Bug#972802: [Pkg-rust-maintainers] Bug#972802: rust-webpki-roots: duplicates ca-certificates, remove from Debian?
On Tue, 2020-11-03 at 20:45 +, kpcyrd wrote: > It's more complicated than that, there's rustls-native-certs to use the > local certificate store, but the patch would be so invasive that debian > would effectively maintain a fork. At the time of writing webpki-roots > has 85 reverse dependencies on crates.io, while rustls-native-certs has > 13. I wonder if a wrapper crate that would present a common API and allow a build-time choice between the two options would be the way to go? Then everything that uses either of them could get changed upstream to use the wrapper, upstream builds could use webpki-roots and Debian could configure our builds to use rustls-native-certs. Is that plausible? > > - The quality of the ca-certificates package on debian-based Linux > > distributions is poor. At the time of writing, this ships many > > certificates not included in the Mozilla set, either because they > > failed an audit and were withdrawn[1] or were removed for > > mississuance[2]. > > [1]: https://bugs.mozilla.org/show_bug.cgi?id=1448506 > [2]: https://bugs.mozilla.org/show_bug.cgi?id=1552374 FTR, those URLs are broken, they need "bugs" replaced with "bugzilla". TÜRKTRUST was removed from the Debian package in 20190110 and Certnomis was removed from the Debian package in 20200601, those were definitely quite a bit later than what Mozilla did :( I'm not sure what the solution there is. It probably doesn't help that the current maintainer is not yet a Debian member, but is a Debian Maintainer (DM), but can't upload ca-certificates without a sponsor. Maybe the package should be co-maintained by the Debian security team? https://ftp-master.debian.org/dm.txt -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#972802: [Pkg-rust-maintainers] Bug#972802: rust-webpki-roots: duplicates ca-certificates, remove from Debian?
On Sat, Oct 24, 2020 at 11:50:14AM +0800, Paul Wise wrote: > > This is a very non-trivial downstream patch though, the project I'm > > trying to package runs in a sandbox and loading certificates from disk > > at runtime is not possible without redesigning some things. > > One option to solve this would be to have src:rust-webpki-roots provide > webpki-roots-build containing build.py and then have ca-certificates > build-dep on webpki-roots, run build.py and build a binary package > containing the generated rust code. That seems a bit ick though. > > Is there any chance of webpki/rustls upstream switching from embedding > to runtime loading of certs like other TLS stacks do? It's more complicated than that, there's rustls-native-certs to use the local certificate store, but the patch would be so invasive that debian would effectively maintain a fork. At the time of writing webpki-roots has 85 reverse dependencies on crates.io, while rustls-native-certs has 13. rustls-native-certs compares itself to webpki-roots in the readme, I think this bit is interesting: > Cons: > [...] > - The quality of the ca-certificates package on debian-based Linux > distributions is poor. At the time of writing, this ships many > certificates not included in the Mozilla set, either because they > failed an audit and were withdrawn[1] or were removed for > mississuance[2]. [1]: https://bugs.mozilla.org/show_bug.cgi?id=1448506 [2]: https://bugs.mozilla.org/show_bug.cgi?id=1552374
Bug#972802: rust-webpki-roots: duplicates ca-certificates, remove from Debian?
On Sat, 24 Oct 2020 11:50:14 +0800 Paul Wise wrote: On Sat, 2020-10-24 at 03:06 +, kpcyrd wrote: > Yes, running the build.py script would cause reproducible builds issues > because it's used to take snapshots of Mozilla's trusted root CA > certificates. Hmm, I assume that is because it would build from the current snapshot each time it is run? > This is a very non-trivial downstream patch though, the project I'm > trying to package runs in a sandbox and loading certificates from disk > at runtime is not possible without redesigning some things. One option to solve this would be to have src:rust-webpki-roots provide webpki-roots-build containing build.py and then have ca-certificates build-dep on webpki-roots, run build.py and build a binary package containing the generated rust code. That seems a bit ick though. Is there any chance of webpki/rustls upstream switching from embedding to runtime loading of certs like other TLS stacks do? > webpki-roots is an optional dependency of reqwest, see > librust-reqwest+webpki-roots-dev[1]. It looks like this package needs rebuilding, because the binary package librust-webpki-roots-dev doesn't provide the virtual package named librust-webpki-roots-0.16+default-dev any more, which is probably why dak didn't know that something in Debian uses src:rust-webpki-roots. > It's related to webpki[2]/rustls[3], the later only got accepted > into debian very recently. These appear to be the websites for these two: https://briansmith.org/rustdoc/webpki/ https://github.com/ctz/rustls I packaged rustls and webpki-roots as preconditions for packaging MesaLink. I will not pursue this project any longer; the reason for it was #963699 which is not relevant anymore. I am okay with removing both of these packages again. However, rustls is a common package in Rust world and the Rust team might want to keep it.
Bug#972802: rust-webpki-roots: duplicates ca-certificates, remove from Debian?
On Sat, 2020-10-24 at 03:06 +, kpcyrd wrote: > Yes, running the build.py script would cause reproducible builds issues > because it's used to take snapshots of Mozilla's trusted root CA > certificates. Hmm, I assume that is because it would build from the current snapshot each time it is run? > This is a very non-trivial downstream patch though, the project I'm > trying to package runs in a sandbox and loading certificates from disk > at runtime is not possible without redesigning some things. One option to solve this would be to have src:rust-webpki-roots provide webpki-roots-build containing build.py and then have ca-certificates build-dep on webpki-roots, run build.py and build a binary package containing the generated rust code. That seems a bit ick though. Is there any chance of webpki/rustls upstream switching from embedding to runtime loading of certs like other TLS stacks do? > webpki-roots is an optional dependency of reqwest, see > librust-reqwest+webpki-roots-dev[1]. It looks like this package needs rebuilding, because the binary package librust-webpki-roots-dev doesn't provide the virtual package named librust-webpki-roots-0.16+default-dev any more, which is probably why dak didn't know that something in Debian uses src:rust-webpki-roots. > It's related to webpki[2]/rustls[3], the later only got accepted > into debian very recently. These appear to be the websites for these two: https://briansmith.org/rustdoc/webpki/ https://github.com/ctz/rustls -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#972802: rust-webpki-roots: duplicates ca-certificates, remove from Debian?
On Sat, Oct 24, 2020 at 09:42:40AM +0800, Paul Wise wrote: > Source: rust-webpki-roots > Severity: serious > Tags: security > X-Debbugs-Cc: Debian Security Team , kpcyrd > > Usertags: embed > > rust-webpki-roots is essentially a duplicate of ca-certificates. > > https://tracker.debian.org/pkg/ca-certificates > https://wiki.debian.org/EmbeddedCopies > > AFAICT, rebuilding the package from source doesn't run the upstream > supplied build.py script, so rebuilding from source won't update the > certs available in the package. Yes, running the build.py script would cause reproducible builds issues because it's used to take snapshots of Mozilla's trusted root CA certificates. > Having to rebuild rust-webpki-roots and everything that depends on it > after every update of ca-certificates would be very annoying though. > > Probably rust-webpki-roots should be removed from Debian and replaced > with something that loads the certs from ca-certificates at runtime. This is a very non-trivial downstream patch though, the project I'm trying to package runs in a sandbox and loading certificates from disk at runtime is not possible without redesigning some things. > As far as I can tell, nothing in Debian uses rust-webpki-roots, but on > IRC, kpcyrd mentioned that they have projects that use webpki-roots, > CCing them in order to get more info about that usage. webpki-roots is an optional dependency of reqwest, see librust-reqwest+webpki-roots-dev[1]. It's related to webpki[2]/rustls[3], the later only got accepted into debian very recently. [1]: https://packages.debian.org/unstable/librust-reqwest+webpki-roots-dev [2]: https://tracker.debian.org/pkg/rust-webpki [3]: https://tracker.debian.org/pkg/rust-rustls
Bug#972802: rust-webpki-roots: duplicates ca-certificates, remove from Debian?
Source: rust-webpki-roots Severity: serious Tags: security X-Debbugs-Cc: Debian Security Team , kpcyrd Usertags: embed rust-webpki-roots is essentially a duplicate of ca-certificates. https://tracker.debian.org/pkg/ca-certificates https://wiki.debian.org/EmbeddedCopies AFAICT, rebuilding the package from source doesn't run the upstream supplied build.py script, so rebuilding from source won't update the certs available in the package. Having to rebuild rust-webpki-roots and everything that depends on it after every update of ca-certificates would be very annoying though. Probably rust-webpki-roots should be removed from Debian and replaced with something that loads the certs from ca-certificates at runtime. As far as I can tell, nothing in Debian uses rust-webpki-roots, but on IRC, kpcyrd mentioned that they have projects that use webpki-roots, CCing them in order to get more info about that usage. $ ssh mirror.ftp-master.debian.org dak rm -s unstable -Rn rust-webpki-roots Will remove the following packages from unstable: librust-webpki-roots-dev | 0.20.0-1+b1 | amd64, arm64, armel, armhf, i386 rust-webpki-roots | 0.20.0-1 | source webpki-roots | 0.20.0-1+b1 | amd64, arm64, armel, armhf, i386 Maintainer: Debian Rust Maintainers --- Reason --- -- Checking reverse dependencies... No dependency problem found. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
