[MIR] spl-linux

Bug #1569294 reported by Colin Ian King on 2016-04-12
24
This bug affects 3 people
Affects Status Importance Assigned to Milestone
spl-linux (Ubuntu)
High
Unassigned

Bug Description

SPL MIR

[ See also ZFS MIR, bug #1532198 ]

Following the process documented at https://wiki.ubuntu.com/MainInclusionProcess , the following template needs to be filled in to start the MIR for spl in 16.04

Below are my answers to the various main inclusion requirements, marked by a * prefix:

[Availability]:

  "The package must already be in the Ubuntu universe, and must
  build for the architectures it is designed to work on."

  * http://packages.ubuntu.com/source/xenial/spl-linux
  * Yes - built for 64 bit arches only, because ZFS (and hence SPL) is
    designed to run well only on 64 bit architectures.

[Rationale]:

  "There must be a certain level of demand for the package, for example:
  The package is useful for a large part of our user base."

  * Yes - there is a lot of interest in ZFS in the server space and for
    users wanting to use a file system that supports huge collections of
    disks with excellent reliable features such as checksummed raid, mirroring
    striping with easy configuration and also simple data sanity checking and
    fixing.
  * Being requested by Kiko

  "The package is a new build dependency or dependency of a package that we
  already support (additionally, the official image builder requires all
  used packages be in main)."

  * Yes, already in Wily as a technology demo.

  "The package helps meet a specific Blueprint goal."

  * No blueprint goal.

  "The package replaces another package we currently support and promises
  higher quality and/or better features, so that we can drop the old
  package from the supported set."

  * Not applicable

[Security]:
  "The security history and the current state of security issues in
  the package must allow us to support the package for at least 18 months
  without exposing its users to an inappropriate level of security risks.
  This requires checking of several things that are explained in detail in
  the subsection Security checks."

  "Check how many vulnerabilities the package had in the past and how they
  were handled by upstream and the Debian/Ubuntu package:"

  "http://cve.mitre.org/cve/cve.html: Search in the National Vulnerability
   Database using the package as a keyword"

  NO SPL (ZFS) CVEs found.

  "http://secunia.com/advisories/search/: search for the package as a keyword"

  * No security advisories found

  Ubuntu CVE Tracker:

  http://people.ubuntu.com/~ubuntu-security/cve/main.html
  * No
  http://people.ubuntu.com/~ubuntu-security/cve/universe.html
  * No
  http://people.ubuntu.com/~ubuntu-security/cve/partner.html
  * No

  "Check for security relevant binaries. If any are present, this
  requires a more in-depth security review."

  "Executables which have the suid or sgid bit set."
  * Not applicable

  "Executables in /sbin, /usr/sbin."
  * Applicable. This requires security review
      /usr/sbin/splat, test tool

  "Packages which install daemons (/etc/init.d/*)"
  * Applicable. This requires security review

  "Packages which open privileged ports (ports < 1024)."
  * Not applicable

  "Add-ons and plugins to security-sensitive software (filters,
  scanners, UI skins, etc)"
  * Not applicable

[Quality assurance]
  "After installing the package it must be possible to make it working with a reasonable effort of configuration and documentation reading."

  * Will work "out-of-the-box" once zfsutils-linux installed with 4.4 kernel
  * Quick start ZFS reference guide written:
    https://wiki.ubuntu.com/Kernel/Reference/ZFS
  * Package does contains man pages for splat

  "The package must not ask debconf questions higher than medium if it is
  going to be installed by default. The debconf questions must have
  reasonable defaults."

  * Does not apply.

  "There are no long-term outstanding bugs which affect the usability of the program to a major degree. To support a package, we must be reasonably convinced that upstream supports and cares for the package."

  * We have good upstream support from ZFS maintainers, response to bugs
    file upstream is within 24-48 hours

  "The status of important bugs in Debian's, Ubuntu's, and upstream's bug
  tracking systems must be evaluated. Links to these bug trackers need to
  be provided in the MIR report. Important bugs must be pointed out and
  discussed in the MIR report."

  Upsteam bug tracking:
    ZFS - https://github.com/zfsonlinux/zfs/issues
    SPL - https://github.com/zfsonlinux/spl/issues
  Ubuntu bug tracking:
    https://bugs.launchpad.net/ubuntu/+source/zfs-linux

  "The package is maintained well in Debian/Ubuntu (check out the Debian PTS)"
    Maintained by Kernel team in sync with kernel

  Testing: We have several sets of ZFS specific regression tests in the
    kernel team autotest test infrastructure:

  * The ZFS test suite:
    http://kernel.ubuntu.com/git/ubuntu/autotest-client-tests.git/tree/ubuntu_zfs
  * fstest (Linux POSIX file system test suite)
    http://kernel.ubuntu.com/git/ubuntu/autotest-client-tests.git/tree/ubuntu_zfs_fstest
  * ZFS I/O stress tests:
    http://kernel.ubuntu.com/git/ubuntu/autotest-client-tests.git/tree/ubuntu_zfs_stress
  * XFS generic tests on ZFS:
    http://kernel.ubuntu.com/git/ubuntu/autotest-client-tests.git/tree/ubuntu_zfs_xfs_generic
  * ZFS Kernel smoke tests
    http://kernel.ubuntu.com/git/ubuntu/autotest-client-tests.git/tree/ubuntu_zfs_smoke_test

[Dependencies]:
  All build and binary dependencies (including Recommends:) must be
  satisfyable in main (i. e. the preferred alternative must be in main).
  If not, these dependencies need a separate MIR report (this can be a
  separate bug or another task on the main MIR bug)

  spl:
  * autotools-dev - Yes
  * autoconf - Yes
  * autogen - Yes
  * automake - Yes
  * debhelper - Yes
  * dh-autoreconf - Yes
  * dkms - Yes
  * libtool - Yes
  * libc-dev - Yes

[Standards compliance]

  "Standards compliance: The package should meet the FHS and Debian Policy
  standards. Major violations should be documented and justified. Also, the
  source packaging should be reasonably easy to understand and maintain."

  Yes, I believe so.

[Maintenance]

  "The package must have an acceptable level of maintenance
  corresponding to its complexity:
  Simple packages (e.g. language bindings, simple Perl modules, small
  command-line programs, etc.) might not need very much maintenance effort,
  and if they are maintained well in Debian we can just keep them synced

  More complex packages will usually need a developer or team of
  developers paying attention to their bugs, whether that be in Ubuntu or
  elsewhere (often Debian). Packages that deliver major new headline
  features in Ubuntu need to have commitment from Ubuntu developers
  willing to spend substantial time on them."

  * Falls into the complex package category. Colin King will primarily
    maintain this package, with ownership owned and covered by the
    Canonical Kernel Team.

  "All packages must have a designated "owning" team, regardless of
  complexity, which is set as a package bug contact."

  * Yes, Canononical Kernel Team
    https://launchpad.net/~canonical-kernel-team

[Background information]
  "The package descriptions should explain the general purpose and context
  of the package. Additional explanations/justifications should be done
  in the MIR report."

  * Yes, package description covers the scope of the package

  "If the package was renamed recently, or has a different upstream name,
  this needs to be explained in the MIR report."

Michael Terry (mterry) on 2016-04-12
Changed in spl-linux (Ubuntu):
assignee: nobody → Ubuntu Security Team (ubuntu-security)
Seth Arnold (seth-arnold) wrote :

I reviewed spl-linux version 0.6.5.4-0ubuntu2 as checked into xenial; this shouldn't be considered a full security audit, in fact it was fairly quick as I've read much of this code over the years out of curiosity and interest.

The SPL layer has an awkward job to do but does it well, and provides in-kernel testing framework, which is all too rare.

Security team ACK for promoting spl-linux to main.

Thanks

Changed in spl-linux (Ubuntu):
assignee: Ubuntu Security Team (ubuntu-security) → nobody
Michael Terry (mterry) wrote :

- Needs a team bug subscriber

- The tests are disabled with this comment:

 # scripts/check.sh tries insmod and rmmod, so it cannot
 # run in an unprivileged build environment.

Can we run that via dep8? We already have a dep8 test for the dkms bits. Should be easy to add another.

- Not a blocker, but we could sure use a merge from Debian. Haven't done that since vivid, it looks like.

Other than those issues, seems fine.

Changed in spl-linux (Ubuntu):
status: New → Incomplete
Changed in spl-linux (Ubuntu):
importance: Undecided → High
Richard Laager (rlaager) wrote :

Is this good to go, at least for yakkety? This is necessary for zfs-linux to be promoted to main.

Michael Terry (mterry) wrote :

My comment #2 still stands. Subscriber and investigation into tests.

Colin Ian King (colin-king) wrote :

I'm working on it, ref: bug 1579036

Colin Ian King (colin-king) wrote :

@Michael Terry, I've prepared a package to address the issues in comment #2, please refer to bug 1579036 where I have filed a SRU to cater for these changes

Launchpad Janitor (janitor) wrote :

[Expired for spl-linux (Ubuntu) because there has been no activity for 60 days.]

Changed in spl-linux (Ubuntu):
status: Incomplete → Expired
Changed in spl-linux (Ubuntu):
status: Expired → In Progress
Michael Terry (mterry) wrote :

Looks fine, just needs a team bug subscriber.

Steve Langasek (vorlon) wrote :

I discussed this further with Colin out of band. It doesn't appear that we have any reason to want to seed spl directly, the package was only being pulled in as a dependency of zfs-dkms; the zfs-dkms binary package being pulled into main is only due to an ordering issue in germinate, which I've resolved by dropping the Recommends from zfsutils-linux to zfs-dkms. We don't want zfs-dkms in main because we have an implementation of the driver in the kernel package instead, and without zfs-dkms we don't need spl-linux in main. So closing wontfix.

Changed in spl-linux (Ubuntu):
status: In Progress → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers