[Bug 1993819] Re: [MIR] cargo, dh-cargo
Paulo Flabiano Smorigo
1993819 at bugs.launchpad.net
Thu Aug 31 14:22:11 UTC 2023
I reviewed cargo 0.68.0+ds0ubuntu1-0ubuntu1 as checked into lunar (mantic
version was not available at the time for this review). This shouldn't be
considered a full audit but rather a quick gauge of maintainability.
Cargo is the Rust package manager. Cargo downloads your Rust package's
dependencies, compiles your packages, makes distributable packages, and uploads
them to crates.io, the Rust community's package registry. Cargo has been
written in Rust and it's an important tool for any program that uses this
language.
- CVE History
- CVE-2022-36113 (low): Fixed in 0.67.0
- CVE-2022-36114 (low): Fixed in 0.67.0
- CVE-2022-46176 (medium): Fixed in 0.67.0
- CVE-2019-16760 (medium): Fixed in 0.26.0
- Build-Depends
- Building tools: debhelper, dpkg-dev, pkg-config
- Rust dependencies: rustc, libstd-rust-dev, dh-cargo
- Python 3 for some helper scripts
- Other dependencies: libcurl, libssh, libgit, libhttp-parser, libssl, zlib1g
- pre/post inst/rm scripts
- none
- init scripts
- none
- systemd units
- none
- dbus services
- none
- setuid binaries
- none
- binaries in PATH
- cargo executable in /usr/bin
- scripts in /usr/share/cargo/scripts
- sudo fragments
- none
- polkit files
- none
- udev rules
- none
- unit tests / autopkgtests
- Good amount of integration tests located in the testsuite directory
- cron jobs
- none
- Build logs
- Some warnings or unused import or variable
- Some intra-doc link fails that cause some "warning: unresolved link to..."
- Some warnings about warning future incompatibility:
"this is accepted in the current edition (Rust 2015) but is a hard error in Rust 2021!"
- No errors logs
- Processes spawned
- none
- Memory management
- Rust has the memory managed through a system of ownership with a set of
rules that the compiler checks. The only exception is when the code uses
the unsafe approach, witch happens a few time (see semgrep). On the good
side, all those cases seems fine, without any major concern.
- During the research an open issue was found about a possible memory leak
while using cargo inside a docker container. It seems to be a problem with
libgit and there is a work around for it:
https://github.com/rust-lang/cargo/issues/10583
- File IO
- Seems safe. Nothing concerning found.
- Logging
- Seems safe. It uses an external library for logging (inside vendor/log).
- Environment variable usage
- Seems safe.
- Use of privileged functions
- none
- Use of cryptography / random number sources etc
- Cargo relies on RustCrypto (https://github.com/RustCrypto/utils) to
do the cryptography. Seems to be a safe and well maintaned library.
- Use of temp files
- Low usage. Seems safe.
- Use of networking
- Use mainly curl (vendor/{curl,curl-sys,git2-curl}) to handle packages
downloads.
- Also use an external library to handle sockets (vender/socket2).
- Other vendor, like libc, winapi, rustix, io-lifetimes, url,
linux-raw-sys, have network functions but could identify if they
are used by cargo.
- Use of WebKit
- none
- Use of PolicyKit
- none
- Any significant cppcheck results
- none
- Any significant Coverity results
- Coverity doesn't support rust.
- Any significant shellcheck results
- Found some minor issues inside vcpkg vendor. Nothing significant.
- Any significant bandit results
- Found some minor issues inside idna and unicode-normalization vendor.
Nothing significant.
- Any significant govulncheck results
- none
- Any significant Semgrep results
- Some usage of "unsafe" method in the main tree and also in vendors. It
seems necessary to do those kind of operations but also disable rust
protections that avoids memory leaks out out of bound problems.
- See semgrep-.txt files for more info.
Cargo is a very active project meaning that the code changes a lot. There are
new releases almost monthly. This is good because bugs and security issues are
fixed in a short time but also makes it hard to maintain when we reach the
point where we need to maintain old versions.
Also Cargo uses "external" code a lot. Inside vendor directory there are 160
projects that Cargo relies on. Most of those source seems well maintained but
it's hard to tell given the amount of code.
Given the comments above, Cargo is a good project from a security standpoint
so, as result, the Security team ACK for promoting cargo to main.
** Bug watch added: github.com/rust-lang/cargo/issues #10583
https://github.com/rust-lang/cargo/issues/10583
** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2019-16760
** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2022-36113
** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2022-36114
** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2022-46176
** Changed in: cargo (Ubuntu)
Status: Incomplete => In Progress
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is a bug assignee.
https://bugs.launchpad.net/bugs/1993819
Title:
[MIR] cargo, dh-cargo
Status in cargo package in Ubuntu:
In Progress
Status in dh-cargo package in Ubuntu:
In Progress
Status in rustc package in Ubuntu:
New
Bug description:
[Availability]
The packages dh-cargo and cargo are already in Ubuntu universe.
The packages build for the architectures they are designed to work on,
They currently build and works for architectures:
* amd64
* arm64
* armhf
* i386
* ppc64el
* riscv64
* s390x
Link to packages:
https://launchpad.net/ubuntu/+source/cargo
https://launchpad.net/ubuntu/+source/dh-cargo
The cargo-doc package is *not* part of the MIR.
[Rationale]
The packages cargo and dh-cargo are required in Ubuntu main as the Rust
programming language is gaining in popularity. cargo is the standard
build tool and package manager for the ecosystem, and dh-cargo is the
debhelper plugin to more easily build new packages.
Note that the huge majority of our users will not use these packages,
their purpose is to be a build-dependency for other packages. In
particular, it is not particularly expected at this stage that those of
our users that are Rust developers, which usually rely on their
toolchain being managed in their $HOME by the `rustup` tool.
[Security]
cargo has 3 security vulnerabilities recorded:
* https://nvd.nist.gov/vuln/detail/CVE-2019-16760
A new feature to apply a local name to a dependency can lead to the
wrong package being used when using older toolchains. This didn't
apply to Ubuntu since we upgrade the Rust toolchain wholesale.
* https://nvd.nist.gov/vuln/detail/CVE-2022-36114
DoS on disk space via crafted dependency (zip-bomb). Low priority
since cargo *by design* can execute arbitrary code from dependencies
(build scripts & procedural macros). Unpatched in current Ubuntu.
* https://nvd.nist.gov/vuln/detail/CVE-2022-36113
Crafted dependency can lead to 2 byte overwrite of arbitrary files.
Low priority (see above). Unpatched in current Ubuntu.
There is an official Rust Security working group that curates a database
of security issues within the Rust ecosystem, including cargo:
https://github.com/rustsec/advisory-db
There are no history of known security issues with dh-cargo.
- no `suid` or `sgid` binaries
- no executables in `/sbin` and `/usr/sbin`
- Package does not install services, timers or recurring jobs
- Packages does not open privileged ports (ports < 1024)
- Packages does not contain extensions to security-sensitive software
(filters, scanners, plugins, UI skins, ...)
Note however that in typical use outside of packaging, building a
project with cargo involves executing code that has been downloaded from
crates.io or any other configured registry: cargo builds and executes
the `build.rs` file for any pre-compilation task (a bit like a
Makefile), and any use of a proc macro implies building and running a
standalone binary to transform the input token stream. While there are
leads for sandboxing the latter (using WASM, for instance), the former
needs by definition broad access to the system, i.e. to check installed
libraries.
[Quality assurance - function/usage]
The packages work well right after install, one can easily create a
simple Rust project and run it.
[Quality assurance - maintenance]
The packages do not deal with exotic hardware we cannot support
[Quality assurance - testing]
The cargo package runs a test suite at build time, and rebuilds itself
(including its test suite) as autopkgtest.
dh-cargo doesn't have builtin tests, and only has one autopkgtest for
testing our delta (tracking vendored dependencies). However, all Rust
packages built using dh-cargo have a Test-Trigger on it and their tests
are usually a rebuild of the package.
[Quality assurance - packaging]
debian/watch is present and works, dh-cargo is a native package.
You'll find attached the build logs of src:cargo along with a lintian
run. src:cargo has an override file for the source package, for
relatively minor warnings. I chose to willingly ignore the MPL-2.0+ vs
MPL-2.0 warnings, as adding a full-blown copy of the same license for
the sake of an "or later" statement seemed overkill.
dh-cargo is lintian-clean.
These packages do not rely on obsolete or about to be demoted
packages.
The packages will not be installed by default.
dh-cargo's packaging is fairly straightforward.
src:cargo's packaging is more complex. The rules file itself is fairly
easy to grap, but the very tricky part is the vendor tarball generation:
https://git.launchpad.net/~canonical-foundations/ubuntu/+source/cargo/tree/debian/rules?h=merge-0.62
https://git.launchpad.net/~canonical-foundations/ubuntu/+source/cargo/tree/debian/README.source?h=merge-0.62
Because of this, security patching of the vendored dependencies should
be done as a quilt patch to src:cargo rather than attempting to
regenerate the vendored deps with a point-release version of the
dependency.
[UI standards]
I do not believe there's a need for translation for these applications
given the stated purpose for having them in main.
[Dependencies]
All the packages dependencies are either in main or are the subject of
their own MIRs:
https://bugs.launchpad.net/ubuntu/+source/libssh2/+bug/1991650
https://bugs.launchpad.net/ubuntu/+source/libgit2/+bug/1990655
[Standards compliance]
cargo violates the Debian Policy on vendored dependencies but is
otherwise fairly conform.
dh-cargo conforms to the Debian Policy.
[Maintenance/Owner]
Owning Team will be Foundations
Team is subscribed to all packages.
cargo uses static linking for the Rust dependencies, but otherwise links
against system dependencies on the devel release. It is however possible
that some of its dependencies (notably libgit2) might be re-vendored
when backporting new versions to previous releases, as is already the
case for Jammy and before, as newer versions regularly bump their
bindings requirements and backporting those isn't always
straightforward.
Regarding the Rust dependencies, the version in the archive currently
does *not* track them in either Cargo.lock or the
XS-Vendored-Sources-Rust field but an upload is pending to remedy that
(using the Sources field). Waiting on the archive reopening, this new
version is available in a PPA:
https://launchpad.net/~schopin/+archive/ubuntu/test-
ppa/+sourcepub/14008184/+listing-archive-extra
[Background information]
The Package descriptions explains the package well.
Upstream is developed by the
Cargo team, under the umbrella of the Rust Foundation
Link to upstream project: https://www.rust-lang.org/
[Previous work]
There was a previous MIR opened against these packages along with rustc.
Given the high volume of discussion for that first package and the time
passed, I opted to open a fresh one instead. The previous MIR can be
found there:
https://bugs.launchpad.net/ubuntu/+source/rustc/+bug/1957932
In particular, a previous MIR review for cargo was done by didrocks:
https://bugs.launchpad.net/ubuntu/+source/rustc/+bug/1957932/comments/6
Most comments were addressed AFAICT, except for the copyright ones.
Regarding the libgit2-sys licensing, it pertains to the bindings, not
the libgit2 library itself, hence the different licensing. At the time,
the libgit2 sources were also embedded, hence the warning (and the error
in d/copyright).
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cargo/+bug/1993819/+subscriptions
More information about the foundations-bugs
mailing list