** Description changed: [Availability] runc is in universe (https://launchpad.net/ubuntu/+source/runc) and builds on amd64, arm64, armhf, i386, ppc64el and s390x. [Rationale] This package is a requirement for the containerd MIR bug #1819761. Both packages are necessary for OCF (Open Container Format) support, from the OCI (Open Containers Initiative, https://www.opencontainers.org/) [Security] runc has currently 3 CVEs: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-5736 runc through 1.0-rc6, as used in Docker before 18.09.2 and other products, allows attackers to overwrite the host runc binary (and consequently obtain host root access) by leveraging the ability to execute a command as root within one of these types of containers: (1) a new container with an attacker-controlled image, or (2) an existing container, to which the attacker previously had write access, that can be attached with docker exec. This occurs because of file-descriptor mishandling, related to /proc/self/exe. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-9962 RunC allowed additional container processes via 'runc exec' to be ptraced by the pid 1 of the container. This allows the main processes of the container, if running as root, to gain access to file-descriptors of these new processes during the initialization and can lead to container escapes or modification of runC state before the process is fully placed inside the container. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-3697 libcontainer/user/user.go in runC before 0.1.0, as used in Docker before 1.11.2, improperly treats a numeric UID as a potential username, which allows local users to gain privileges via a numeric username in the password file in a container. There are no suid/sgid binaries, and all executables are in /usr/sbin. There are no services or daemons in this packages (sysv, upstart or systemd). There are no open privileged or otherwise ports. It is used by container software like docker. [Quality assurance] After installing the package it must be possible to make it working with a reasonable effort of configuration and documentation reading. - the upstream site (https://github.com/opencontainers/runc) has a quickstart tutorial that boils down to this, and it works: # create the top most bundle directory mkdir /mycontainer cd /mycontainer # create the rootfs directory mkdir rootfs # export busybox via Docker into the rootfs directory docker export $(docker create busybox) | tar -C rootfs -xvf - # create a default config.json file runc spec # run it (no changes to config.json necessary) runc run mycontainerid / # id uid=0(root) gid=0(root) / # ps PID USER TIME COMMAND 1 root 0:00 sh 7 root 0:00 ps 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. - no debconf questions 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. - there are currently no open bugs in Ubuntu: https://bugs.launchpad.net/ubuntu/+source/runc - open bugs in debian: - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912821 "runc checkpoint failed without criu" Depending on how important the "checkpoint" feature is, we might have to pull in criu via a Recommends or Depends, and criu will require its own MIR. criu might be a problem because it seems to be python2, and has other deps that will need a MIR of its own. For now, we could add criu as a suggests. - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=922050: security bug CVE-2019-5736 - upstream bugs: https://github.com/opencontainers/runc/issues (currently 159 open, 399 closed) - upstream pull requests: https://github.com/opencontainers/runc/pulls (currently 70 open, 1364 closed) The package is maintained well in Debian/Ubuntu (check out the Debian PTS) - debian pts for runc: https://packages.qa.debian.org/r/runc.html - package is scheduled for removal by March 27th, 2019, because of CVE-2019-5736 (bug #922050) That being said, there is a new package in the queue which fixes that bug already (1.0.0~rc6+dfsg1-2). - the package has DEP8 tests - many uploads per year The package should not deal with exotic hardware which we cannot support. - no exotic hardware involved If the package ships a test suite, and there is no obvious reason why it cannot work during build (e. g. it needs root privileges or network access), it should be run during package build, and a failing test suite should fail the build. - tests are run at package build time. Example run, search for "dh_auto_test": https://launchpadlibrarian.net/411349775/buildlog_ubuntu-disco-amd64.runc_1.0.0~rc6+git20181203.96ec2177-0ubuntu1_BUILDING.txt.gz - the package also has DEP8 tests The package uses a debian/watch file whenever possible. In cases where this is not possible (e. g. native packages), the package should either provide a debian/README.source file or a debian/watch file (with comments only) providing clear instructions on how to generate the source tar file. - there is a debian/watch file and it uses https It is often useful to run lintian --pedantic on the package to spot the most common packaging issues in advance - these are the lintian issues in runc-1.0.0~rc6+git20181203.96ec2177: $ lintian --pedantic -I --show-overrides P: runc source: package-uses-old-debhelper-compat-version 10 I: runc source: out-of-date-standards-version 4.1.4 (released 2018-04-05) (current is 4.3.0) I: runc source: unused-override source-contains-empty-directory vendor/* W: golang-github-opencontainers-runc-dev: package-has-long-file-name 85 > 80 W: runc: manpage-has-bad-whatis-entry usr/share/man/man8/runc-checkpoint.8.gz W: runc: manpage-has-bad-whatis-entry usr/share/man/man8/runc-create.8.gz W: runc: manpage-has-bad-whatis-entry usr/share/man/man8/runc-delete.8.gz W: runc: manpage-has-bad-whatis-entry ... use --no-tag-display-limit to see all (or pipe to a file/program) W: runc: binary-without-manpage usr/sbin/recvtty I: runc: unused-override spelling-error-in-binary - the runc binary package ships one lintian override: runc: spelling-error-in-binary The missing manpage for recvtty could be created somewhat easily via the recvtty --help output, which looks very much like a manpage already. The package should not rely on obsolete or about to be demoted packages. That currently includes package dependencies on Python2 (without providing Python3 packages), and packages depending on GTK2. - the package has many golang build dependencies that come from Universe. The MIR team currently seems to have an understanding (https://wiki.ubuntu.com/MIRTeam#golang) that that is acceptable, but subject to a case-by-case analysis to avoid populating main with too many packages like this. - the package gets extended funcionality if criu (https://launchpad.net/ubuntu/+source/criu, from universe currently), is installed. There is a Debian bug requesting that criu is added as a Recommends. That would trigger another MIR in Ubuntu, and in the meantime we could add that package as a Suggests. The funcionality that is added by that package is snapshots of containers. - there are no python{2,3} or GTK2 dependencies - there is a build-depends on protobuf-compiler, but that doesn't seem to introduce runtime dependencies related to that. [UI standards] (generally only for user-facing applications) - there is no internationalization support in runc. I think the most common use case for runc is to be consumed/used by other tools, instead of directly. Unless one wants to get to the lower level where runc is used, maybe for troubleshooting. [Dependencies] - - currently all dependencies, including Recommends, are in mind, with the note + - currently all dependencies, including Recommends, are in main, with the note about golang packages from Universe that are pulled in during build and linked with statically. There is a Debian bug asking to add criu as a Recommends, already mentioned earlier, and that would break this check. Either we MIR criu, or add it as a suggests for the time being. [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. - FHS compliance looks fine. The package ships just 34 files: manpages are at the proper location, so are binaries and /usr/share/doc files. - debian policy is a bit less than one year old: ships with 4.1.4 (released 2018-04-05), current one is 4.3.0 - I didn't spot major violations of the policy. I didn't check d/copyright to see if it's up-to-date [Maintenance] All packages must have a designated "owning" team, regardless of complexity, which is set as a package bug contact. - at some point, the Ubuntu Server manager should comment on the bug accepting maintenance of this package The runc tool by itself has simple usage, but is used by more complex packages like docker, containerd and others. [Background information] None at this time.
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1817336 Title: [MIR] runc To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/runc/+bug/1817336/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
