Comment 0 for bug 1993819
Revision history for this message
| Simon Chopin (schopin) wrote MIR: cargo, dh-cargo | #0 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
1b1ed1a
(Get the code!)
[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:/
https:/
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:/
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:/
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:/
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:/
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:/
https:/
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:/
https:/
[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-
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:/
[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:/
[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:/
In particular, a previous MIR review for cargo was done by didrocks:
https:/
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).