Front page | perl.perl5.porters |
Postings from June 2022
> On Jun 16, 2022, at 14:42, Craig A. Berry <craig.a.berry@gmail.com> wrote: > > On Thu, Jun 16, 2022 at 9:18 AM Felipe Gasper <felipe@felipegasper.com> wrote: >> >> If OpenSSL’s roots are old or invalid, then anything that uses that OpenSSL is buggy. Thus, I would think Perl doesn’t really need to care about how well the root store is maintained. >> >> It might be good to assemble a list of how other languages solve this problem. I checked a few and started a gist here: >> https://gist.github.com/FGasper/9ea9432409a4acf89fc206083cbae278 >> >> Given that node.js, PHP, and Python all seem to rely on OpenSSL’s root store, that path doesn’t seem like it would be unduly problematic for Perl. > > Again, OpenSSL does not come with any certificates in its root store. I this is “mostly false”, actually. The OpenSSL project doesn’t *provide* a root store, sure, but many (most?) production OpenSSL deployments do, in fact, “come with” a root store--it just happens not to be something that OpenSSL itself provides. > So let's please not go with a Linux-only solution and just use > Mozilla::CA as already planned. How would using OpenSSL’s root certs be less “Linux-only” than using Net::SSLeay? If we want a fully cross-platform solution, then bundling mbedTLS seems the only reasonable path. That doesn’t seem likely. If, though, we’re going to use OpenSSL exclusively, we might as well prefer whatever roots it may include. It seems to work well enough for node.js, Python, and PHP--all of which are popular outside Linux. A “hybrid” approach might be to ship a new module that implements a fallback mechanism: 1) Check for OpenSSL’s roots. 2) Check for Mozilla::CA. 3) Check list of hard-coded paths (steal from golang’s lists). … or some other logic like checking mtimes or what not to determine a best root bundle. -FThread Previous | Thread Next