[Bug 2110879] Re: [MIR] coreutils-from

Christian Ehrhardt 2110879 at bugs.launchpad.net
Fri May 23 09:17:09 UTC 2025 

Review for Source Package: coreutils-from

[Summary]

Thanks for reaching out, this could as well have been a part of coreutils
and we'd never have seen it - appreciated.

MIR team ACK

This does not need a security review

List of specific binary packages to be promoted to main:
 - coreutils
 - coreutils-from-gnu

Specific binary packages built, but NOT to be promoted to main:
 - coreutils-from-uutils
 - coreutils-from-toybox
 - coreutils-from-busybox

These are ok to follow as their dependencies are resolved in individual MIRs.
Functionally this already provides all users need to experiment with either of
them, but would not yet change what is supported.

Recommended TODOs:
#1 - autopkg tests would be perfect here to check if all continues to work
     no matter which of the coreutils implementers get updated. I agree that the
     actual function is and should stay in the respective packages. But I'd
     recommend to consider adding a test for the switching between different
     sets of redirection. That has functionality in itself (are all tools
     reachable and functional after switching, avoid dangling symlinks, ...)
     and is the place that cares about conisstency between them (are all
     behaving comparable enough).

[Rationale, Duplication and Ownership]
There is no other package in main providing the same functionality.
In some way it is an enabler to allow different packages that have the same,
but in a constructive way going forward, nothing that the MIR rules are about.

A team is committed to own long term maintenance of this package.

The rationale given in the report seems valid and useful for Ubuntu

[Dependencies]
OK:
- no other Dependencies to MIR due to this (and everyone is aware about the
  further deps once we add more)
- no -dev/-debug/-doc packages that need exclusion
- No dependencies in main that are only superficially tested requiring
  more tests now.

Problems: None

[Embedded sources and static linking]
OK:
- no embedded source present
- no static linking
- does not have unexpected Built-Using entries
- not a go package, no extra constraints to consider in that regard
- not a rust package, no extra constraints to consider in that regard

To be fair it doesn't have source at all :-)

Problems: None

[Security]
OK:
- history of CVEs does not look concerning (it is new, but given the
  function I doubt it would be very bad)
- does not run a daemon as root
- does not use webkit1,2
- does not use lib*v8 directly
- does not parse data formats (files [images, video, audio,
  xml, json, asn.1], network packets, structures, ...) from
  an untrusted source.
- does not expose any external endpoint (port/socket/... or similar)
- does not process arbitrary web content
- does not use centralized online accounts
- does not integrate arbitrary javascript into the desktop
- does not deal with system authentication (eg, pam), etc)
- does not deal with security attestation (secure boot, tpm, signatures)
- does not deal with cryptography (en-/decryption, certificates,
  signing, ...)
- this makes appropriate use of established risk mitigation features (none
  as it is not acting, but only redirecting)

Being a coreutils mapper it indirectly deals with some very central system
functions, but all the actual code is in the related packges depended on by
coreutils-from.

Problems: None

[Common blockers]
OK:
- does not FTBFS currently
- This does not need special HW for build or test
- no new python2 dependency
- Python package, but using dh_python
- Go package, but using dh-golang

Problems:
- does not have a test suite that runs at build time
- does not have a non-trivial test suite that runs as autopkgtest

Given what the package does this isn't a requirement. But let me be honest
switching between those is a quite complex thing that can go wrong. I'm tempted
to suggest that adding a test here would be the perfect spot to ensure that
switching between the alternative works smoothly and behaves similar enough.
It isn't gating IMHO, but I'll add it as recommended task.

[Packaging red flags]
OK:
- Ubuntu does not carry a delta (it is native in ubuntu)
- symbols tracking not applicable for this kind of code.
- debian/watch is not present but also not needed (native)
- Upstream/Ubuntu update history is non-existing (new and therefore ok)
- the current release is packaged (could that ever be different for ubuntu
  native?)
- promoting this does not seem to cause issues for MOTUs that so far
  maintained the package
- no massive Lintian warnings
- debian/rules is rather clean
- It is not on the lto-disabled list

Problems: None

[Upstream red flags]
OK:
- no Errors/warnings during the build
- no incautious use of malloc/sprintf (for once I'm rather sure :-) )
- no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH
- no use of user nobody
- no use of setuid / setgid
- no important open bugs (crashers, etc) in Debian or Ubuntu
- no dependency on webkit, qtwebkit or libseed
- not part of the UI for extra checks
- no translation present, but none needed for this case

Problems: None

** Changed in: coreutils-from (Ubuntu)
       Status: New => In Progress

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to coreutils-from in Ubuntu.
https://bugs.launchpad.net/bugs/2110879

Title:
  [MIR] coreutils-from

Status in coreutils-from package in Ubuntu:
  In Progress

Bug description:
  The source package and coreutils binary already ended up in main as
  coreutils binary used to be in main but moved packages, but for sake
  of process let's do an MIR.

  [Availability]
  The package coreutils-from is already in Ubuntu universe.
  The package coreutils-from build for the architectures it is designed to work on.
  Link to package https://launchpad.net/ubuntu/+source/coreutils-from

  [Rationale]
  The package coreutils-from is required in Ubuntu main for enabling the
  switch to rust-coreutils as per https://discourse.ubuntu.com/t/carefully-but-purposefully-oxidising-ubuntu/56995/7

  It's a set of symlink farms, facilitating switching between providers.
  For the purpose of this MIR, we want to consider the gnu-coreutils one,
  well the mechanism for switching, the rust-coreutils we will do in the
  rust-coreutils MIR.

  [Security]
  - No CVEs/security issues in this software in the past
  - Binaries are no problem because they are symbolic links to separately
    reviewed coreutils providers.
  - Package does not install services, timers or recurring jobs

  - This is just symlink farms, so we don't have much security to keep in
    mind, the features are needed in the actual providers.

    For rust-coreutils we need to sort out the story of the multi-call
    binary vs AppArmor path-based profiles, but we'll leave that discussion
    to the rust-coreutils MIR.

  [Quality assurance - function/usage]
  - The package works well right after install

  [Quality assurance - maintenance]
  It is just symlink farms.

  [Quality assurance - testing]
  The `coreutils` packages upstream test suite continues running, coreutils
  are used everywhere, so bugs are easily noticed - for the default provider
  anyway.

  Once we enable coreutils-from-uutils as the default, we also need to
  continue running the GNU test suite against the GNU tools specifically.

  - The package does not run a test at build time because it's just a symlink farm;
    the actual providers run their test suites.
  - The package does not run an autopkgtest because the actual code providers run test suites
  - The package does have not failing autopkgtests right now

  [Quality assurance - packaging]
  - debian/watch is not present because it is a native package
  - debian/control defines a correct Maintainer field
  - Lintian overrides are present, but ok because they are only in the
    variants we don't want to MIR.

  - The package will be installed by default, but does not ask debconf
     questions
  - Packaging and build is easy:
     https://git.launchpad.net/~juliank/+git/coreutils-from/tree/debian?h=main

  [UI standards]
  These are questions for the actual implementations.

  [Dependencies]
  The default dependency is to the gnu-coreutils right now, we want that to
  migrate, then switch to rust-coreutils, we'll then MIR that.

  [Standards compliance]
  - This package correctly follows FHS and Debian Policy

  [Maintenance/Owner]
  - The owning team will be foundations-bugs and I have their acknowledgement for
    that commitment
  - This does not use static builds
  - This does not use vendored code
  - The package is new :D

  [Background information]
  https://discourse.ubuntu.com/t/carefully-but-purposefully-oxidising-ubuntu/56995/7
  https://discourse.ubuntu.com/t/migration-to-rust-coreutils-in-25-10/59708

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/coreutils-from/+bug/2110879/+subscriptions

More information about the foundations-bugs mailing list