Comment 21 for bug 1993819

Revision history for this message
Paulo Flabiano Smorigo (pfsmorigo) wrote :

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.