bug#36363: let's encrypt hash mismatch

[Chris Marusich]

Ludovic Courtès <address@hidden> writes:

> Julien Lepiller <address@hidden> skribis:
>
>>  expected hash: 0zhd1ps7sz4w1x52xk3v7ng6d0rcyi7y7rcrplwkmilnq5hzjv1y
>>  actual hash:   0zycy85ff9ga53z1q03df89ka9iihb9p8bjhw056rq2y4rn3b6ac
>>  hash mismatch for store item
>>  '/gnu/store/1drx7dy1zakc0xs60nb0im1jbvxp11dj-isrgrootx1.pem' build
>
> I believe you’d be fine if substitutes were enabled, but they’re not.
>
> In the meantime, you can fetch those files with something like:
>
>   wget -O /tmp/isrgrootx1.pem \
>     
> http://berlin.guix.gnu.org/file/isrgrootx1.pem/sha256/0zhd1ps7sz4w1x52xk3v7ng6d0rcyi7y7rcrplwkmilnq5hzjv1y
>   guix download file:///tmp/isrgrootx1.pem
>
> But yeah, like Tobias writes, it’s a bit of a problem.  Should we mirror
> them somewhere?  Does Let’s Encrypt have them under a versioned URL
> elsewhere?

What is Guix using these files for?  I realize it's got something to do
with TLS, but it isn't clear to me why Guix downloads these certs.

I don't have the full context, so please forgive me if my comments are
unhelpful, but before deciding to use stale versions, I think it's worth
asking, "Could using a stale version introduce any security risk?"
Maybe there's a reason why LE doesn't publish the old versions.

-- 
Chris

signature.asc
Description: PGP signature