debcrafters-packages team mailing list archive

[Skia <2113961@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

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.
- 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]
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

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

[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.

[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

[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

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

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

[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

** Affects: util-linux (Ubuntu)
     Importance: Undecided
         Status: New

** Attachment added: "lintian --pedantic"
   https://bugs.launchpad.net/bugs/2113961/+attachment/5883437/+files/lintian.pedantic

-- 
You received this bug notification because you are a member of
Debcrafters 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:
  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.
  - 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]
  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

  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

  [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.

  [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

  [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

  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

  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

  [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

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/2113961/+subscriptions