On Fri, Dec 10, 2021 at 10:45 AM Tomasz Konojacki <me@xenu.pl> wrote: > > On Fri, 10 Dec 2021 10:37:19 +0000 > Nicholas Clark <nick@ccl4.org> wrote: > > other question was > > > > *) for bootstrapping how many (well, few) certificates do we need to ship? Is it any easier to ship a certificate file with one certificate rather than 100? I'm no expert but I believe root certs typically have many-year expiration lifecycles, much longer than the specific domain certs created from them, so there could be advantages to using a standard bundle of root certs even for bootstrapping purposes. Specifically, if we ship Perl with one and only one cert for cpan.org and it happens to expire two weeks after a Perl release ships, how does that one cert get updated before expiration? Root certs do eventually expire and revocations are always possible, but unpleasantness that is rare is preferable to unpleasantness that is more frequent. Also, if we include a cert file that only has one certificate in it because that's all we need for bootstrapping CPAN.pm, doesn't that potentially break other uses of the same toolchain (Net::SSLeay/IO::Socket::SSL), such as folks scraping random parts of the web or whatever? Or we have to use a differently-named cert file for bootstrapping and make the tools find it. > > and how often do these change? Looks like every month or two here: <https://curl.se/docs/caextract.html> although that may just be how often curl keeps up and not how often they actually change. > Mozilla::CA is the module that provides SSL certificates. Unfortunately > it's almost always outdated so ideally we should get co-maint on it and > automate its updates. It certainly looks automatable as it already has a script to produce a new release when the cacert.pem file changes. How does the end user get the updated version, though? Would CPAN.pm have to always update Mozilla::CA even if it's not in the dependency chain of whatever is being installed?Thread Previous | Thread Next