[Bug 2111815] Re: [MIR] rust-coreutils
Hlib Korzhynskyy
2111815 at bugs.launchpad.net
Wed Sep 3 21:55:55 UTC 2025
I reviewed rust-coreutils 0.1.0+git20250801.cf79675-0ubuntu1 as checked
into questing. This shouldn't be considered a full audit but rather a quick
gauge of maintainability.
rust-coreutils is a cross-platform reimplementation of GNU coreutils in
rust. It is designed to be a drop-in replacement for the GNU counterpart.
- CVE History
- None
- The upstream repository does not currently specify a way to report
security issues, should they arise. Creating a `SECURITY.md` file is
recommended for this.
- Build-Depends
- Normal build depends
- The package contains a lot of rust vendored libraries. These do seem
to be specified in debian/control. There is confirmation of
commitment by the owning team to provide updates for vendored code,
so this is not seen as an issue.
- pre/post inst/rm scripts
- This package itself does not seem to contain any pre/post inst/rm
scripts.
- init scripts
- None
- systemd units
- None
- dbus services
- None
- setuid binaries
- None
- binaries in PATH
- A single binary with many symlinks.
- The implications with AppArmor have already been discussed, but this
should still be considered.
- sudo fragments
- None
- polkit files
- None
- udev rules
- None
- unit tests / autopkgtests
- The application seems to have a rather extensive unit test suite. No
autopkgtests, but this has also already been discussed in the MIR
report.
- cron jobs
- None
- Build logs
- Seems fine.
- Processes spawned
- The program seems to spawn a process as new commands for each core
utility.
- Some utilities seem to also create shell processes as part of their
operations, such as `split`. They seem to be created in a safe way.
- Some processes spawned as part of tests.
- Memory management
- While the program is written in rust, memory management inside specific
blocks such as unsafe wrappers seems to be fine.
- File IO
- The utilities seem to handled File IO properly. Due to certain
limitations, file management seems to have been divided between special
files such as FIFO, pipes, among others. This seems to be handled
properly as well.
- There seem to be certain limitations to the library being used for
CLI operations (clap), but the workarounds seem to be properly
documented with comments, and seem to be handled fine overall.
- One potentially problematic aspect to be considered is the
inconsistency in handling non-UTF-8 characters. Some utilities seem to
handle non-UTF-8 characters properly, while others do not seem to
handle these. It would be nice if the proper support for these
characters be added, but this does seem to be on the radar of upstream
developers.
- There also seem to be small inconsistencies between some commands.
- For example, `base32`/`base64`/... is not decoded with rust-coreutils
at all if the formatting is not correct, while the GNU counterpart
will decode it until reaching the incorrect formatting.
- Upstream seems to be aware of this particular issue.
- https://github.com/uutils/coreutils/issues/5698
- https://github.com/uutils/coreutils/issues/6008
- Other issues are also reported on GitHub, and upstream seems to
respond to issues well.
- There is also extensive usage of buffers/chunks to make operations when
it comes to file IO. Usage seems to be fine there as well overall.
- Logging
- The utilities seem to handle logging properly. Consistency with GNU is
prioritized, same with returned status codes upon exit.
- Environment variable usage
- Environment variable usage seems to be fine. Checks POSIXLY_CORRECT
in some cases to comply with POSIX. Some utilities also use env
variables (such as `env`) and they seem to be handled fine.
- Use of privileged functions
- Usage seems to be fine. When used in unsafe blocks, they are commented
with the special `SAFETY` keyword to justify their usage, although this
is not always the case. Overall, however, no issues were encountered.
- Use of cryptography / random number sources etc
- Usage seems to be fine. For example, in `shred` StdRng::from_os_rng is
used, and the RNG usage seems to be proper in other cases.
- Use of temp files
- Temp file usage also seems to be fine. `mktemp` implementation seems to
be fine as well
- Use of networking
- None
- Use of WebKit
- None
- Use of PolicyKit
- None
- Any significant cppcheck results
- None
- Any significant Coverity results
- Rust is not supported by Coverity at the time of writing.
- Quite a few vulnerabilities were detected in a vendored crate,
specifically rust-vendor/onig_sys/oniguruma/src/regexec.c
- As the code specifically handles regex, it is rather complex, and
cannot be looked at more in depth due to time constraints. It is
recommended that the usage of `regexec` is analyzed within uutils,
to see what specifically could be affected in that regard.
- Vulnerabilities identified by Coverity seem to be mostly memory
related such as overflows/null pointer dereference.
- Any significant shellcheck results
- None
- Any significant bandit results
- None, just some test related low severity.
- Any significant govulncheck results
- N/A
- Any significant Semgrep results
- None
As of time of writing, the project seems to be in a fine state.
Upstream maintainers seem to be verified, and the code seems to be clean
and maintainable. There were some inconsistencies in code usage (such as
not all `unsafe` blocks having `SAFETY` comments), but it seems like the
project uses proper safety measures, QA tools like CI pipelines, and proper
testing. In many cases, code comments were also very clear and concise,
while also providing example code samples in some cases.
The upstream repository does seem to contain quite a few issues and open
pull requests, but this is to be expected due to the current focus on the
project, as well as its popularity.
Security team ACK for promoting rust-coreutils to main
** Bug watch added: github.com/uutils/coreutils/issues #5698
https://github.com/uutils/coreutils/issues/5698
** Bug watch added: github.com/uutils/coreutils/issues #6008
https://github.com/uutils/coreutils/issues/6008
** Changed in: rust-coreutils (Ubuntu)
Status: New => In Progress
** Changed in: rust-coreutils (Ubuntu)
Assignee: Ubuntu Security Team (ubuntu-security) => (unassigned)
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to rust-coreutils in Ubuntu.
https://bugs.launchpad.net/bugs/2111815
Title:
[MIR] rust-coreutils
Status in rust-coreutils package in Ubuntu:
In Progress
Bug description:
[Availability]
The package rust-coreutils is already in Ubuntu universe.
The package rust-coreutils build for the architectures it is designed to work on.
It currently builds and works for architectures: (all of them)
Link to package https://launchpad.net/ubuntu/+source/rust-coreutils
[Rationale]
- The package rust-coreutils is required in Ubuntu main for
strengthening product security, resilience, and safety by adopting
memory-safe replacements for core functionalities as outlined in
Jon Seager's post:
https://discourse.ubuntu.com/t/carefully-but-purposefully-oxidising-
ubuntu/56995
- The package rust-coreutils will generally be useful for a large part of
our user base as it will become the new default coreutils
[Security]
- No CVEs/security issues in this software in the past
- no `suid` or `sgid` binaries
- no executables in `/sbin` and `/usr/sbin`
[chroot used to be in sbin]
- Package does not install services, timers or recurring jobs
- Security has been kept in mind and common isolation/risk-mitigation
patterns are in place utilizing the following features:
This is using a memory-safe language, eliminating most memory safety
issue.
- Package does not expose any external endpoints
- 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
Particularly, when installing coreutils-from-uutils, which is to be the
default. On its own, this provides a single coreutils binary.
[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/rust-coreutils/+bug
- Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=rust-coreutils
- Upstream's bug tracker, e.g., GitHub Issues
- The package has important open bugs, listing them:
- Lots of coreutils still have some breakage which prevents the default
switch, I won't list them individually.
- 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
https://launchpadlibrarian.net/797298944/buildlog_ubuntu-questing-amd64.rust-coreutils_0.0.30-2ubuntu2_BUILDING.txt.gz
- The package does not run an autopkgtest because there are no additional
tests. It does trigger a whole bunch of packages; and of course the GNU
coreutils test suite gets triggerd by coreutils-from with coreutils-from-uutils
as the default coreutils provider.
[Quality assurance - packaging]
- debian/watch is not present, instead it has "cargo magic"
- debian/control defines a correct Maintainer field
- Please link to a recent build log of the package https://launchpadlibrarian.net/797298944/buildlog_ubuntu-questing-amd64.rust-coreutils_0.0.30-2ubuntu2_BUILDING.txt.gz
- Please attach the full output you have got from
`lintian --pedantic` as an extra post to this bug:
it's just:
W: rust-coreutils: bad-whatis-entry [usr/share/man/man1/rust-coreutils.1.gz]
W: rust-coreutils: debian-changelog-line-too-long [usr/share/doc/rust-coreutils/changelog.Debian.gz:9]
W: rust-coreutils: no-manual-page [usr/bin/coreutils]
aka rust-coreutils is the manpage for coreutils and it's a bit
weird.
- Lintian overrides are not present
- This package does not rely on obsolete or about to be demoted packages.
- This package has no python2 or GTK2 dependencies
- The package will be installed by default, but does not ask debconf
questions
- Packaging and build is easy, link to debian/rules
https://git.launchpad.net/ubuntu/+source/rust-coreutils/tree/debian/rules?h=ubuntu/questing-devel
The vendoring is the most part :D
[UI standards]
The situation is a bit more complex than the template allows for; coreutils
are *somewhat* user interfacing - for terminal users.
Translation support is being added, but sadly it uses "Fluent" which is
not compatible with Launchpad's translation service, which is going to need
some more work to see how we can translate from ftl to pot, produce po and
then translate back to ftl such that we can ship translations in language
packs.
[Dependencies]
- No further depends or recommends dependencies that are not yet in main
[Rust dependencies are vendored per Rust MIR policy]
[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
- I Suggest the owning team to be debcrafters-packages starting 26.10
- The team foundations is aware of the implications by a static build and
commits to test no-change-rebuilds and to fix any issues found for the
lifetime of the release (including ESM)
- The team foundations is aware of the implications of vendored code and (as
alerted by the security team) commits to provide updates and backports
to the security team for any affected vendored code for the lifetime
of the release (including ESM).
- This package uses vendored rust code tracked in Cargo.lock as shipped,
in the *source* package (it produces a single binary, no crates), refreshing
that code is outlined in debian/README.source
[FIXME: I don't have a README.source]
- This package is rust based and vendors all non language-runtime
dependencies
- The package has been built within the last 3 months in the archive
- Build link on launchpad: https://launchpad.net/ubuntu/+source/rust-coreutils/0.0.30-2ubuntu2
[Background information]
The Package description explains the package well
Upstream Name is coreutils (same as GNU one)
Link to upstream project https://github.com/uutils/coreutils
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rust-coreutils/+bug/2111815/+subscriptions
More information about the foundations-bugs
mailing list