develooper Front page | perl.perl5.porters | Postings from June 2022

Re: Pre-RFC: support https out-of-the-box

Thread Previous | Thread Next
From:
Craig A. Berry
Date:
June 16, 2022 18:42
Subject:
Re: Pre-RFC: support https out-of-the-box
Message ID:
CA+vYcVzfuAo71CK0Zve9GZ-k=m+WB+__oVF+E6M_Z1WHoC8opA@mail.gmail.com
On Thu, Jun 16, 2022 at 9:18 AM Felipe Gasper <felipe@felipegasper.com> wrote:
>
>
> > On Jun 16, 2022, at 09:46, Craig A. Berry <craig.a.berry@gmail.com> wrote:
> >
> > On Wed, Jun 15, 2022 at 7:38 PM Felipe Gasper <felipe@felipegasper.com> wrote:
> >>
> >>
> >>
> >>> On Jun 15, 2022, at 18:22, Craig A. Berry <craig.a.berry@gmail.com> wrote:
> >>>
> >>> On Wed, Jun 15, 2022 at 2:23 AM Alexander Hartmaier
> >>> <alex.hartmaier@gmail.com> wrote:
> >>>>
> >>>> On Tue, Jun 14, 2022 at 6:18 PM Elvin Aslanov <rwp.primary@gmail.com> wrote:
> >>>>>
> >>>>> yeah but `cpan Mozilla::CA` isn't hard to do to update the module and it won't break with newer Perl versions as well since it's just plaintext non-code certificates bundle
> >>>>
> >>>>
> >>>> I'd prefer if the stack used the OS trusted CAs by default instead of having its own list.
> >>>> This should only be the default and overrideable for private CA use-cases.
> >>>
> >>> But that is a *massively* more difficult portability problem than just
> >>> "where do I find OpenSSL or LibreSSL?".
> >
> >> Clarification: by “OS-trusted CAs” I believe Alexander refers specifically to OpenSSL’s roots, which are easily discoverable via the mechanism I mentioned earlier in this thread.
> >>
> >> The idea is: if there’s OpenSSL, use it; if not, no out-of-the-box TLS.
> >
> > As the StackOverflow article you cited makes clear, it is easy to
> > discover the directory where OpenSSL will look for certificates, but
> > what certificates are stored there has nothing to do with OpenSSL.  If
> > the OpenSSL packager includes authoritative certificates and updates
> > them with package updates, that's certainly a convenient way to stay
> > current.  But how does one tell that is the case?  Someone may have
> > installed OpenSSL from source or from a packager that does not include
> > certs and have no certificates all or only self-signed or example
> > certificates.
>
> 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.
From the OpenSSL docs here:

https://www.openssl.org/docs/manmaster/man1/openssl-verification-options.html

>>> quote <<<
Note that OpenSSL does not provide a default set of trust anchors.
Many Linux distributions include a system default and configure
OpenSSL to point to that. Mozilla maintains an influential trust store
that can be found at
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/.
>>> end quote <<<

So let's please not go with a Linux-only solution and just use
Mozilla::CA as already planned.

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About