On Tue, 2020-11-03 at 20:45 +0000, 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