Front page | perl.perl5.porters |
Postings from June 2022
On Thu, Jun 16, 2022 at 2:38 AM 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?". Do you know where the OS > > trusted CAs are for every platform and distribution on which Perl > > runs? Or if there even is such a thing as an "OS trusted CA" on all of > > them? Or what format they are in? Or whether they even exist on the > > filesystem or are in some proprietary data store? > > 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. > > -FG > I wasn't really talking about OpenSSL but Debian/Ubuntu's ca-certificates package which puts the trusted root CA cert files in PEM format in /etc/ssl/certs. I'm sure RHEL and derivates have such a directory as well. For Windows I don't know how and where they are stored nor how to access them, but the UI for managing them is launching mmc.exe and adding the 'Certificates' snapin. That's what a regular user expects, just as usage of a system set proxy, which is also a topic to make the HTTPS Internet access work. That's with my 'large enterprise security engineer/architect' hat on. FYI our current international client network can't even resolve Internet DNS any more, just the proxy can. There are also multiple internal root CAs that you have to trust, either for internal https resource access or even man-in-the-middle TLS (please don't call it SSL, that long dead) inspection. I'd split the required parts up into (in order of importance, can also be shortcut using configure switches if autodetection fails or isn't implemented for a platform): - TLS library setup - trusted root CA certificate detection (different per OS, maybe even dist specific) - system proxy detectionThread Previous | Thread Next