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

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

Thread Previous | Thread Next
Craig A. Berry
June 16, 2022 13:47
Re: Pre-RFC: support https out-of-the-box
Message ID:
On Wed, Jun 15, 2022 at 7:38 PM Felipe Gasper <> wrote:
> > On Jun 15, 2022, at 18:22, Craig A. Berry <> wrote:
> >
> > On Wed, Jun 15, 2022 at 2:23 AM Alexander Hartmaier
> > <> wrote:
> >>
> >> On Tue, Jun 14, 2022 at 6:18 PM Elvin Aslanov <> 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

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About