| 2022-10-24 16:49:37 |
Dan Bungert |
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). |
[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). |
|
