| 2022-01-14 15:39:03 |
Simon Chopin |
bug |
|
|
added bug |
| 2022-01-14 15:40:23 |
Simon Chopin |
description |
[Availability]
The packages rustc and cargo are already in Ubuntu universe.
The packages build for the architectures they are designed to work on,
and are also built on platform with lesser upstream support, see
https://doc.rust-lang.org/nightly/rustc/platform-support.html for details.
They currently build and works for architectures:
* amd64
* arm64
* armhf
* i386
* ppc64el
* riscv64
* s390x
Link to packages:
https://launchpad.net/ubuntu/+source/rustc
https://launchpad.net/ubuntu/+source/cargo
[Rationale]
The packages rustc and cargo are required in Ubuntu main as the Rust programming
language is gaining in popularity, and those two packages are, respectively, its
main compiler implementation and its dedicated build tool (and dependency manager).
There are a few packages in main already that have partially switched to Rust
as their implementation language, and so rustc and cargo will be needed to keep
us in sync with their upstream. See for instance
https://bugs.launchpad.net/ubuntu/+source/mdevctl/+bug/1942394 and
https://lists.debian.org/debian-python/2021/12/msg00000.html
(python-cryptography is in main)
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 and rustc had 19 recorded security issues in the past, mostly in the Rust standard library
(1 affecting cargo):
https://nvd.nist.gov/vuln/search/results?form_type=Advanced&results_type=overview&search_type=all&isCpeNameSearch=false&cpe_vendor=cpe%3A%2F%3Arust-lang&cpe_product=cpe%3A%2F%3A%3Arust
All issues are usually handled promptly by the Rust team. However, the fixes
are rarely (if ever) backported to previous releases besides an occasional
1.X.1 point release for the latest stable.
There is an official Rust Security working group that curates a database of security
issues within the Rust ecosystem, including rustc/cargo:
https://github.com/rustsec/advisory-db
- 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, building a project with cargo+rustc involves
executing code that has been downloaded from crates.io: 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 dependency basically implies running arbitrary code (the macro) within
the execution context of rustc.
[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 packages both run a test suite on build time. However, the rustc test suite
does NOT make the build fail.
TODO: check with mwhudson *why*?
Neither package has any autopkgtests.
TODO: cargo autopkgtest that creates a new crate, adds a simple dependency
(anyhow is a good candidate, no transitive deps), vendors it, builds the binary
from the vendored crate, and runs it.
RULE: - If no build tests nor autopkgtests are included, and/or if the package
RULE: requires specific hardware to perform testing, the subscribed team
RULE: must provide a written test plan in a comment to the MIR bug, and
RULE: commit to running that test either at each upload of the package or
RULE: at least once each release cycle. In the comment to the MIR bug,
RULE: please link to the codebase of these tests (scripts or doc of manual
RULE: steps) and attach a full log of these test runs. This is meant to
RULE: assess their validity (e.g. not just superficial)
TODO: - The package can not be tested at build or autopktest time because <TBD>
TODO: to make up for that here <TBD> is a test plan/automation and example
TODO: test <TBD> (logs/scripts)
RULE: - In some cases a solution that is about to be promoted consists of
RULE: several very small libraries and one actual application uniting them
RULE: to achieve something useful. This is rather common in the go/rust space.
RULE: In that case often these micro-libs on their own can and should only
RULE: provide low level unit-tests. But more complex autopkgtests make no
RULE: sense on that level. Therefore in those cases one might want to test on
RULE: the solution level.
RULE: - Process wise MIR-requesting teams can ask (on the bug) for this
RULE: special case to apply for a given case, which reduces the test
RULE: constraints on the micro libraries but in return increases the
RULE: requirements for the test of the actual app/solution.
RULE: - Since this might promote micro-lib packages to main with less than
RULE: the common level of QA any further MIRed program using them will have
RULE: to provide the same amount of increased testing.
TODO: - This package is minimal and will be tested in a more wide reaching
TODO: solution context <TBD>, details about this testing are here <TBD>
[Quality assurance - packaging]
debian/watch is present and works
RULE: - It is often useful to run `lintian --pedantic` on the package to spot
RULE: the most common packaging issues in advance
RULE: - Non-obvious or non-properly commented lintian overrides should be
RULE: explained
rustc yields quite a bit of lintian output, but they seem mostly harmless.
https://lintian.debian.org/sources/rustc
There are lintian overrides present, but those are usually justified in the override
files themselves.
cargo is a bit more tame on the warning fronts
https://lintian.debian.org/sources/cargo
It has an override file for the source package, for relatively minor warnings.
These packages does not rely on obsolete or about to be demoted packages.
The packages will not be installed by default
The packaging is fairly complex, especially in the case of rustc. The crux of
the complexity can be attributed to the boostrapping issue, as well as the need
to deal with vendored dependencies. There is extensive documentation within the
debian/ directories to help with the difficulties, and a lot of things have been
automated in scripts living in debian/scripts/*
Note that originally, the upstream tarball for rustc includes the sources for
cargo as well as its vendored dependencies, but the Debian Rust team chose to
split it out in its own package.
[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]
The packages have quite a few vendored dependencies. However, their non-vendored
dependencies are all in main, as well as the build-dependencies, assuming for the purpose
of this analysis that src:rustc is in main.
[Standards compliance]
The packages violate the Debian Policy on vendored
dependencies, with at least copies of LLVM and libgit2 (as a delta to Debian)
TODO: check for more C dependencies that might have escaped my notice.
[Maintenance/Owner]
Owning Team will be Foundations
Team is not yet, but will subscribe to the package before promotion
Both packages use static linking for the Rust dependencies, as well as any
vendored C dependency (i.e. libgit2 and LLVM)
TODO: check what's what with LLVM, status unclear?
rustc uses vendored rust code tracked in Cargo.lock as shipped, in the package,
refreshing that code works via `cargo update ...` + cargo vendor
cargo has a different process, documented in debian/README.source.
TODO: actually try to update a dependency in cargo using the debian/README.source,
which are not that clear.
[Background information]
The Package descriptions explains the package well
Upstream Name is developped by the Rust Compiler team and the Cargo team, under
the umbrella of the Rust Foundation
Link to upstream project: https://www.rust-lang.org/ |
[Availability]
The packages rustc and cargo are already in Ubuntu universe.
The packages build for the architectures they are designed to work on,
and are also built on platform with lesser upstream support, see
https://doc.rust-lang.org/nightly/rustc/platform-support.html for details.
They currently build and works for architectures:
* amd64
* arm64
* armhf
* i386
* ppc64el
* riscv64
* s390x
Link to packages:
https://launchpad.net/ubuntu/+source/rustc
https://launchpad.net/ubuntu/+source/cargo
[Rationale]
The packages rustc and cargo are required in Ubuntu main as the Rust programming
language is gaining in popularity, and those two packages are, respectively, its
main compiler implementation and its dedicated build tool (and dependency manager).
There are a few packages in main already that have partially switched to Rust
as their implementation language, and so rustc and cargo will be needed to keep
us in sync with their upstream. See for instance
https://bugs.launchpad.net/ubuntu/+source/mdevctl/+bug/1942394 and
https://lists.debian.org/debian-python/2021/12/msg00000.html
(python-cryptography is in main)
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 and rustc had 19 recorded security issues in the past, mostly in the Rust standard library
(1 affecting cargo):
https://nvd.nist.gov/vuln/search/results?form_type=Advanced&results_type=overview&search_type=all&isCpeNameSearch=false&cpe_vendor=cpe%3A%2F%3Arust-lang&cpe_product=cpe%3A%2F%3A%3Arust
All issues are usually handled promptly by the Rust team. However, the fixes
are rarely (if ever) backported to previous releases besides an occasional
1.X.1 point release for the latest stable.
There is an official Rust Security working group that curates a database of security
issues within the Rust ecosystem, including rustc/cargo:
https://github.com/rustsec/advisory-db
- 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, building a project with cargo+rustc involves
executing code that has been downloaded from crates.io: 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 dependency basically implies running arbitrary code (the macro) within
the execution context of rustc.
[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 packages both run a test suite on build time. However, the rustc test suite
does NOT make the build fail.
TODO: check with mwhudson *why*?
Neither package has any autopkgtests.
TODO: cargo autopkgtest that creates a new crate, adds a simple dependency
(anyhow is a good candidate, no transitive deps), vendors it, builds the binary
from the vendored crate, and runs it.
[Quality assurance - packaging]
debian/watch is present and works
rustc yields quite a bit of lintian output, but they seem mostly harmless.
https://lintian.debian.org/sources/rustc
There are lintian overrides present, but those are usually justified in the override
files themselves.
cargo is a bit more tame on the warning fronts
https://lintian.debian.org/sources/cargo
It has an override file for the source package, for relatively minor warnings.
These packages does not rely on obsolete or about to be demoted packages.
The packages will not be installed by default
The packaging is fairly complex, especially in the case of rustc. The crux of
the complexity can be attributed to the boostrapping issue, as well as the need
to deal with vendored dependencies. There is extensive documentation within the
debian/ directories to help with the difficulties, and a lot of things have been
automated in scripts living in debian/scripts/*
Note that originally, the upstream tarball for rustc includes the sources for
cargo as well as its vendored dependencies, but the Debian Rust team chose to
split it out in its own package.
[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]
The packages have quite a few vendored dependencies. However, their non-vendored
dependencies are all in main, as well as the build-dependencies, assuming for the purpose
of this analysis that src:rustc is in main.
[Standards compliance]
The packages violate the Debian Policy on vendored
dependencies, with at least copies of LLVM and libgit2 (as a delta to Debian)
TODO: check for more C dependencies that might have escaped my notice.
[Maintenance/Owner]
Owning Team will be Foundations
Team is not yet, but will subscribe to the package before promotion
Both packages use static linking for the Rust dependencies, as well as any
vendored C dependency (i.e. libgit2 and LLVM)
TODO: check what's what with LLVM, status unclear?
rustc uses vendored rust code tracked in Cargo.lock as shipped, in the package,
refreshing that code works via `cargo update ...` + cargo vendor
cargo has a different process, documented in debian/README.source.
TODO: actually try to update a dependency in cargo using the debian/README.source,
which are not that clear.
[Background information]
The Package descriptions explains the package well
Upstream Name is developed by the Rust Compiler team and the Cargo team, under
the umbrella of the Rust Foundation
Link to upstream project: https://www.rust-lang.org/ |
|
| 2022-01-14 15:44:19 |
Simon Chopin |
bug task added |
|
cargo (Ubuntu) |
|
| 2022-01-14 15:50:38 |
Simon Chopin |
cargo (Ubuntu): status |
New |
Incomplete |
|
| 2022-01-14 15:50:40 |
Simon Chopin |
rustc (Ubuntu): status |
New |
Incomplete |
|
| 2022-01-14 15:50:58 |
Simon Chopin |
bug |
|
|
added subscriber MIR approval team |
| 2022-01-18 16:43:27 |
Lukas Märdian |
summary |
MIR: rustc, cargo |
[MIR] rustc, cargo |
|
| 2022-01-25 14:46:12 |
Simon Chopin |
description |
[Availability]
The packages rustc and cargo are already in Ubuntu universe.
The packages build for the architectures they are designed to work on,
and are also built on platform with lesser upstream support, see
https://doc.rust-lang.org/nightly/rustc/platform-support.html for details.
They currently build and works for architectures:
* amd64
* arm64
* armhf
* i386
* ppc64el
* riscv64
* s390x
Link to packages:
https://launchpad.net/ubuntu/+source/rustc
https://launchpad.net/ubuntu/+source/cargo
[Rationale]
The packages rustc and cargo are required in Ubuntu main as the Rust programming
language is gaining in popularity, and those two packages are, respectively, its
main compiler implementation and its dedicated build tool (and dependency manager).
There are a few packages in main already that have partially switched to Rust
as their implementation language, and so rustc and cargo will be needed to keep
us in sync with their upstream. See for instance
https://bugs.launchpad.net/ubuntu/+source/mdevctl/+bug/1942394 and
https://lists.debian.org/debian-python/2021/12/msg00000.html
(python-cryptography is in main)
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 and rustc had 19 recorded security issues in the past, mostly in the Rust standard library
(1 affecting cargo):
https://nvd.nist.gov/vuln/search/results?form_type=Advanced&results_type=overview&search_type=all&isCpeNameSearch=false&cpe_vendor=cpe%3A%2F%3Arust-lang&cpe_product=cpe%3A%2F%3A%3Arust
All issues are usually handled promptly by the Rust team. However, the fixes
are rarely (if ever) backported to previous releases besides an occasional
1.X.1 point release for the latest stable.
There is an official Rust Security working group that curates a database of security
issues within the Rust ecosystem, including rustc/cargo:
https://github.com/rustsec/advisory-db
- 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, building a project with cargo+rustc involves
executing code that has been downloaded from crates.io: 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 dependency basically implies running arbitrary code (the macro) within
the execution context of rustc.
[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 packages both run a test suite on build time. However, the rustc test suite
does NOT make the build fail.
TODO: check with mwhudson *why*?
Neither package has any autopkgtests.
TODO: cargo autopkgtest that creates a new crate, adds a simple dependency
(anyhow is a good candidate, no transitive deps), vendors it, builds the binary
from the vendored crate, and runs it.
[Quality assurance - packaging]
debian/watch is present and works
rustc yields quite a bit of lintian output, but they seem mostly harmless.
https://lintian.debian.org/sources/rustc
There are lintian overrides present, but those are usually justified in the override
files themselves.
cargo is a bit more tame on the warning fronts
https://lintian.debian.org/sources/cargo
It has an override file for the source package, for relatively minor warnings.
These packages does not rely on obsolete or about to be demoted packages.
The packages will not be installed by default
The packaging is fairly complex, especially in the case of rustc. The crux of
the complexity can be attributed to the boostrapping issue, as well as the need
to deal with vendored dependencies. There is extensive documentation within the
debian/ directories to help with the difficulties, and a lot of things have been
automated in scripts living in debian/scripts/*
Note that originally, the upstream tarball for rustc includes the sources for
cargo as well as its vendored dependencies, but the Debian Rust team chose to
split it out in its own package.
[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]
The packages have quite a few vendored dependencies. However, their non-vendored
dependencies are all in main, as well as the build-dependencies, assuming for the purpose
of this analysis that src:rustc is in main.
[Standards compliance]
The packages violate the Debian Policy on vendored
dependencies, with at least copies of LLVM and libgit2 (as a delta to Debian)
TODO: check for more C dependencies that might have escaped my notice.
[Maintenance/Owner]
Owning Team will be Foundations
Team is not yet, but will subscribe to the package before promotion
Both packages use static linking for the Rust dependencies, as well as any
vendored C dependency (i.e. libgit2 and LLVM)
TODO: check what's what with LLVM, status unclear?
rustc uses vendored rust code tracked in Cargo.lock as shipped, in the package,
refreshing that code works via `cargo update ...` + cargo vendor
cargo has a different process, documented in debian/README.source.
TODO: actually try to update a dependency in cargo using the debian/README.source,
which are not that clear.
[Background information]
The Package descriptions explains the package well
Upstream Name is developed by the Rust Compiler team and the Cargo team, under
the umbrella of the Rust Foundation
Link to upstream project: https://www.rust-lang.org/ |
[Availability]
The packages rustc and cargo are already in Ubuntu universe.
The packages build for the architectures they are designed to work on,
and are also built on platform with lesser upstream support, see
https://doc.rust-lang.org/nightly/rustc/platform-support.html for details.
They currently build and works for architectures:
* amd64
* arm64
* armhf
* i386
* ppc64el
* riscv64
* s390x
Link to packages:
https://launchpad.net/ubuntu/+source/rustc
https://launchpad.net/ubuntu/+source/cargo
[Rationale]
The packages rustc and cargo are required in Ubuntu main as the Rust programming
language is gaining in popularity, and those two packages are, respectively, its
main compiler implementation and its dedicated build tool (and dependency manager).
There are a few packages in main already that have partially switched to Rust
as their implementation language, and so rustc and cargo will be needed to keep
us in sync with their upstream. See for instance
https://bugs.launchpad.net/ubuntu/+source/mdevctl/+bug/1942394 and
https://lists.debian.org/debian-python/2021/12/msg00000.html
(python-cryptography is in main)
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 and rustc had 19 recorded security issues in the past, mostly in the Rust standard library
(1 affecting cargo):
https://nvd.nist.gov/vuln/search/results?form_type=Advanced&results_type=overview&search_type=all&isCpeNameSearch=false&cpe_vendor=cpe%3A%2F%3Arust-lang&cpe_product=cpe%3A%2F%3A%3Arust
All issues are usually handled promptly by the Rust team. However, the fixes
are rarely (if ever) backported to previous releases besides an occasional
1.X.1 point release for the latest stable.
There is an official Rust Security working group that curates a database of security
issues within the Rust ecosystem, including rustc/cargo:
https://github.com/rustsec/advisory-db
- 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, building a project with cargo+rustc involves
executing code that has been downloaded from crates.io: 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 dependency basically implies running arbitrary code (the macro) within
the execution context of rustc.
[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 packages both run a test suite on build time. However, the rustc test suite
does NOT make the build fail.
TODO: check with mwhudson *why*?
Neither package has any autopkgtests.
TODO: cargo autopkgtest that creates a new crate, adds a simple dependency
(anyhow is a good candidate, no transitive deps), vendors it, builds the binary
from the vendored crate, and runs it.
[Quality assurance - packaging]
debian/watch is present and works
rustc yields quite a bit of lintian output, but they seem mostly harmless.
https://lintian.debian.org/sources/rustc
There are lintian overrides present, but those are usually justified in the override
files themselves.
cargo is a bit more tame on the warning fronts
https://lintian.debian.org/sources/cargo
It has an override file for the source package, for relatively minor warnings.
These packages does not rely on obsolete or about to be demoted packages.
The packages will not be installed by default
The packaging is fairly complex, especially in the case of rustc. The crux of
the complexity can be attributed to the boostrapping issue, as well as the need
to deal with vendored dependencies. There is extensive documentation within the
debian/ directories to help with the difficulties, and a lot of things have been
automated in scripts living in debian/scripts/*
Note that originally, the upstream tarball for rustc includes the sources for
cargo as well as its vendored dependencies, but the Debian Rust team chose to
split it out in its own package.
[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]
The packages have quite a few vendored dependencies. However, their non-vendored
dependencies are all in main, as well as the build-dependencies, assuming for the purpose
of this analysis that src:rustc is in main.
[Standards compliance]
The packages violate the Debian Policy on vendored
dependencies, with a copy of LLVM in rustc, and a copy of libgit2 (as a delta to Debian) in cargo.
Note that one can also find the sources for libcurl in src:rustc, but that's a leftover of the dependencies of cargo, which has been split out of src:rustc.
[Maintenance/Owner]
Owning Team will be Foundations
Team is not yet, but will subscribe to the package before promotion
Both packages use static linking for the Rust dependencies, as well as any
vendored C dependency (i.e. libgit2 and LLVM)
TODO: check what's what with LLVM, status unclear?
rustc uses vendored rust code tracked in Cargo.lock as shipped, in the package,
refreshing that code works via `cargo update ...` + cargo vendor
cargo has a different process, documented in debian/README.source.
TODO: actually try to update a dependency in cargo using the debian/README.source,
which are not that clear.
[Background information]
The Package descriptions explains the package well
Upstream Name is developed by the Rust Compiler team and the Cargo team, under
the umbrella of the Rust Foundation
Link to upstream project: https://www.rust-lang.org/ |
|
| 2022-01-26 10:41:19 |
Lukas Märdian |
rustc (Ubuntu): milestone |
|
ubuntu-22.04-beta |
|
| 2022-01-26 10:41:22 |
Lukas Märdian |
cargo (Ubuntu): milestone |
|
ubuntu-22.04-beta |
|
| 2022-01-26 10:41:24 |
Lukas Märdian |
rustc (Ubuntu): importance |
Undecided |
Critical |
|
| 2022-01-26 10:41:26 |
Lukas Märdian |
cargo (Ubuntu): importance |
Undecided |
Critical |
|
| 2022-01-26 10:49:18 |
Lukas Märdian |
rustc (Ubuntu): status |
Incomplete |
New |
|
| 2022-01-26 10:49:19 |
Lukas Märdian |
cargo (Ubuntu): status |
Incomplete |
New |
|
| 2022-02-01 15:48:26 |
Christian Ehrhardt |
rustc (Ubuntu): assignee |
|
Christian Ehrhardt (paelzer) |
|
| 2022-02-01 15:49:43 |
Christian Ehrhardt |
cargo (Ubuntu): assignee |
|
Didier Roche (didrocks) |
|
| 2022-02-01 18:01:50 |
Simon Chopin |
description |
[Availability]
The packages rustc and cargo are already in Ubuntu universe.
The packages build for the architectures they are designed to work on,
and are also built on platform with lesser upstream support, see
https://doc.rust-lang.org/nightly/rustc/platform-support.html for details.
They currently build and works for architectures:
* amd64
* arm64
* armhf
* i386
* ppc64el
* riscv64
* s390x
Link to packages:
https://launchpad.net/ubuntu/+source/rustc
https://launchpad.net/ubuntu/+source/cargo
[Rationale]
The packages rustc and cargo are required in Ubuntu main as the Rust programming
language is gaining in popularity, and those two packages are, respectively, its
main compiler implementation and its dedicated build tool (and dependency manager).
There are a few packages in main already that have partially switched to Rust
as their implementation language, and so rustc and cargo will be needed to keep
us in sync with their upstream. See for instance
https://bugs.launchpad.net/ubuntu/+source/mdevctl/+bug/1942394 and
https://lists.debian.org/debian-python/2021/12/msg00000.html
(python-cryptography is in main)
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 and rustc had 19 recorded security issues in the past, mostly in the Rust standard library
(1 affecting cargo):
https://nvd.nist.gov/vuln/search/results?form_type=Advanced&results_type=overview&search_type=all&isCpeNameSearch=false&cpe_vendor=cpe%3A%2F%3Arust-lang&cpe_product=cpe%3A%2F%3A%3Arust
All issues are usually handled promptly by the Rust team. However, the fixes
are rarely (if ever) backported to previous releases besides an occasional
1.X.1 point release for the latest stable.
There is an official Rust Security working group that curates a database of security
issues within the Rust ecosystem, including rustc/cargo:
https://github.com/rustsec/advisory-db
- 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, building a project with cargo+rustc involves
executing code that has been downloaded from crates.io: 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 dependency basically implies running arbitrary code (the macro) within
the execution context of rustc.
[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 packages both run a test suite on build time. However, the rustc test suite
does NOT make the build fail.
TODO: check with mwhudson *why*?
Neither package has any autopkgtests.
TODO: cargo autopkgtest that creates a new crate, adds a simple dependency
(anyhow is a good candidate, no transitive deps), vendors it, builds the binary
from the vendored crate, and runs it.
[Quality assurance - packaging]
debian/watch is present and works
rustc yields quite a bit of lintian output, but they seem mostly harmless.
https://lintian.debian.org/sources/rustc
There are lintian overrides present, but those are usually justified in the override
files themselves.
cargo is a bit more tame on the warning fronts
https://lintian.debian.org/sources/cargo
It has an override file for the source package, for relatively minor warnings.
These packages does not rely on obsolete or about to be demoted packages.
The packages will not be installed by default
The packaging is fairly complex, especially in the case of rustc. The crux of
the complexity can be attributed to the boostrapping issue, as well as the need
to deal with vendored dependencies. There is extensive documentation within the
debian/ directories to help with the difficulties, and a lot of things have been
automated in scripts living in debian/scripts/*
Note that originally, the upstream tarball for rustc includes the sources for
cargo as well as its vendored dependencies, but the Debian Rust team chose to
split it out in its own package.
[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]
The packages have quite a few vendored dependencies. However, their non-vendored
dependencies are all in main, as well as the build-dependencies, assuming for the purpose
of this analysis that src:rustc is in main.
[Standards compliance]
The packages violate the Debian Policy on vendored
dependencies, with a copy of LLVM in rustc, and a copy of libgit2 (as a delta to Debian) in cargo.
Note that one can also find the sources for libcurl in src:rustc, but that's a leftover of the dependencies of cargo, which has been split out of src:rustc.
[Maintenance/Owner]
Owning Team will be Foundations
Team is not yet, but will subscribe to the package before promotion
Both packages use static linking for the Rust dependencies, as well as any
vendored C dependency (i.e. libgit2 and LLVM)
TODO: check what's what with LLVM, status unclear?
rustc uses vendored rust code tracked in Cargo.lock as shipped, in the package,
refreshing that code works via `cargo update ...` + cargo vendor
cargo has a different process, documented in debian/README.source.
TODO: actually try to update a dependency in cargo using the debian/README.source,
which are not that clear.
[Background information]
The Package descriptions explains the package well
Upstream Name is developed by the Rust Compiler team and the Cargo team, under
the umbrella of the Rust Foundation
Link to upstream project: https://www.rust-lang.org/ |
[Availability]
The packages rustc and cargo are already in Ubuntu universe.
The packages build for the architectures they are designed to work on,
and are also built on platform with lesser upstream support, see
https://doc.rust-lang.org/nightly/rustc/platform-support.html for details.
They currently build and works for architectures:
* amd64
* arm64
* armhf
* i386
* ppc64el
* riscv64
* s390x
Link to packages:
https://launchpad.net/ubuntu/+source/rustc
https://launchpad.net/ubuntu/+source/cargo
[Rationale]
The packages rustc and cargo are required in Ubuntu main as the Rust programming
language is gaining in popularity, and those two packages are, respectively, its
main compiler implementation and its dedicated build tool (and dependency manager).
There are a few packages in main already that have partially switched to Rust
as their implementation language, and so rustc and cargo will be needed to keep
us in sync with their upstream. See for instance
https://bugs.launchpad.net/ubuntu/+source/mdevctl/+bug/1942394 and
https://lists.debian.org/debian-python/2021/12/msg00000.html
(python-cryptography is in main)
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 and rustc had 19 recorded security issues in the past, mostly in the Rust standard library
(1 affecting cargo):
https://nvd.nist.gov/vuln/search/results?form_type=Advanced&results_type=overview&search_type=all&isCpeNameSearch=false&cpe_vendor=cpe%3A%2F%3Arust-lang&cpe_product=cpe%3A%2F%3A%3Arust
All issues are usually handled promptly by the Rust team. However, the fixes
are rarely (if ever) backported to previous releases besides an occasional
1.X.1 point release for the latest stable.
There is an official Rust Security working group that curates a database of security
issues within the Rust ecosystem, including rustc/cargo:
https://github.com/rustsec/advisory-db
- 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, building a project with cargo+rustc involves
executing code that has been downloaded from crates.io: 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 dependency basically implies running arbitrary code (the macro) within
the execution context of rustc.
[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 packages both run a test suite on build time. However, the rustc test suite
does NOT make the build fail. The reason is that there are always a few tests that fail, and it was a tradeoff made due to limited resources. Please note that Debian has a strategy of only failing the build if there are *too many* errors. As the Foundations team commits more resources on this toolchain, this policy will probably be revisited.
Neither package has any autopkgtests.
TODO: cargo autopkgtest that creates a new crate, adds a simple dependency
(anyhow is a good candidate, no transitive deps), vendors it, builds the binary
from the vendored crate, and runs it.
[Quality assurance - packaging]
debian/watch is present and works
rustc yields quite a bit of lintian output, but they seem mostly harmless.
https://lintian.debian.org/sources/rustc
There are lintian overrides present, but those are usually justified in the override
files themselves.
cargo is a bit more tame on the warning fronts
https://lintian.debian.org/sources/cargo
It has an override file for the source package, for relatively minor warnings.
These packages does not rely on obsolete or about to be demoted packages.
The packages will not be installed by default
The packaging is fairly complex, especially in the case of rustc. The crux of
the complexity can be attributed to the boostrapping issue, as well as the need
to deal with vendored dependencies. There is extensive documentation within the
debian/ directories to help with the difficulties, and a lot of things have been
automated in scripts living in debian/scripts/*
Note that originally, the upstream tarball for rustc includes the sources for
cargo as well as its vendored dependencies, but the Debian Rust team chose to
split it out in its own package.
[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]
The packages have quite a few vendored dependencies. However, their non-vendored
dependencies are all in main, as well as the build-dependencies, assuming for the purpose
of this analysis that src:rustc is in main.
[Standards compliance]
The packages violate the Debian Policy on vendored
dependencies, with a copy of LLVM in rustc, and a copy of libgit2 (as a delta to Debian) in cargo.
Note that one can also find the sources for libcurl in src:rustc, but that's a leftover of the dependencies of cargo, which has been split out of src:rustc.
[Maintenance/Owner]
Owning Team will be Foundations
Team is not yet, but will subscribe to the package before promotion
Both packages use static linking for the Rust dependencies, as well as any
vendored C dependency (i.e. libgit2 and LLVM).
The copy of LLVM is there because rustc depends on relatively recent version of LLVM, and has been upgraded regularly in our LTS releases due to firefox regularly bumping its minimal rust version requirements. Removing the embedded copy would probably mean having to have those more recent versions of LLVM in the archive as well.
rustc uses vendored rust code tracked in Cargo.lock as shipped, in the package,
refreshing that code works via `cargo update ...` + cargo vendor
cargo has a different process, documented in debian/README.source.
TODO: actually try to update a dependency in cargo using the debian/README.source,
which are not that clear.
[Background information]
The Package descriptions explains the package well
Upstream Name is developed by the Rust Compiler team and the Cargo team, under
the umbrella of the Rust Foundation
Link to upstream project: https://www.rust-lang.org/ |
|
| 2022-02-03 08:42:04 |
Christian Ehrhardt |
bug watch added |
|
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972829 |
|
| 2022-02-03 08:42:04 |
Christian Ehrhardt |
bug watch added |
|
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928422 |
|
| 2022-02-03 08:42:04 |
Christian Ehrhardt |
cve linked |
|
2022-21658 |
|
| 2022-02-03 08:43:30 |
Christian Ehrhardt |
rustc (Ubuntu): assignee |
Christian Ehrhardt (paelzer) |
Simon Chopin (schopin) |
|
| 2022-02-03 08:43:32 |
Christian Ehrhardt |
rustc (Ubuntu): status |
New |
Incomplete |
|
| 2022-02-09 15:59:26 |
Didier Roche-Tolomelli |
cargo (Ubuntu): assignee |
Didier Roche (didrocks) |
Simon Chopin (schopin) |
|
| 2022-02-09 15:59:29 |
Didier Roche-Tolomelli |
cargo (Ubuntu): status |
New |
Incomplete |
|
| 2022-02-15 17:55:19 |
Simon Chopin |
description |
[Availability]
The packages rustc and cargo are already in Ubuntu universe.
The packages build for the architectures they are designed to work on,
and are also built on platform with lesser upstream support, see
https://doc.rust-lang.org/nightly/rustc/platform-support.html for details.
They currently build and works for architectures:
* amd64
* arm64
* armhf
* i386
* ppc64el
* riscv64
* s390x
Link to packages:
https://launchpad.net/ubuntu/+source/rustc
https://launchpad.net/ubuntu/+source/cargo
[Rationale]
The packages rustc and cargo are required in Ubuntu main as the Rust programming
language is gaining in popularity, and those two packages are, respectively, its
main compiler implementation and its dedicated build tool (and dependency manager).
There are a few packages in main already that have partially switched to Rust
as their implementation language, and so rustc and cargo will be needed to keep
us in sync with their upstream. See for instance
https://bugs.launchpad.net/ubuntu/+source/mdevctl/+bug/1942394 and
https://lists.debian.org/debian-python/2021/12/msg00000.html
(python-cryptography is in main)
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 and rustc had 19 recorded security issues in the past, mostly in the Rust standard library
(1 affecting cargo):
https://nvd.nist.gov/vuln/search/results?form_type=Advanced&results_type=overview&search_type=all&isCpeNameSearch=false&cpe_vendor=cpe%3A%2F%3Arust-lang&cpe_product=cpe%3A%2F%3A%3Arust
All issues are usually handled promptly by the Rust team. However, the fixes
are rarely (if ever) backported to previous releases besides an occasional
1.X.1 point release for the latest stable.
There is an official Rust Security working group that curates a database of security
issues within the Rust ecosystem, including rustc/cargo:
https://github.com/rustsec/advisory-db
- 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, building a project with cargo+rustc involves
executing code that has been downloaded from crates.io: 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 dependency basically implies running arbitrary code (the macro) within
the execution context of rustc.
[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 packages both run a test suite on build time. However, the rustc test suite
does NOT make the build fail. The reason is that there are always a few tests that fail, and it was a tradeoff made due to limited resources. Please note that Debian has a strategy of only failing the build if there are *too many* errors. As the Foundations team commits more resources on this toolchain, this policy will probably be revisited.
Neither package has any autopkgtests.
TODO: cargo autopkgtest that creates a new crate, adds a simple dependency
(anyhow is a good candidate, no transitive deps), vendors it, builds the binary
from the vendored crate, and runs it.
[Quality assurance - packaging]
debian/watch is present and works
rustc yields quite a bit of lintian output, but they seem mostly harmless.
https://lintian.debian.org/sources/rustc
There are lintian overrides present, but those are usually justified in the override
files themselves.
cargo is a bit more tame on the warning fronts
https://lintian.debian.org/sources/cargo
It has an override file for the source package, for relatively minor warnings.
These packages does not rely on obsolete or about to be demoted packages.
The packages will not be installed by default
The packaging is fairly complex, especially in the case of rustc. The crux of
the complexity can be attributed to the boostrapping issue, as well as the need
to deal with vendored dependencies. There is extensive documentation within the
debian/ directories to help with the difficulties, and a lot of things have been
automated in scripts living in debian/scripts/*
Note that originally, the upstream tarball for rustc includes the sources for
cargo as well as its vendored dependencies, but the Debian Rust team chose to
split it out in its own package.
[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]
The packages have quite a few vendored dependencies. However, their non-vendored
dependencies are all in main, as well as the build-dependencies, assuming for the purpose
of this analysis that src:rustc is in main.
[Standards compliance]
The packages violate the Debian Policy on vendored
dependencies, with a copy of LLVM in rustc, and a copy of libgit2 (as a delta to Debian) in cargo.
Note that one can also find the sources for libcurl in src:rustc, but that's a leftover of the dependencies of cargo, which has been split out of src:rustc.
[Maintenance/Owner]
Owning Team will be Foundations
Team is not yet, but will subscribe to the package before promotion
Both packages use static linking for the Rust dependencies, as well as any
vendored C dependency (i.e. libgit2 and LLVM).
The copy of LLVM is there because rustc depends on relatively recent version of LLVM, and has been upgraded regularly in our LTS releases due to firefox regularly bumping its minimal rust version requirements. Removing the embedded copy would probably mean having to have those more recent versions of LLVM in the archive as well.
rustc uses vendored rust code tracked in Cargo.lock as shipped, in the package,
refreshing that code works via `cargo update ...` + cargo vendor
cargo has a different process, documented in debian/README.source.
TODO: actually try to update a dependency in cargo using the debian/README.source,
which are not that clear.
[Background information]
The Package descriptions explains the package well
Upstream Name is developed by the Rust Compiler team and the Cargo team, under
the umbrella of the Rust Foundation
Link to upstream project: https://www.rust-lang.org/ |
[Availability]
The packages rustc and cargo are already in Ubuntu universe.
The packages build for the architectures they are designed to work on,
and are also built on platform with lesser upstream support, see
https://doc.rust-lang.org/nightly/rustc/platform-support.html for details.
They currently build and works for architectures:
* amd64
* arm64
* armhf
* i386
* ppc64el
* riscv64
* s390x
Link to packages:
https://launchpad.net/ubuntu/+source/rustc
https://launchpad.net/ubuntu/+source/cargo
Upcoming version:
https://launchpad.net/~schopin/+archive/ubuntu/rustc-mir/+sourcepub/13264343/+listing-archive-extra
[Rationale]
The packages rustc and cargo are required in Ubuntu main as the Rust programming
language is gaining in popularity, and those two packages are, respectively, its
main compiler implementation and its dedicated build tool (and dependency manager).
There are a few packages in main already that have partially switched to Rust
as their implementation language, and so rustc and cargo will be needed to keep
us in sync with their upstream. See for instance
https://bugs.launchpad.net/ubuntu/+source/mdevctl/+bug/1942394 and
https://lists.debian.org/debian-python/2021/12/msg00000.html
(python-cryptography is in main)
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 and rustc had 19 recorded security issues in the past, mostly in the Rust standard library
(1 affecting cargo):
https://nvd.nist.gov/vuln/search/results?form_type=Advanced&results_type=overview&search_type=all&isCpeNameSearch=false&cpe_vendor=cpe%3A%2F%3Arust-lang&cpe_product=cpe%3A%2F%3A%3Arust
All issues are usually handled promptly by the Rust team. However, the fixes
are rarely (if ever) backported to previous releases besides an occasional
1.X.1 point release for the latest stable.
There is an official Rust Security working group that curates a database of security
issues within the Rust ecosystem, including rustc/cargo:
https://github.com/rustsec/advisory-db
- 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, building a project with cargo+rustc involves
executing code that has been downloaded from crates.io: 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 dependency basically implies running arbitrary code (the macro) within
the execution context of rustc.
[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 packages both run a test suite on build time. However, the rustc test suite
does NOT make the build fail as of 1.57. The reason is that there are always a few tests that fail, and it was a tradeoff made due to limited resources. Please note that Debian has a strategy of only failing the build if there are *too many* errors. As the Foundations team commits more resources on this toolchain, we've reverted back to Debian's system and are planning to making the testing story more rigorous.
Neither package has any autopkgtests in the versions currently in the release pocket. The upcoming rustc upload will have an autopkgtest consisting of rebuilding itself. Debian's cargo package now has a similar autopkgtest, that will be cherry-picked in the next cargo upload.
[Quality assurance - packaging]
debian/watch is present and works
rustc yields quite a bit of lintian output, but they seem mostly harmless.
https://lintian.debian.org/sources/rustc
There are lintian overrides present, but those are usually justified in the override
files themselves.
cargo is a bit more tame on the warning fronts
https://lintian.debian.org/sources/cargo
It has an override file for the source package, for relatively minor warnings.
These packages does not rely on obsolete or about to be demoted packages.
The packages will not be installed by default
The packaging is fairly complex, especially in the case of rustc. The crux of
the complexity can be attributed to the boostrapping issue, as well as the need
to deal with vendored dependencies. There is extensive documentation within the
debian/ directories to help with the difficulties, and a lot of things have been
automated in scripts living in debian/scripts/*
Note that originally, the upstream tarball for rustc includes the sources for
cargo as well as its vendored dependencies, but the Debian Rust team chose to
split it out in its own package.
[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]
The packages have quite a few vendored dependencies. However, their non-vendored
dependencies are all in main, as well as the build-dependencies, assuming for the purpose
of this analysis that src:rustc is in main.
[Standards compliance]
The packages violate the Debian Policy on vendored
dependencies, with a copy of libgit2 (as a delta to Debian) in cargo.
The upcoming 1.58.1+dfsg1~ubuntu1 version of src:rustc unbundles the LLVM copy that's currently in src:rustc.
[Maintenance/Owner]
Owning Team will be Foundations
Team is not yet, but will subscribe to the package before promotion
Both packages use static linking for the Rust dependencies, as well as any
vendored C dependency (i.e. libgit2).
rustc uses vendored rust code tracked in Cargo.lock as shipped, in the package,
refreshing that code works via `cargo update ...` + cargo vendor
cargo has a different process, documented in debian/README.source.
TODO: actually try to update a dependency in cargo using the debian/README.source,
which are not that clear.
[Background information]
The Package descriptions explains the package well
Upstream Name is developed by the Rust Compiler team and the Cargo team, under
the umbrella of the Rust Foundation
Link to upstream project: https://www.rust-lang.org/ |
|
| 2022-02-16 10:07:08 |
Simon Chopin |
rustc (Ubuntu): assignee |
Simon Chopin (schopin) |
Ubuntu Security Team (ubuntu-security) |
|
| 2022-02-23 22:37:01 |
Steve Beattie |
bug |
|
|
added subscriber Steve Beattie |
| 2022-02-24 06:17:02 |
Steve Beattie |
rustc (Ubuntu): assignee |
Ubuntu Security Team (ubuntu-security) |
|
|
| 2022-03-10 19:08:13 |
Simon Chopin |
rustc (Ubuntu): status |
Incomplete |
Confirmed |
|
| 2022-03-10 19:10:05 |
Simon Chopin |
rustc (Ubuntu): status |
Confirmed |
In Progress |
|
| 2022-03-10 19:19:14 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~schopin/ubuntu-seeds/+git/ubuntu-seeds/+merge/416688 |
|
| 2022-03-15 15:39:14 |
Steve Beattie |
cve linked |
|
2022-23639 |
|
| 2022-03-22 13:10:56 |
Anthony Fok |
bug |
|
|
added subscriber Anthony Fok |
| 2022-04-04 07:14:37 |
Simon Chopin |
bug task added |
|
dh-cargo (Ubuntu) |
|
| 2022-04-04 07:15:26 |
Simon Chopin |
summary |
[MIR] rustc, cargo |
[MIR] rustc, cargo, dh-cargo |
|
| 2022-04-04 07:37:25 |
Simon Chopin |
description |
[Availability]
The packages rustc and cargo are already in Ubuntu universe.
The packages build for the architectures they are designed to work on,
and are also built on platform with lesser upstream support, see
https://doc.rust-lang.org/nightly/rustc/platform-support.html for details.
They currently build and works for architectures:
* amd64
* arm64
* armhf
* i386
* ppc64el
* riscv64
* s390x
Link to packages:
https://launchpad.net/ubuntu/+source/rustc
https://launchpad.net/ubuntu/+source/cargo
Upcoming version:
https://launchpad.net/~schopin/+archive/ubuntu/rustc-mir/+sourcepub/13264343/+listing-archive-extra
[Rationale]
The packages rustc and cargo are required in Ubuntu main as the Rust programming
language is gaining in popularity, and those two packages are, respectively, its
main compiler implementation and its dedicated build tool (and dependency manager).
There are a few packages in main already that have partially switched to Rust
as their implementation language, and so rustc and cargo will be needed to keep
us in sync with their upstream. See for instance
https://bugs.launchpad.net/ubuntu/+source/mdevctl/+bug/1942394 and
https://lists.debian.org/debian-python/2021/12/msg00000.html
(python-cryptography is in main)
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 and rustc had 19 recorded security issues in the past, mostly in the Rust standard library
(1 affecting cargo):
https://nvd.nist.gov/vuln/search/results?form_type=Advanced&results_type=overview&search_type=all&isCpeNameSearch=false&cpe_vendor=cpe%3A%2F%3Arust-lang&cpe_product=cpe%3A%2F%3A%3Arust
All issues are usually handled promptly by the Rust team. However, the fixes
are rarely (if ever) backported to previous releases besides an occasional
1.X.1 point release for the latest stable.
There is an official Rust Security working group that curates a database of security
issues within the Rust ecosystem, including rustc/cargo:
https://github.com/rustsec/advisory-db
- 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, building a project with cargo+rustc involves
executing code that has been downloaded from crates.io: 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 dependency basically implies running arbitrary code (the macro) within
the execution context of rustc.
[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 packages both run a test suite on build time. However, the rustc test suite
does NOT make the build fail as of 1.57. The reason is that there are always a few tests that fail, and it was a tradeoff made due to limited resources. Please note that Debian has a strategy of only failing the build if there are *too many* errors. As the Foundations team commits more resources on this toolchain, we've reverted back to Debian's system and are planning to making the testing story more rigorous.
Neither package has any autopkgtests in the versions currently in the release pocket. The upcoming rustc upload will have an autopkgtest consisting of rebuilding itself. Debian's cargo package now has a similar autopkgtest, that will be cherry-picked in the next cargo upload.
[Quality assurance - packaging]
debian/watch is present and works
rustc yields quite a bit of lintian output, but they seem mostly harmless.
https://lintian.debian.org/sources/rustc
There are lintian overrides present, but those are usually justified in the override
files themselves.
cargo is a bit more tame on the warning fronts
https://lintian.debian.org/sources/cargo
It has an override file for the source package, for relatively minor warnings.
These packages does not rely on obsolete or about to be demoted packages.
The packages will not be installed by default
The packaging is fairly complex, especially in the case of rustc. The crux of
the complexity can be attributed to the boostrapping issue, as well as the need
to deal with vendored dependencies. There is extensive documentation within the
debian/ directories to help with the difficulties, and a lot of things have been
automated in scripts living in debian/scripts/*
Note that originally, the upstream tarball for rustc includes the sources for
cargo as well as its vendored dependencies, but the Debian Rust team chose to
split it out in its own package.
[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]
The packages have quite a few vendored dependencies. However, their non-vendored
dependencies are all in main, as well as the build-dependencies, assuming for the purpose
of this analysis that src:rustc is in main.
[Standards compliance]
The packages violate the Debian Policy on vendored
dependencies, with a copy of libgit2 (as a delta to Debian) in cargo.
The upcoming 1.58.1+dfsg1~ubuntu1 version of src:rustc unbundles the LLVM copy that's currently in src:rustc.
[Maintenance/Owner]
Owning Team will be Foundations
Team is not yet, but will subscribe to the package before promotion
Both packages use static linking for the Rust dependencies, as well as any
vendored C dependency (i.e. libgit2).
rustc uses vendored rust code tracked in Cargo.lock as shipped, in the package,
refreshing that code works via `cargo update ...` + cargo vendor
cargo has a different process, documented in debian/README.source.
TODO: actually try to update a dependency in cargo using the debian/README.source,
which are not that clear.
[Background information]
The Package descriptions explains the package well
Upstream Name is developed by the Rust Compiler team and the Cargo team, under
the umbrella of the Rust Foundation
Link to upstream project: https://www.rust-lang.org/ |
[Availability]
The packages rustc and cargo are already in Ubuntu universe.
The packages build for the architectures they are designed to work on,
and are also built on platform with lesser upstream support, see
https://doc.rust-lang.org/nightly/rustc/platform-support.html for details.
They currently build and works for architectures:
* amd64
* arm64
* armhf
* i386
* ppc64el
* riscv64
* s390x
Link to packages:
https://launchpad.net/ubuntu/+source/rustc
https://launchpad.net/ubuntu/+source/cargo
https://launchpad.net/ubuntu/+source/dh-cargo
Upcoming version:
https://launchpad.net/~schopin/+archive/ubuntu/rustc-mir/+sourcepub/13264343/+listing-archive-extra
[Rationale]
The packages rustc and cargo are required in Ubuntu main as the Rust programming
language is gaining in popularity, and those two packages are, respectively, its
main compiler implementation and its dedicated build tool (and dependency manager). dh-cargo is the standard packaging helper for Rust-based packages.
There are a few packages in main already that have partially switched to Rust
as their implementation language, and so rustc and cargo will be needed to keep
us in sync with their upstream. See for instance
https://bugs.launchpad.net/ubuntu/+source/mdevctl/+bug/1942394 and
https://lists.debian.org/debian-python/2021/12/msg00000.html
(python-cryptography is in main)
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 and rustc had 19 recorded security issues in the past, mostly in the Rust standard library
(1 affecting cargo):
https://nvd.nist.gov/vuln/search/results?form_type=Advanced&results_type=overview&search_type=all&isCpeNameSearch=false&cpe_vendor=cpe%3A%2F%3Arust-lang&cpe_product=cpe%3A%2F%3A%3Arust
All issues are usually handled promptly by the Rust team. However, the fixes
are rarely (if ever) backported to previous releases besides an occasional
1.X.1 point release for the latest stable.
There is an official Rust Security working group that curates a database of security
issues within the Rust ecosystem, including rustc/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+rustc involves
executing code that has been downloaded from crates.io: 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 dependency basically implies running arbitrary code (the macro) within
the execution context of rustc.
[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 and rustc packages both run a test suite on build time. However, the rustc test suite
does NOT make the build fail as of 1.57. The reason is that there are always a few tests that fail, and it was a tradeoff made due to limited resources. Please note that Debian has a strategy of only failing the build if there are *too many* errors. As the Foundations team commits more resources on this toolchain, we've reverted back to Debian's system and are planning to making the testing story more rigorous.
Neither package has any autopkgtests in the versions currently in the release pocket. The upcoming rustc upload will have an autopkgtest consisting of rebuilding itself. Debian's cargo package now has a similar autopkgtest, that will be cherry-picked in the next cargo upload.
dh-cargo has neither build-time tests nor autopkgtests.
[Quality assurance - packaging]
debian/watch is present and works, dh-cargo is a native package.
rustc yields quite a bit of lintian output, but they seem mostly harmless.
https://lintian.debian.org/sources/rustc
There are lintian overrides present, but those are usually justified in the override
files themselves.
cargo is a bit more tame on the warning fronts
https://lintian.debian.org/sources/cargo
It has an override file for the source package, for relatively minor warnings.
dh-cargo is lintian-clean.
These packages does not rely on obsolete or about to be demoted packages.
The packages will not be installed by default
The packaging is fairly complex, especially in the case of rustc. The crux of
the complexity can be attributed to the boostrapping issue, as well as the need
to deal with vendored dependencies. There is extensive documentation within the
debian/ directories to help with the difficulties, and a lot of things have been
automated in scripts living in debian/scripts/*
Note that originally, the upstream tarball for rustc includes the sources for
cargo as well as its vendored dependencies, but the Debian Rust team chose to
split it out in its own package.
[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]
The packages have quite a few vendored dependencies. However, their non-vendored
dependencies are all in main, as well as the build-dependencies, assuming for the purpose
of this analysis that src:rustc is in main.
[Standards compliance]
The packages violate the Debian Policy on vendored
dependencies, with a copy of libgit2 (as a delta to Debian) in cargo.
The upcoming 1.58.1+dfsg1~ubuntu1 version of src:rustc unbundles the LLVM copy that's currently in src:rustc.
[Maintenance/Owner]
Owning Team will be Foundations
Team is not yet subscribed to all packages (dh-cargo still missing)
Both cargo and rustc packages use static linking for the Rust dependencies, as well as any
vendored C dependency (i.e. libgit2).
rustc uses vendored rust code tracked in Cargo.lock as shipped, in the package,
refreshing that code works via `cargo update ...` + cargo vendor. However, upgrading a single crate is more invasive than what could be expected, so patching vendored versions directly might be more advisable, as experienced with CVE-2022-23639.
cargo has a different process, documented in debian/README.source.
TODO: actually try to update a dependency in cargo using the debian/README.source,
which are not that clear.
[Background information]
The Package descriptions explains the package well
Upstream Name is developed by the Rust Compiler team and the Cargo team, under
the umbrella of the Rust Foundation
Link to upstream project: https://www.rust-lang.org/ |
|
| 2022-04-04 07:58:14 |
Simon Chopin |
dh-cargo (Ubuntu): status |
New |
Incomplete |
|
| 2022-04-11 16:34:25 |
Simon Chopin |
rustc (Ubuntu): status |
In Progress |
Fix Committed |
|
| 2022-04-11 16:36:40 |
Simon Chopin |
bug |
|
|
added subscriber Ubuntu Package Archive Administrators |
| 2022-04-11 20:41:20 |
Steve Langasek |
rustc (Ubuntu): status |
Fix Committed |
Fix Released |
|
| 2022-04-15 15:51:43 |
Steve Langasek |
removed subscriber Ubuntu Package Archive Administrators |
|
|
|
| 2022-10-21 13:28:06 |
Simon Chopin |
cargo (Ubuntu): status |
Incomplete |
Invalid |
|
| 2022-10-21 13:28:08 |
Simon Chopin |
dh-cargo (Ubuntu): status |
Incomplete |
Invalid |
|
| 2023-08-10 09:06:54 |
Frank Heimes |
bug |
|
|
added subscriber Frank Heimes |
| 2023-09-12 09:30:35 |
Lukas Märdian |
rustc (Ubuntu): status |
Fix Released |
New |
|
| 2023-09-22 05:55:27 |
Didier Roche-Tolomelli |
rustc (Ubuntu): status |
New |
Fix Committed |
|
| 2023-10-10 10:24:27 |
Lukas Märdian |
rustc (Ubuntu): status |
Fix Committed |
Fix Released |
|
