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

Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to