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

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

Thread Previous | Thread Next
From:
Felipe Gasper
Date:
June 16, 2022 14:18
Subject:
Re: Pre-RFC: support https out-of-the-box
Message ID:
09ECA3C0-2772-42EF-813B-F0C6F2A96179@felipegasper.com

> 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.

-F

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