** Description changed: + Disclaimer: this template is not fully filled up. I'd like to have the feeling of the MIR team on this bug before actually spending more time going further, given that we're talking about `util-linux`, which is one of the few very essential packages of a Linux system, and we won't have much of choice other than promoting liblastlog2-2 to main. I've already completed some parts of the template, to show that promoting this shouldn't be too much of a problem anyway, because the package is generally speaking well maintained. - [Availability] The package src:util-linux is already in Ubuntu main. The package src:util-linux build for the architectures it is designed to work on. It currently builds and works for architectures: amd64, arm64, armhf, i386, ppc64el, riscv64, s390x Link to package https://launchpad.net/ubuntu/+source/util-linux [Rationale] Okay, it seems the MIR template doesn't apply well for this use-case, because it more or less assumes that the MIR is about a source package that is currently in universe. In the current situation, only an existing binary package needs to be promoted, from a source package already in main. I'll do my best to adapt the template and provide a good rational. - bin:liblastlog2-2 is provided by src:util-linux, and was already there in - plucky/universe. + plucky/universe. - The package src:util-linux is generally useful for a large part of - our user base: it provides the bin:util-linux package, that is even flagged as - `Essential: yes`. - This is the package providing, among many other things, the `su`, `fsck`, - `flock`, or `mkswap` binaries, all mostly essential to any system (random - selection of important commands to give a quick example). + our user base: it provides the bin:util-linux package, that is even flagged as + `Essential: yes`. + This is the package providing, among many other things, the `su`, `fsck`, + `flock`, or `mkswap` binaries, all mostly essential to any system (random + selection of important commands to give a quick example). - The package bin:liblastlog2-2 is a new runtime dependency of package - bin:util-linux that we already support. + bin:util-linux that we already support. - The binary packages liblastlog2-2 needs to be in main to have the latest merge - of util-linux migrate from questing-proposed to questing. + of util-linux migrate from questing-proposed to questing. - All other binary packages currently in universe built by src:util-linux should - remain in universe. + remain in universe. - The package bin:liblastlog2-2 is required in Ubuntu main no later than - somewhere in July due to some partners requiring patches to be SRU'd to Noble, - and thus needing the package to migrate from -proposed (even though it's not a - hard block from the SRU team, according to what I've red on Matrix recently). + somewhere in July due to some partners requiring patches to be SRU'd to Noble, + and thus needing the package to migrate from -proposed (even though it's not a + hard block from the SRU team, according to what I've red on Matrix recently). [Security] - Obviously, util-linux has had some security issues in the past (although not - that much): - - https://ubuntu.com/security/cves?package=util-linux - - https://security-tracker.debian.org/tracker/source-package/util-linux + that much): + - https://ubuntu.com/security/cves?package=util-linux + - https://security-tracker.debian.org/tracker/source-package/util-linux - Those issues seems to be handled correctly in both Ubuntu and Debian: - - https://ubuntu.com/security/CVE-2024-28085 - - https://security-tracker.debian.org/tracker/CVE-2024-28085 - - https://security-tracker.debian.org/tracker/CVE-2021-37600 + - https://ubuntu.com/security/CVE-2024-28085 + - https://security-tracker.debian.org/tracker/CVE-2024-28085 + - https://security-tracker.debian.org/tracker/CVE-2021-37600 - There are countless binaries in sbin, but I'm fairly confident taking them out - is a big plan of its own to still have a working system. + is a big plan of its own to still have a working system. - There are just a couple systemd units: - - fstrim.{service,timer}: Discard unused filesystem blocks once a week - - lastlog2-import.service: Import lastlog data into lastlog2 database - run only once in some particular situations to handle a data migration + - fstrim.{service,timer}: Discard unused filesystem blocks once a week + - lastlog2-import.service: Import lastlog data into lastlog2 database - run only once in some particular situations to handle a data migration - About common isolation/risk-mitigation: - - I'm not sure anything in util-linux is opening privileged ports. - - I know some binaries are dropping privileges. - - Going much further on that topic would be a full audit, for which I - unfortunately don't really have time and competency for. I hope that's okay. + - I'm not sure anything in util-linux is opening privileged ports. + - I know some binaries are dropping privileges. + - Going much further on that topic would be a full audit, for which I + unfortunately don't really have time and competency for. I hope that's okay. - Packages does not contain extensions to security-sensitive software (filters, scanners, plugins, UI skins, ...) [Quality assurance - function/usage] - The package works well right after install [Quality assurance - maintenance] - The package is maintained well in Debian/Ubuntu/Upstream and does - not have too many, long-term & critical, open bugs - - Ubuntu https://bugs.launchpad.net/ubuntu/+source/util-linux/+bugs?orderby=-importance&start=0 - - Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=util-linux - - Upstream https://github.com/util-linux/util-linux/issues - - Obviously this package has tons of bugs opened, but at the same time, it has - a lot of activity, and is well maintained upstream, in Debian, and in - Ubuntu, just because of its central position in any Linux system. + not have too many, long-term & critical, open bugs + - Ubuntu https://bugs.launchpad.net/ubuntu/+source/util-linux/+bugs?orderby=-importance&start=0 + - Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=util-linux + - Upstream https://github.com/util-linux/util-linux/issues + - Obviously this package has tons of bugs opened, but at the same time, it has + a lot of activity, and is well maintained upstream, in Debian, and in + Ubuntu, just because of its central position in any Linux system. - The package does not deal with exotic hardware we cannot support [Quality assurance - testing] - The package runs a test suite on build time, if it fails - it makes the build fail, link to build log TBD + it makes the build fail, link to build log TBD - The package runs an autopkgtest, and is currently passing on - all architectures but i386: https://autopkgtest.ubuntu.com/packages/util-linux + all architectures but i386: https://autopkgtest.ubuntu.com/packages/util-linux - The package does have not failing autopkgtests right now [Quality assurance - packaging] - debian/watch is present and works - debian/control defines a correct Maintainer field - This package does not yield massive lintian Warnings, Errors - Recent build: https://launchpad.net/ubuntu/+source/util-linux/2.41-4ubuntu2/+build/30908305 - Lintian overrides are present, but ok because most are well commented, and the rest is pretty obvious, like highly privileged binaries. - This package does not rely on obsolete or about to be demoted packages. - The package will be installed by default, but does not ask debconf - questions higher than medium + questions higher than medium - Packaging is quite complex, but I'm not sure how much of a choice we have. - Good thing is that this package is equally important in Debian, so it will very - likely keep being maintained. + Good thing is that this package is equally important in Debian, so it will very + likely keep being maintained. [UI standards] - TODO-A: - Application is not end-user facing (does not need translation) - TODO-B: - Application is end-user facing, Translation is present, via standard - TODO-B: intltool/gettext or similar build and runtime internationalization - TODO-B: system see TBD + - Application is end-user facing, Translation is present, via standard + intltool/gettext. See `configure` for `libintl` and `gettext`. - TODO-A: - End-user applications that ships a standard conformant desktop file, - TODO-A: see TBD - TODO-B: - End-user applications without desktop file, not needed because TBD + - End-user applications without desktop file, not needed because it only ships + CLI tools. [Dependencies] - RULE: - In case of alternative the preferred alternative must be in main. - RULE: - Build(-only) dependencies can be in universe - RULE: - If there are further dependencies they need a separate MIR discussion - RULE: (this can be a separate bug or another task on the main MIR bug) - TODO-A: - No further depends or recommends dependencies that are not yet in main - TODO-B: - There are further dependencies that are not yet in main, MIR for them - TODO-B: is at TBD - TODO-C: - There are further dependencies that are not yet in main, the MIR - TODO-C: process for them is handled as part of this bug here. + - No further depends or recommends dependencies that are not yet in main [Standards compliance] - RULE: - Major violations should be documented and justified. - RULE: - FHS: https://refspecs.linuxfoundation.org/fhs.shtml - RULE: - Debian Policy: https://www.debian.org/doc/debian-policy/ - TODO-A: - This package correctly follows FHS and Debian Policy - TODO-B: - This package violates FHS or Debian Policy, reasons for that are TBD + - This package correctly follows FHS and Debian Policy. [Maintenance/Owner] - RULE: The package must have an acceptable level of maintenance corresponding - RULE: to its complexity: - RULE: - All packages must have a designated "owning" team, regardless of - RULE: complexity. - RULE: This requirement of an owning-team comes in two aspects: - RULE: - A case needs to have a team essentially saying "yes we will own that" - RULE: to enter the MIR process. Usually that is implied by team members - RULE: filing MIR requests having the backup by their management for the - RULE: long term commitment this implies. - RULE: - A community driven MIR request might be filed to show the use case, - RULE: but then, as a first step, needs to get a team agreeing to own - RULE: it before the case can be processed further. - RULE: If unsure which teams to consider have a look at the current mapping - RULE: http://reqorts.qa.ubuntu.com/reports/m-r-package-team-mapping.html - RULE: In that case (you are not a representative of the team who will - RULE: gain the long term committment to this) please ask a representative - RULE: of that team to comment on the bug acknowledging that they are ok to - RULE: own it. - RULE: - The package needs a bug subscriber before it can be promoted to main. - RULE: Strictly speaking that subscription can therefore wait until the - RULE: moment of the actual promotion by an archive admin. But it is - RULE: strongly recommended to subscribe early, as the owning team will get - RULE a preview of the to-be-expected incoming bugs later on. - RULE: - Simple packages (e.g. language bindings, simple Perl modules, small - RULE: command-line programs, etc.) might not need very much maintenance - RULE: effort, and if they are maintained well in Debian we can just keep them - RULE: synced. They still need a subscribing team to handle bugs, FTBFS and - RULE: tests - RULE: - More complex packages will usually need a developer or team of - RULE: developers paying attention to their bugs, whether that be in Ubuntu - RULE: or elsewhere (often Debian). Packages that deliver major new headline - RULE: features in Ubuntu need to have commitment from Ubuntu developers - RULE: willing to spend substantial time on them. - TODO-A: - The owning team will be TBD and I have their acknowledgement for - TODO-A: that commitment - TODO-B: - I Suggest the owning team to be TBD - TODO-A: - The future owning team is already subscribed to the package - TODO-B: - The future owning team is not yet subscribed, but will subscribe to - TODO-B: the package before promotion + - The owning team will be debcrafters-packages and I have their acknowledgement for + that commitment + - The future owning team is already subscribed to the package. - RULE: - Responsibilities implied by static builds promoted to main, which is - RULE: not a recommended but a common case with golang and rust packages. - RULE: - the security team will track CVEs for all vendored/embedded sources in main - RULE: - the security team will provide updates to main for all `golang-*-dev` - RULE: packages - RULE: - the security team will provide updates to main for non-vendored - RULE: dependencies as per normal procedures (including e.g., - RULE: sponsoring/coordinating uploads from teams/upstream projects, etc) - RULE: - the security team will perform no-change-rebuilds for all packages - RULE: listing an CVE-fixed package as Built-Using and coordinate testing - RULE: with the owning teams responsible for the rebuilt packages - RULE: - for packages that build using any `golang-*-dev` packages: - RULE: - the owning team must state their commitment to test - RULE: no-change-rebuilds triggered by a dependent library/compiler and to - RULE: fix any issues found for the lifetime of the release (including ESM - RULE: when included) - RULE: - the owning team must provide timely testing of no-change-rebuilds - RULE: from the security team, fixing the rebuilt package as necessary - RULE: - for packages that build with approved vendored code: - RULE: - the owning team must state their commitment to provide updates to - RULE: the security team for any affected vendored code for the lifetime of - RULE: the release (including ESM when included) - RULE: - the security team will alert the owning team of issues that may - RULE: affect their vendored code - RULE: - the owning team will provide timely, high quality updates for the - RULE: security team to sponsor to fix issues in the affected vendored code - RULE: - the owning team will use a minimal set of vendored code (e.g., Rust - RULE: packages are unlikely to need `*_win` crates to build) - RULE: - if subsequent uploads add new vendored components or dependencies - RULE: these have to be reviewed and agreed by the security team. - RULE: - Such updates in the project might be trivial, but imply that a - RULE: dependency for e.g. a CVE fix will be moved to a new major version. - RULE: Being vendored that does gladly at least not imply incompatibility - RULE: issues with other packages or the SRU policy. But it might happen - RULE: that this triggers either: - RULE: a) The need to adapt the current version of the main package and/or - RULE: other vendored dependencies to work with the new dependency - RULE: b) The need to backport the fix in the dependency as the main - RULE: package will functionally only work well with the older version - RULE: c) The need to backport the fix in the dependency, as it would imply - RULE: requiring a newer toolchain to be buildable that isn't available - RULE: in the target release. - RULE: - The rust ecosystem currently isn't yet considered stable enough for - RULE: classic lib dependencies and transitions in main; therefore the - RULE: expectation for those packages is to vendor (and own/test) all - RULE: dependencies (except those provided by the rust runtime itself). - RULE: This implies that all the rules for vendored builds always - RULE: apply to them. In addition: - RULE: - The rules and checks for rust based packages are preliminary and might - RULE: change over time as the ecosystem matures and while - RULE: processing the first few rust based packages. - RULE: - It is expected rust builds will use dh-cargo so that a later switch - RULE: to non vendored dependencies isn't too complex (e.g. it is likely - RULE: that over time more common libs shall become stable and then archive - RULE: packages will be used to build). - RULE: - The tooling to get a Cargo.lock that will include internal vendored - RULE: dependencies is described at: - RULE: https://github.com/ubuntu/ubuntu-project-docs/blob/main/docs/MIR/mir-rust.md - RULE: - An example of how Rust dependency vendoring can be automated is - RULE: "s390-tools", isolating crates in a .orig-vendor.tar.xz tarball: - RULE: * https://git.launchpad.net/ubuntu/+source/s390-tools/tree/debian/rules - RULE: Other examples include "authd" (for a native package, combined with - RULE: Golang vendoring) and "gnome-snapshot" (using debian/missing-sources): - RULE: * authd: - RULE: https://github.com/ubuntu/authd/blob/main/debian/rules - RULE: * gnome-snapshot: - RULE: https://salsa.debian.org/ubuntu-dev-team/snapshot/-/blob/ubuntu/latest/debian/README.source + - This does not use static builds. + - This does not use vendored code + - This package is not rust based - RULE: - All vendored dependencies (no matter what language) shall have a - RULE: way to be refreshed - TODO-A: - This does not use static builds - TODO-B: - The team TBD is aware of the implications by a static build and - TODO-B: commits to test no-change-rebuilds and to fix any issues found for the - TODO-B: lifetime of the release (including ESM) - - TODO-A: - This does not use vendored code - TODO-B: - The team TBD is aware of the implications of vendored code and (as - TODO-B: alerted by the security team) commits to provide updates and backports - TODO-B: to the security team for any affected vendored code for the lifetime - TODO-B: of the release (including ESM). - - TODO-A: - This does not use vendored code - TODO-B: - This package uses vendored go code tracked in go.sum as shipped in the - TODO-B: package, refreshing that code is outlined in debian/README.source - TODO-C: - This package uses vendored rust code tracked in Cargo.lock as shipped, - TODO-C: in the package (at /usr/share/doc/<pkgname>/Cargo.lock - might be - TODO-C: compressed), refreshing that code is outlined in debian/README.source - TODO-D: - This package uses vendored code, refreshing that code is outlined - TODO-D: in debian/README.source - - TODO-A: - This package is not rust based - TODO-B: - This package is rust based and vendors all non language-runtime - TODO-B: dependencies - - RULE: - Some packages build and update often, in this case everyone can just - RULE: check the recent build logs to ensure if it builds fine. - RULE: But some other packages are rather stable and have not been rebuilt - RULE: in a long time. There no one can be confident it would build on e.g. - RULE: an urgent security fix. Hence we ask if there has been a recent build. - RULE: That might be a recent build that has been done anyway as seen on - RULE: https://launchpad.net/ubuntu/+source/<source>, a reference to a recent - RULE: archive test rebuild (those are announced on the ubuntu-devel mailing - RULE: list like https://lists.ubuntu.com/archives/ubuntu-devel-announce/2024-January/001342.html), - RULE: or a build set up by the reporter in a PPA with all architectures - RULE: enabled. - TODO-A: - The package has been built within the last 3 months in the archive - TODO-B: - The package has been built within the last 3 months as part - TODO-B: of a test rebuild - TODO-C: - The package has been built within the last 3 months in PPA - TODO-D: - The package has been built within the last 3 months in sbuild as it - TODO-D: can not be uploaded yet - RULE: - To make it easier for everyone, please provide a link to that build so - RULE: everyone can follow up easily e.g. checking the various architectures. - RULE: Example https://launchpad.net/ubuntu/+source/qemu/1:8.2.2+ds-0ubuntu1 - TODO: - Build link on launchpad: TBD + - The package has been built within the last 3 months in the archive + - Build link on launchpad: https://launchpad.net/ubuntu/+source/util-linux/2.41-4ubuntu2 [Background information] - RULE: - The package descriptions should explain the general purpose and context - RULE: of the package. Additional explanations/justifications should be done in - RULE: the MIR report. - RULE: - If the package was renamed recently, or has a different upstream name, - RULE: this needs to be explained in the MIR report. - TODO: The Package description explains the package well - TODO: Upstream Name is TBD - TODO: Link to upstream project TBD - TODO: TBD (any further background that might be helpful + The Package description explains the package well + Upstream Name is `util-linux` + Link to upstream project: https://github.com/util-linux/util-linux/ + + This package has been in main since the very early beginning of Ubuntu, so never got the chance to get a proper MIR. + This was sparked when the `bin:util-linux` has started to depend on `bin:liblastlog2-2`, which was in Universe. `liblastlog2-2` was nicely handled by @paelzer under the "Renamed or re-organized sources" condition (https://canonical-ubuntu-project.readthedocs-hosted.com/MIR/mir-rereview/#renamed-or-reorganized-sources). + This MIR still makes sense to me, given that `util-linux` provides many very important binaries, among which many of them are `suid`, and is one the `Essential` packages shipped in absolutely every form Ubuntu can take.
** Description changed: - - Disclaimer: this template is not fully filled up. I'd like to have the feeling - of the MIR team on this bug before actually spending more time going further, - given that we're talking about `util-linux`, which is one of the few very - essential packages of a Linux system, and we won't have much of choice other - than promoting liblastlog2-2 to main. - I've already completed some parts of the template, to show that promoting this - shouldn't be too much of a problem anyway, because the package is generally - speaking well maintained. - [Availability] The package src:util-linux is already in Ubuntu main. The package src:util-linux build for the architectures it is designed to work on. It currently builds and works for architectures: amd64, arm64, armhf, i386, ppc64el, riscv64, s390x Link to package https://launchpad.net/ubuntu/+source/util-linux [Rationale] + See previous rational below for what actually sparked this MIR. + Now that `bin:liblastlog2-2` has been promoted and everything is unblocked, the rationale becomes as simple as an ask for a re-review for one of the `Essential` packages, shipping, among other things, a few `suid` binaries in absolutely every form Ubuntu can take. + https://canonical-ubuntu-project.readthedocs-hosted.com/MIR/mir-rereview/#opt-in-re-review + + Original rationale: Okay, it seems the MIR template doesn't apply well for this use-case, because it more or less assumes that the MIR is about a source package that is currently in universe. In the current situation, only an existing binary package needs to be promoted, from a source package already in main. I'll do my best to adapt the template and provide a good rational. - bin:liblastlog2-2 is provided by src:util-linux, and was already there in plucky/universe. - The package src:util-linux is generally useful for a large part of our user base: it provides the bin:util-linux package, that is even flagged as `Essential: yes`. This is the package providing, among many other things, the `su`, `fsck`, `flock`, or `mkswap` binaries, all mostly essential to any system (random selection of important commands to give a quick example). - The package bin:liblastlog2-2 is a new runtime dependency of package bin:util-linux that we already support. - The binary packages liblastlog2-2 needs to be in main to have the latest merge of util-linux migrate from questing-proposed to questing. - All other binary packages currently in universe built by src:util-linux should remain in universe. - The package bin:liblastlog2-2 is required in Ubuntu main no later than somewhere in July due to some partners requiring patches to be SRU'd to Noble, and thus needing the package to migrate from -proposed (even though it's not a hard block from the SRU team, according to what I've red on Matrix recently). [Security] - Obviously, util-linux has had some security issues in the past (although not that much): - https://ubuntu.com/security/cves?package=util-linux - https://security-tracker.debian.org/tracker/source-package/util-linux - Those issues seems to be handled correctly in both Ubuntu and Debian: - https://ubuntu.com/security/CVE-2024-28085 - https://security-tracker.debian.org/tracker/CVE-2024-28085 - https://security-tracker.debian.org/tracker/CVE-2021-37600 - There are countless binaries in sbin, but I'm fairly confident taking them out is a big plan of its own to still have a working system. - There are just a couple systemd units: - fstrim.{service,timer}: Discard unused filesystem blocks once a week - lastlog2-import.service: Import lastlog data into lastlog2 database - run only once in some particular situations to handle a data migration - About common isolation/risk-mitigation: - I'm not sure anything in util-linux is opening privileged ports. - I know some binaries are dropping privileges. - Going much further on that topic would be a full audit, for which I unfortunately don't really have time and competency for. I hope that's okay. - Packages does not contain extensions to security-sensitive software (filters, scanners, plugins, UI skins, ...) [Quality assurance - function/usage] - The package works well right after install [Quality assurance - maintenance] - The package is maintained well in Debian/Ubuntu/Upstream and does not have too many, long-term & critical, open bugs - Ubuntu https://bugs.launchpad.net/ubuntu/+source/util-linux/+bugs?orderby=-importance&start=0 - Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=util-linux - Upstream https://github.com/util-linux/util-linux/issues - Obviously this package has tons of bugs opened, but at the same time, it has a lot of activity, and is well maintained upstream, in Debian, and in Ubuntu, just because of its central position in any Linux system. - The package does not deal with exotic hardware we cannot support [Quality assurance - testing] - The package runs a test suite on build time, if it fails it makes the build fail, link to build log TBD - The package runs an autopkgtest, and is currently passing on all architectures but i386: https://autopkgtest.ubuntu.com/packages/util-linux - The package does have not failing autopkgtests right now [Quality assurance - packaging] - debian/watch is present and works - debian/control defines a correct Maintainer field - This package does not yield massive lintian Warnings, Errors - Recent build: https://launchpad.net/ubuntu/+source/util-linux/2.41-4ubuntu2/+build/30908305 - Lintian overrides are present, but ok because most are well commented, and the rest is pretty obvious, like highly privileged binaries. - This package does not rely on obsolete or about to be demoted packages. - The package will be installed by default, but does not ask debconf questions higher than medium - Packaging is quite complex, but I'm not sure how much of a choice we have. Good thing is that this package is equally important in Debian, so it will very likely keep being maintained. [UI standards] - Application is end-user facing, Translation is present, via standard - intltool/gettext. See `configure` for `libintl` and `gettext`. + intltool/gettext. See `configure` for `libintl` and `gettext`. - End-user applications without desktop file, not needed because it only ships CLI tools. [Dependencies] - No further depends or recommends dependencies that are not yet in main [Standards compliance] - This package correctly follows FHS and Debian Policy. [Maintenance/Owner] - The owning team will be debcrafters-packages and I have their acknowledgement for - that commitment + that commitment - The future owning team is already subscribed to the package. - This does not use static builds. - This does not use vendored code - This package is not rust based - The package has been built within the last 3 months in the archive - Build link on launchpad: https://launchpad.net/ubuntu/+source/util-linux/2.41-4ubuntu2 [Background information] The Package description explains the package well Upstream Name is `util-linux` Link to upstream project: https://github.com/util-linux/util-linux/ This package has been in main since the very early beginning of Ubuntu, so never got the chance to get a proper MIR. This was sparked when the `bin:util-linux` has started to depend on `bin:liblastlog2-2`, which was in Universe. `liblastlog2-2` was nicely handled by @paelzer under the "Renamed or re-organized sources" condition (https://canonical-ubuntu-project.readthedocs-hosted.com/MIR/mir-rereview/#renamed-or-reorganized-sources). This MIR still makes sense to me, given that `util-linux` provides many very important binaries, among which many of them are `suid`, and is one the `Essential` packages shipped in absolutely every form Ubuntu can take. ** Description changed: [Availability] The package src:util-linux is already in Ubuntu main. The package src:util-linux build for the architectures it is designed to work on. It currently builds and works for architectures: amd64, arm64, armhf, i386, ppc64el, riscv64, s390x Link to package https://launchpad.net/ubuntu/+source/util-linux [Rationale] See previous rational below for what actually sparked this MIR. - Now that `bin:liblastlog2-2` has been promoted and everything is unblocked, the rationale becomes as simple as an ask for a re-review for one of the `Essential` packages, shipping, among other things, a few `suid` binaries in absolutely every form Ubuntu can take. + Now that `bin:liblastlog2-2` has been promoted and everything is unblocked, the + rationale becomes as simple as an ask for a re-review for one of the `Essential` + packages, shipping, among other things, a few `suid` binaries in absolutely + every form Ubuntu can take. https://canonical-ubuntu-project.readthedocs-hosted.com/MIR/mir-rereview/#opt-in-re-review Original rationale: Okay, it seems the MIR template doesn't apply well for this use-case, because it more or less assumes that the MIR is about a source package that is currently in universe. In the current situation, only an existing binary package needs to be promoted, from a source package already in main. I'll do my best to adapt the template and provide a good rational. - bin:liblastlog2-2 is provided by src:util-linux, and was already there in plucky/universe. - The package src:util-linux is generally useful for a large part of our user base: it provides the bin:util-linux package, that is even flagged as `Essential: yes`. This is the package providing, among many other things, the `su`, `fsck`, `flock`, or `mkswap` binaries, all mostly essential to any system (random selection of important commands to give a quick example). - The package bin:liblastlog2-2 is a new runtime dependency of package bin:util-linux that we already support. - The binary packages liblastlog2-2 needs to be in main to have the latest merge of util-linux migrate from questing-proposed to questing. - All other binary packages currently in universe built by src:util-linux should remain in universe. - The package bin:liblastlog2-2 is required in Ubuntu main no later than somewhere in July due to some partners requiring patches to be SRU'd to Noble, and thus needing the package to migrate from -proposed (even though it's not a hard block from the SRU team, according to what I've red on Matrix recently). [Security] - Obviously, util-linux has had some security issues in the past (although not that much): - https://ubuntu.com/security/cves?package=util-linux - https://security-tracker.debian.org/tracker/source-package/util-linux - Those issues seems to be handled correctly in both Ubuntu and Debian: - https://ubuntu.com/security/CVE-2024-28085 - https://security-tracker.debian.org/tracker/CVE-2024-28085 - https://security-tracker.debian.org/tracker/CVE-2021-37600 - There are countless binaries in sbin, but I'm fairly confident taking them out is a big plan of its own to still have a working system. - There are just a couple systemd units: - fstrim.{service,timer}: Discard unused filesystem blocks once a week - - lastlog2-import.service: Import lastlog data into lastlog2 database - run only once in some particular situations to handle a data migration + - lastlog2-import.service: Import lastlog data into lastlog2 database - run + only once in some particular situations to handle a data migration - About common isolation/risk-mitigation: - I'm not sure anything in util-linux is opening privileged ports. - I know some binaries are dropping privileges. - Going much further on that topic would be a full audit, for which I unfortunately don't really have time and competency for. I hope that's okay. - Packages does not contain extensions to security-sensitive software (filters, scanners, plugins, UI skins, ...) [Quality assurance - function/usage] - The package works well right after install [Quality assurance - maintenance] - The package is maintained well in Debian/Ubuntu/Upstream and does not have too many, long-term & critical, open bugs - Ubuntu https://bugs.launchpad.net/ubuntu/+source/util-linux/+bugs?orderby=-importance&start=0 - Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=util-linux - Upstream https://github.com/util-linux/util-linux/issues - Obviously this package has tons of bugs opened, but at the same time, it has a lot of activity, and is well maintained upstream, in Debian, and in Ubuntu, just because of its central position in any Linux system. - The package does not deal with exotic hardware we cannot support [Quality assurance - testing] - The package runs a test suite on build time, if it fails it makes the build fail, link to build log TBD - The package runs an autopkgtest, and is currently passing on all architectures but i386: https://autopkgtest.ubuntu.com/packages/util-linux - The package does have not failing autopkgtests right now [Quality assurance - packaging] - debian/watch is present and works - debian/control defines a correct Maintainer field - This package does not yield massive lintian Warnings, Errors - Recent build: https://launchpad.net/ubuntu/+source/util-linux/2.41-4ubuntu2/+build/30908305 - Lintian overrides are present, but ok because most are well commented, and the rest is pretty obvious, like highly privileged binaries. - This package does not rely on obsolete or about to be demoted packages. - The package will be installed by default, but does not ask debconf questions higher than medium - Packaging is quite complex, but I'm not sure how much of a choice we have. Good thing is that this package is equally important in Debian, so it will very likely keep being maintained. [UI standards] - Application is end-user facing, Translation is present, via standard intltool/gettext. See `configure` for `libintl` and `gettext`. - End-user applications without desktop file, not needed because it only ships CLI tools. [Dependencies] - No further depends or recommends dependencies that are not yet in main [Standards compliance] - This package correctly follows FHS and Debian Policy. [Maintenance/Owner] - The owning team will be debcrafters-packages and I have their acknowledgement for that commitment - The future owning team is already subscribed to the package. - This does not use static builds. - This does not use vendored code - This package is not rust based - The package has been built within the last 3 months in the archive - Build link on launchpad: https://launchpad.net/ubuntu/+source/util-linux/2.41-4ubuntu2 [Background information] The Package description explains the package well Upstream Name is `util-linux` Link to upstream project: https://github.com/util-linux/util-linux/ - This package has been in main since the very early beginning of Ubuntu, so never got the chance to get a proper MIR. - This was sparked when the `bin:util-linux` has started to depend on `bin:liblastlog2-2`, which was in Universe. `liblastlog2-2` was nicely handled by @paelzer under the "Renamed or re-organized sources" condition (https://canonical-ubuntu-project.readthedocs-hosted.com/MIR/mir-rereview/#renamed-or-reorganized-sources). - This MIR still makes sense to me, given that `util-linux` provides many very important binaries, among which many of them are `suid`, and is one the `Essential` packages shipped in absolutely every form Ubuntu can take. + This package has been in main since the very early beginning of Ubuntu, so never + got the chance to get a proper MIR. + This was sparked when the `bin:util-linux` has started to depend on + `bin:liblastlog2-2`, which was in Universe. `liblastlog2-2` was nicely + handled by @paelzer under the "Renamed or re-organized sources" condition. + This MIR still makes sense to me, given that `util-linux` provides many + very important binaries, among which many of them are `suid`, and is one the + `Essential` packages shipped in absolutely every form Ubuntu can take. ** Changed in: util-linux (Ubuntu) Status: Incomplete => New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to util-linux in Ubuntu. https://bugs.launchpad.net/bugs/2113961 Title: [MIR] liblastlog2-2 Status in util-linux package in Ubuntu: New Bug description: [Availability] The package src:util-linux is already in Ubuntu main. The package src:util-linux build for the architectures it is designed to work on. It currently builds and works for architectures: amd64, arm64, armhf, i386, ppc64el, riscv64, s390x Link to package https://launchpad.net/ubuntu/+source/util-linux [Rationale] See previous rational below for what actually sparked this MIR. Now that `bin:liblastlog2-2` has been promoted and everything is unblocked, the rationale becomes as simple as an ask for a re-review for one of the `Essential` packages, shipping, among other things, a few `suid` binaries in absolutely every form Ubuntu can take. https://canonical-ubuntu-project.readthedocs-hosted.com/MIR/mir-rereview/#opt-in-re-review Original rationale: Okay, it seems the MIR template doesn't apply well for this use-case, because it more or less assumes that the MIR is about a source package that is currently in universe. In the current situation, only an existing binary package needs to be promoted, from a source package already in main. I'll do my best to adapt the template and provide a good rational. - bin:liblastlog2-2 is provided by src:util-linux, and was already there in plucky/universe. - The package src:util-linux is generally useful for a large part of our user base: it provides the bin:util-linux package, that is even flagged as `Essential: yes`. This is the package providing, among many other things, the `su`, `fsck`, `flock`, or `mkswap` binaries, all mostly essential to any system (random selection of important commands to give a quick example). - The package bin:liblastlog2-2 is a new runtime dependency of package bin:util-linux that we already support. - The binary packages liblastlog2-2 needs to be in main to have the latest merge of util-linux migrate from questing-proposed to questing. - All other binary packages currently in universe built by src:util-linux should remain in universe. - The package bin:liblastlog2-2 is required in Ubuntu main no later than somewhere in July due to some partners requiring patches to be SRU'd to Noble, and thus needing the package to migrate from -proposed (even though it's not a hard block from the SRU team, according to what I've red on Matrix recently). [Security] - Obviously, util-linux has had some security issues in the past (although not that much): - https://ubuntu.com/security/cves?package=util-linux - https://security-tracker.debian.org/tracker/source-package/util-linux - Those issues seems to be handled correctly in both Ubuntu and Debian: - https://ubuntu.com/security/CVE-2024-28085 - https://security-tracker.debian.org/tracker/CVE-2024-28085 - https://security-tracker.debian.org/tracker/CVE-2021-37600 - There are countless binaries in sbin, but I'm fairly confident taking them out is a big plan of its own to still have a working system. - There are just a couple systemd units: - fstrim.{service,timer}: Discard unused filesystem blocks once a week - lastlog2-import.service: Import lastlog data into lastlog2 database - run only once in some particular situations to handle a data migration - About common isolation/risk-mitigation: - I'm not sure anything in util-linux is opening privileged ports. - I know some binaries are dropping privileges. - Going much further on that topic would be a full audit, for which I unfortunately don't really have time and competency for. I hope that's okay. - Packages does not contain extensions to security-sensitive software (filters, scanners, plugins, UI skins, ...) [Quality assurance - function/usage] - The package works well right after install [Quality assurance - maintenance] - The package is maintained well in Debian/Ubuntu/Upstream and does not have too many, long-term & critical, open bugs - Ubuntu https://bugs.launchpad.net/ubuntu/+source/util-linux/+bugs?orderby=-importance&start=0 - Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=util-linux - Upstream https://github.com/util-linux/util-linux/issues - Obviously this package has tons of bugs opened, but at the same time, it has a lot of activity, and is well maintained upstream, in Debian, and in Ubuntu, just because of its central position in any Linux system. - The package does not deal with exotic hardware we cannot support [Quality assurance - testing] - The package runs a test suite on build time, if it fails it makes the build fail, link to build log TBD - The package runs an autopkgtest, and is currently passing on all architectures but i386: https://autopkgtest.ubuntu.com/packages/util-linux - The package does have not failing autopkgtests right now [Quality assurance - packaging] - debian/watch is present and works - debian/control defines a correct Maintainer field - This package does not yield massive lintian Warnings, Errors - Recent build: https://launchpad.net/ubuntu/+source/util-linux/2.41-4ubuntu2/+build/30908305 - Lintian overrides are present, but ok because most are well commented, and the rest is pretty obvious, like highly privileged binaries. - This package does not rely on obsolete or about to be demoted packages. - The package will be installed by default, but does not ask debconf questions higher than medium - Packaging is quite complex, but I'm not sure how much of a choice we have. Good thing is that this package is equally important in Debian, so it will very likely keep being maintained. [UI standards] - Application is end-user facing, Translation is present, via standard intltool/gettext. See `configure` for `libintl` and `gettext`. - End-user applications without desktop file, not needed because it only ships CLI tools. [Dependencies] - No further depends or recommends dependencies that are not yet in main [Standards compliance] - This package correctly follows FHS and Debian Policy. [Maintenance/Owner] - The owning team will be debcrafters-packages and I have their acknowledgement for that commitment - The future owning team is already subscribed to the package. - This does not use static builds. - This does not use vendored code - This package is not rust based - The package has been built within the last 3 months in the archive - Build link on launchpad: https://launchpad.net/ubuntu/+source/util-linux/2.41-4ubuntu2 [Background information] The Package description explains the package well Upstream Name is `util-linux` Link to upstream project: https://github.com/util-linux/util-linux/ This package has been in main since the very early beginning of Ubuntu, so never got the chance to get a proper MIR. This was sparked when the `bin:util-linux` has started to depend on `bin:liblastlog2-2`, which was in Universe. `liblastlog2-2` was nicely handled by @paelzer under the "Renamed or re-organized sources" condition. This MIR still makes sense to me, given that `util-linux` provides many very important binaries, among which many of them are `suid`, and is one the `Essential` packages shipped in absolutely every form Ubuntu can take. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/2113961/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
