GNU bug report logs - #36363
let's encrypt hash mismatch

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 36363 in the body.
You can then email your comments to 36363 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Julien Lepiller <julien <at> lepiller.eu>
To: bug-guix <at> gnu.org
Subject: let's encrypt hash mismatch
Date: Mon, 24 Jun 2019 19:23:02 +0200

Hi!

trying to run guix pull on the overdrive at my place to try and fix a
bug in openssh which doesn't start at boot, I get this error message:

building /gnu/store/qvrwd6v9jy50j121f963v7rps8fc8qsa-isrgrootx1.pem.drv...
building /gnu/store/3s8l6bg8gsfxrqallc5w02drl1m021ky-letsencryptauthorityx3.pem.drv...

Starting download
of /gnu/store/1drx7dy1zakc0xs60nb0im1jbvxp11dj-isrgrootx1.pem From
https://letsencrypt.org/certs/isrgrootx1.pem...

Starting download
of /gnu/store/bcq7sqhg18b7b1q87j8z60d5hybsdafm-letsencryptauthorityx3.pem
From https://letsencrypt.org/certs/letsencryptauthorityx3.pem...
downloading from https://letsencrypt.org/certs/isrgrootx1.pem...
downloading from
https://letsencrypt.org/certs/letsencryptauthorityx3.pem...

 letsencryptauthorityx3.pem  2KiB     385KiB/s 00:00
 [##################] 100.0% sha256 hash mismatch
 for /gnu/store/1drx7dy1zakc0xs60nb0im1jbvxp11dj-isrgrootx1.pem:
 expected hash: 0zhd1ps7sz4w1x52xk3v7ng6d0rcyi7y7rcrplwkmilnq5hzjv1y
 actual hash:   0zycy85ff9ga53z1q03df89ka9iihb9p8bjhw056rq2y4rn3b6ac
 hash mismatch for store item
 '/gnu/store/1drx7dy1zakc0xs60nb0im1jbvxp11dj-isrgrootx1.pem' build
 of /gnu/store/qvrwd6v9jy50j121f963v7rps8fc8qsa-isrgrootx1.pem.drv
 failed View build log at
 '/var/log/guix/drvs/qv/rwd6v9jy50j121f963v7rps8fc8qsa-isrgrootx1.pem.drv.bz2'.
 cannot build derivation
 `/gnu/store/03xigpq7w1ll67ydrwhjydmybdj5gd2i-le-certs-0.drv': 1
 dependencies couldn't be built guix pull: error: build failed: build
 of `/gnu/store/03xigpq7w1ll67ydrwhjydmybdj5gd2i-le-certs-0.drv' failed


Thanks!

Message #8 received at 36363 <at> debbugs.gnu.org (full text, mbox):

From: Tobias Geerinckx-Rice <me <at> tobias.gr>
To: julien lepiller <roptat <at> lepiller.eu>
Cc: 36363 <at> debbugs.gnu.org
Subject: Re: bug#36363: let's encrypt hash mismatch
Date: Mon, 24 Jun 2019 20:44:07 +0200

[Message part 1 (text/plain, inline)]

Julien,

Julien Lepiller wrote:
> trying to run guix pull on the overdrive at my place to try and 
> fix a
> bug in openssh which doesn't start at boot, I get this error 
> message:

[…]

>  letsencryptauthorityx3.pem  2KiB     385KiB/s 00:00
>  [##################] 100.0% sha256 hash mismatch
>  for /gnu/store/1drx7dy1zakc0xs60nb0im1jbvxp11dj-isrgrootx1.pem:
>  expected hash: 
>  0zhd1ps7sz4w1x52xk3v7ng6d0rcyi7y7rcrplwkmilnq5hzjv1y
>  actual hash: 
>  0zycy85ff9ga53z1q03df89ka9iihb9p8bjhw056rq2y4rn3b6ac

This will keep happening until we find(/create) a versioned URL 
for these files.  Let's Encrypt like to change them in place.

The last time this happened they'd added CR/LF line endings for no 
reason at all, but this time I don't have the old version around 
anymore…

Kind regards,

T G-R

[signature.asc (application/pgp-signature, inline)]

Message #11 received at 36363 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Julien Lepiller <julien <at> lepiller.eu>
Cc: 36363 <at> debbugs.gnu.org
Subject: Re: bug#36363: let's encrypt hash mismatch
Date: Mon, 24 Jun 2019 22:09:23 +0200

Hi Julien,

Julien Lepiller <julien <at> lepiller.eu> 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?

HTH,
Ludo’.

Message #14 received at 36363 <at> debbugs.gnu.org (full text, mbox):

From: Chris Marusich <cmmarusich <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 36363 <at> debbugs.gnu.org, Julien Lepiller <julien <at> lepiller.eu>
Subject: Re: bug#36363: let's encrypt hash mismatch
Date: Sun, 21 Jul 2019 16:12:25 -0700

[Message part 1 (text/plain, inline)]

Ludovic Courtès <ludo <at> gnu.org> writes:

> Julien Lepiller <julien <at> lepiller.eu> 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 (application/pgp-signature, inline)]

Message #17 received at 36363 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Chris Marusich <cmmarusich <at> gmail.com>
Cc: 36363 <at> debbugs.gnu.org, Julien Lepiller <julien <at> lepiller.eu>
Subject: Re: bug#36363: let's encrypt hash mismatch
Date: Mon, 22 Jul 2019 12:34:05 +0200

Hi Chris,

Chris Marusich <cmmarusich <at> gmail.com> skribis:

> Ludovic Courtès <ludo <at> gnu.org> writes:
>
>> Julien Lepiller <julien <at> lepiller.eu> 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.

This is used by (guix scripts pull) so we can always authenticate
git.savannah.gnu.org when we fetch from the Git repo.  It’s used if and
only if certificates aren’t available system-wide (see
‘honor-x509-certificates’.)

Ludo’.

Message #22 received at 36363-done <at> debbugs.gnu.org (full text, mbox):

From: Tobias Geerinckx-Rice <me <at> tobias.gr>
To: 36363-done <at> debbugs.gnu.org
Subject: Re: let's encrypt hash mismatch
Date: Fri, 09 Oct 2020 14:04:29 +0200

[Message part 1 (text/plain, inline)]

Closing as this specific failure has passed and any wider 
discussion shouldn't happen here.

Kind regards,

T G-R

[signature.asc (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.