bug#46829: `guix pull` uses incorrect certificate store

["Ludovic Courtès" <ludo@gnu.org>]

Hi,

Leo Famulari <leo@famulari.name> skribis:

> On Tue, Apr 13, 2021 at 11:29:58AM +0200, Ludovic Courtès wrote:
>> So I think the issue is that, when ‘nss-certs’ is not installed, ‘guix
>> pull’ uses the LE certs, but these certificates expire quite frequently,
>> whereas if you have ‘nss-certs’ installed, there’s “always” a valid
>> authentication chain from the roots.
>
> No, that's incorrect. The certificates in le-certs expired after 5
> years, so it's not frequent.
>
> These are the root and intermediate certificates for the Let's Encrypt
> certificate authority — they are not the 90 day certificates used by a
> webserver.
>
> The problem is that we (I) failed to pay attention and let our le-certs
> package go stale.

OK.  5 years still looks kinda “frequent” to me.  I would think that old
software installations (including “appliances”) would live longer than
that, no?

You install Guix on a laptop, you leave it in a drawer, and you come a
few years later and you can neither access HTTPS web sites nor run ‘guix
pull’?

>> For those who do not have ‘nss-certs’ installed, a workaround is to do
>> avoid HTTPS:
>
> The original motivation of le-certs was that nss-certs would not be
> required, and that `guix pull` would always work. I think we should
> still try to achieve this.

OK.

>> We could also add a ‘--no-check-certificates’ option to ‘guix pull’.
>
> I think we should avoid adding "use insecure connection" options. Even
> if the code itself is signed.

“Insecure” is a strong word: it still prevents eavesdropping, which is
the only property that matters in the presence of authenticated
channels.

> I'm going to figure out how to subscribe to Let's Encrypt announcements
> and I'll report back with ideas about how to avoid a repeat of the
> problem.

Yes, that’s the better option.  Thank you!

Ludo’.