Front page | perl.perl5.porters |
Postings from June 2022
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.Thread Previous | Thread Next