** Description changed: [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). + 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, building a project with cargo+rustc involves + 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 packages both run a test suite on build time. However, the rustc test suite + 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 + 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, but will subscribe to the package before promotion + Team is not yet subscribed to all packages (dh-cargo still missing) - Both packages use static linking for the Rust dependencies, as well as any + 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 + 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/
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1957932 Title: [MIR] rustc, cargo, dh-cargo To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cargo/+bug/1957932/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
