Front page | perl.perl5.porters |
Postings from December 2021
On Wed, Dec 08, 2021 at 09:42:47PM -0600, Craig A. Berry wrote: > On Wed, Dec 8, 2021 at 1:12 PM Paul "LeoNerd" Evans > <leonerd@leonerd.org.uk> wrote: > > > > Two other facts which seem relevant, that haven't been mentioned so far: > > > > 1) Perl is currently supported on many more platforms than OpenSSL is > > > > 2) OpenSSL requires perl during its build process > > > > For both of these reasons, core perl *cannot* require OpenSSL. > > It cannot require it but it can provide Perl-level support for TLS if > the underlying capability is available. This has all been covered in > the original thread Neil started. Obviously it must still be possible ... this, because this: > I don't think it is possible near-term to guarantee that every Perl > installation has TLS 1.2+ support with certificate verification. But > it seems feasible to greatly narrow the impact of the CVEs by ensuring > that support via Perl modules is available if the libraries upon which > those modules depend are available. > > There are plenty of challenges and no perfect solutions, such as the > same chicken-and-egg problem everyone has of needing to update your > certificate store using a certificate that may have been revoked but > you won't know until after you've updated your certificate store. But > is there any reason other than it's hard work that Perl shouldn't > include Net::SSLeay, IO::Socket::SSL, and Mozilla::CA in the core and > build them whenever the underlying support is available? "other than hard work" - no (other) reasons are obvious to me. *but* both that list and the other mentions of "but use curl or wget" seem to forget Windows. Which I admit that I don't know that much about, but my list of "known unknowns" is already: 1) What is the OS default certificate store on Windows (that we can assume the OS handles updates and revocations), and what module is needed to read it? 2) Are curl and wget likely to be found on Win32? Is there any command line tool that a HTTP::TIMTOWTDI module can shell out to, to deal with https? other question was *) for bootstrapping how many (well, few) certificates do we need to ship? and how often do these change? In that if the minimal bootstrap only defaults to https://www.cpan.org/ (where that's a CDN which is up, and going down is a newsworthy catastrophe) then surely it's sufficient to locally know only the root certificate that signed www.cpan.org? And shipping and tracking that is a much smaller problem than all the crap that web browsers currently accept as trustworthy. We don't need our bootstrapping https to be able to verify the identity of arbitrary sites that might happen to us some unusual root certificate. Just one sane site that we also (roughly) control. (Or at least talk to) Nicholas ClarkThread Previous | Thread Next