Let's Encrypt certificate store (le-certs) expired

  • Done
  • quality assurance status badge
Details
7 participants
  • Andreas Enge
  • François
  • Leo Famulari
  • Ludovic Courtès
  • Christopher Baines
  • Maxime Devos
  • zimoun
Owner
unassigned
Submitted by
Christopher Baines
Severity
important
C
C
Christopher Baines wrote on 28 Feb 2021 11:27
Fresh install of 1.2.0 can't guix pull
(address . bug-guix@gnu.org)
871rd0ebd5.fsf@cbaines.net
I believe there's TLS issues with pulling for the current 1.2.0 release.

root@horna ~# guix pull
substitute: updating substitutes from 'https://guix.cbaines.net'... 100.0%
0.0 MB will be downloaded
le-certs-0 4KiB 1.8MiB/s 00:00 [##################] 100.0%

Updating channel 'guix' from Git repository at 'https://git.savannah.gnu.org/git/guix.git'...
guix pull: error: Git error: the SSL certificate is invalid

Resolving git.savannah.gnu.org (git.savannah.gnu.org)... 209.51.188.201, 2001:470:142:5::201
Connecting to git.savannah.gnu.org (git.savannah.gnu.org)|209.51.188.201|:443... connected.
ERROR: The certificate of ‘git.savannah.gnu.org’ is not trusted.
ERROR: The certificate of ‘git.savannah.gnu.org’ doesn't have a known issuer.


This is probably possible to work around by doing:


As the commit signatures are checked, the risk of not using HTTPS should
be reduced.
-----BEGIN PGP SIGNATURE-----

iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAmA7b/ZfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF
ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2Jh
aW5lcy5uZXQACgkQXiijOwuE9XeOqA/9EdO2KeqvOTkTncwzaaBseIXXUy38m167
xnTELIZbibF5ZyiuUA2qZ3svEvgmfDcXT5Fo7lKjKhtXlRihzjWfxkagDITGq0qT
EuMbB+DWDY/vUnD9IWWCyh14x6kfZWb9Am6qYSHPO6WTfVrBzaxe8MYNshHlEMXi
AABAy+ccUmDLcRSmgi532PDV/DQsMgn9oc5zzIOVMq55UzbtLsyp8JkbXnzjCkpk
sNws1lxsheLpGKPUuaNCW94tPrF96R+ZXj+qbQ+HeMNIVGErG2QhnUzVgAA7wm6M
XFC9/ij7AX9gwxHvhN0Zf8pOIFIiPKFstVXZi2ebdFbTnRUgg5P4Esgd7maXxCx2
YG3ktGeopfOdRHMc+przfwtLGM5snRvI8yIKyCXqgbJuRVhHhV7+4B1aeBCyCx2X
3qdyzWqSIgezrWqpUI25rDlCyvxgOOwso67pAgbFpNEZYOX9sNvRnbuwi7LQRssc
t/mqFos65ajp8RRVDaLwFvksI5twuF9/B8hi1IVjADS72K6dv+wSHKFzBlUYP0RB
wcKB9jZ70zORW4ALvWAYUaclKns1Ed5a5m588GSkt1Z6DSRYJVl5Jm7hk07gsZ7/
AEDpBeec4cYjWDAMxfdFBMmcDU6bLivAICMf2s0xscsRp2cEaB0rHDVKTR4r9zcg
Se5uA5WSwfs=
=8Wb6
-----END PGP SIGNATURE-----

A
A
Andreas Enge wrote on 28 Feb 2021 12:06
(name . Christopher Baines)(address . mail@cbaines.net)(address . 46829@debbugs.gnu.org)
YDt5OveAM8d/Ngmx@jurong
Am Sun, Feb 28, 2021 at 10:27:02AM +0000 schrieb Christopher Baines:
Toggle quote (4 lines)
> I believe there's TLS issues with pulling for the current 1.2.0 release.
> Updating channel 'guix' from Git repository at 'https://git.savannah.gnu.org/git/guix.git'...
> guix pull: error: Git error: the SSL certificate is invalid

I noticed the same for the following, slightly older version:
branch: master
commit: 0939462e3f81bc98b38bdb7610e6a80ca1cbaa1b

And it also occurs with the current master checkout using
./pre-inst-env guix pull

I tried again after updating my nss-certs package, but it did not make
any difference.

This is on dover, an aarch64 machine. I successfully did "guix pull"
on other machines, however.

Andreas
A
A
Andreas Enge wrote on 28 Feb 2021 12:10
(name . Christopher Baines)(address . mail@cbaines.net)(address . 46829@debbugs.gnu.org)
YDt6F596AjlNoW1o@jurong
Am Sun, Feb 28, 2021 at 10:27:02AM +0000 schrieb Christopher Baines:
Toggle quote (3 lines)
> This is probably possible to work around by doing:
> guix pull --url=http://git.savannah.gnu.org/git/guix.git

This works, thanks for sharing! But it prints a nonsensical warning message:
Updating channel 'guix' from Git repository at 'http://git.savannah.gnu.org/git/guix.git'...
Authenticating channel 'guix', commits 9edb3f6 to bebfe06 (7,806 new commits)...
guix pull: warning: pulled channel 'guix' from a mirror of https://git.savannah.gnu.org/git/guix.git,which might be stale
Building from this channel:

It is weird to call the https location a potentially stale mirror of the
http location.

Andreas
Z
L
L
Ludovic Courtès wrote on 1 Mar 2021 11:15
(name . Andreas Enge)(address . andreas@enge.fr)
87eegztc1s.fsf@gnu.org
Hi,

Andreas Enge <andreas@enge.fr> skribis:

Toggle quote (10 lines)
> This works, thanks for sharing! But it prints a nonsensical warning message:
> Updating channel 'guix' from Git repository at 'http://git.savannah.gnu.org/git/guix.git'...
> Authenticating channel 'guix', commits 9edb3f6 to bebfe06 (7,806 new commits)...
> guix pull: warning: pulled channel 'guix' from a mirror of https://git.savannah.gnu.org/git/guix.git, which might be stale
> Building from this channel:
> guix http://git.savannah.gnu.org/git/guix.git bebfe06
>
> It is weird to call the https location a potentially stale mirror of the
> http location.

There’s no way to know that the two URLs point to the same thing, hence
the message.

Thanks,
Ludo’.
L
L
Ludovic Courtès wrote on 1 Mar 2021 11:19
(name . Christopher Baines)(address . mail@cbaines.net)(address . 46829@debbugs.gnu.org)
877dmrtbvn.fsf@gnu.org
Hi,

Christopher Baines <mail@cbaines.net> skribis:

Toggle quote (11 lines)
> I believe there's TLS issues with pulling for the current 1.2.0 release.
>
> root@horna ~# guix pull
> substitute: updating substitutes from 'https://guix.cbaines.net'... 100.0%
> 0.0 MB will be downloaded
> downloading from https://guix.cbaines.net/nar/lzip/zg72c146skpca45ijvjigqhqgx0mwiny-le-certs-0 ...
> le-certs-0 4KiB 1.8MiB/s 00:00 [##################] 100.0%
>
> Updating channel 'guix' from Git repository at 'https://git.savannah.gnu.org/git/guix.git'...
> guix pull: error: Git error: the SSL certificate is invalid

That’s on an installation without ‘nss-certs’ in the system profile,
right?

I suppose we need to update the ‘le-certs’ package, or maybe skip X.509
certification verification altogether for the ‘guix’ channel?

Thanks,
Ludo’.
A
A
Andreas Enge wrote on 1 Mar 2021 13:03
(name . Ludovic Courtès)(address . ludo@gnu.org)
YDzYKCEmofz1LUcP@jurong
Am Mon, Mar 01, 2021 at 11:19:08AM +0100 schrieb Ludovic Courtès:
Toggle quote (3 lines)
> That’s on an installation without ‘nss-certs’ in the system profile,
> right?

Yes, I installed nss-certs into the profiles from which I wanted to do
the "guix pull".

Andreas
L
L
Ludovic Courtès wrote on 1 Mar 2021 15:10
control message for bug #46829
(address . control@debbugs.gnu.org)
87mtvnrmlu.fsf@gnu.org
severity 46829 important
quit
C
C
Christopher Baines wrote on 5 Mar 2021 11:49
Re: bug#46829: Fresh install of 1.2.0 can't guix pull
(name . zimoun)(address . zimon.toutoune@gmail.com)(address . 46829@debbugs.gnu.org)
87tuppnae7.fsf@cbaines.net
zimoun <zimon.toutoune@gmail.com> writes:

Toggle quote (11 lines)
> Hi Chris,
>
> On Sun, 28 Feb 2021 at 10:27, Christopher Baines <mail@cbaines.net> wrote:
>> I believe there's TLS issues with pulling for the current 1.2.0
>> release.
>
> Is this bug different from <http://issues.guix.gnu.org/issue/44559#8>?
>
> And fixes are also discussed here:
> <http://issues.guix.gnu.org/issue/46650>.

Yes, this bug is about a problem with guix pull, whereas #44559 relates
to a specific issue building the gnutls package.
-----BEGIN PGP SIGNATURE-----

iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAmBCDKBfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF
ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2Jh
aW5lcy5uZXQACgkQXiijOwuE9XdG+hAAsOUm8Yfw1MD2m0oei0pLmVHB/+TwbCWW
S+ax0zUeHx3nP8NcPmj7qlOxq3bpvg78Uryp25fD7xiEsUwMcUzpQXjP/0x9o4O0
XChUV9jAAIJzGyF1QGrs28Mc0eqfzVrqLu6gYj8SnKbKD8Rpdd5kuw/luyTCvC9j
ZXe4TRLdFh8bHLMxyAedtBWssHTbzyo/f+xLciOxueA26kj+WOGCKiper/ujJ7GH
rvVoniCBelr7GzP5boWXxvGX91c1dZAt254nvcPtSc1ZL61sViYgZNT3lqZuNPHd
GwtfQim5XVP1dd8QdSrF0p3FL2fSmKH/vbCz2mVRUpQ/+8VDZaAI23GxdIU4XNtm
IX6riHYN59qDTIk9wl5cE+GyndTWE5H2Edubx06XcNLrYiuKZiGht+q4SAjeBBid
hz2BmqHjQJ51AV6wjyit583rch+7q/7g8c3rTuFjveSo6i1WpecLNIyMW4neAtVD
0w/AzJnO4TJzfp35zQKKPMwAM0v+97531x/MPxMdnMPSZAHzxkPRROZtOX3rurfD
knNh/Q0wVHw68/QBp6EYcnW0eJCiyQfdxUhEG69uj1GOZkDS7H9JVsi8E2TDssEk
VKAC1uap5THjAIPdCWYR9uMUqFDeddhFDh7dp0nL3dsufK4F6muenPvIsWkOrlGw
WILE1i7+Sik=
=Poyg
-----END PGP SIGNATURE-----

L
L
Ludovic Courtès wrote on 17 Mar 2021 15:36
(name . Christopher Baines)(address . mail@cbaines.net)(address . 46829@debbugs.gnu.org)
877dm54zk3.fsf@gnu.org
Hi,

Ludovic Courtès <ludo@gnu.org> skribis:

Toggle quote (16 lines)
> Christopher Baines <mail@cbaines.net> skribis:
>
>> I believe there's TLS issues with pulling for the current 1.2.0 release.
>>
>> root@horna ~# guix pull
>> substitute: updating substitutes from 'https://guix.cbaines.net'... 100.0%
>> 0.0 MB will be downloaded
>> downloading from https://guix.cbaines.net/nar/lzip/zg72c146skpca45ijvjigqhqgx0mwiny-le-certs-0 ...
>> le-certs-0 4KiB 1.8MiB/s 00:00 [##################] 100.0%
>>
>> Updating channel 'guix' from Git repository at 'https://git.savannah.gnu.org/git/guix.git'...
>> guix pull: error: Git error: the SSL certificate is invalid
>
> That’s on an installation without ‘nss-certs’ in the system profile,
> right?

Looking at (guix scripts pull), I think that is the case:

(define (honor-x509-certificates store)
"Use the right X.509 certificates for Git checkouts over HTTPS."
(unless (honor-system-x509-certificates!)
(honor-lets-encrypt-certificates! store)))

By default, 1.2.0 installs ‘nss-certs’, so I would assume such
installations are unaffected, right?

Toggle quote (3 lines)
> I suppose we need to update the ‘le-certs’ package, or maybe skip X.509
> certification verification altogether for the ‘guix’ channel?

In hindsight, it seems preferable to keep X.509 authentication for now,
because there are still unauthenticated channels out there and because
it’s a bit tedious to work around it in (guix channels) and (guix git).

I checked the ‘le-certs’ package like so:

Toggle snippet (24 lines)
$ guix gc --references $(guix build -d le-certs) |grep pem
/gnu/store/733k3s05nribnbbgc99w766gv7q36zgs-letsencryptauthorityx4.pem.drv
/gnu/store/92qqzmbfy72gs5knlpwrz8v2cf0fl1fs-isrgrootx1.pem.drv
/gnu/store/gm8rfnhlbvdql9dm43vag5p0lha56g4r-letsencryptauthorityx3.pem.drv
$ guix build --check -v1 $(guix gc --references $(guix build -d le-certs) |grep pem)
La jenaj derivoj estos konstruataj:
/gnu/store/gm8rfnhlbvdql9dm43vag5p0lha56g4r-letsencryptauthorityx3.pem.drv
/gnu/store/92qqzmbfy72gs5knlpwrz8v2cf0fl1fs-isrgrootx1.pem.drv
/gnu/store/733k3s05nribnbbgc99w766gv7q36zgs-letsencryptauthorityx4.pem.drv

building /gnu/store/92qqzmbfy72gs5knlpwrz8v2cf0fl1fs-isrgrootx1.pem.drv...
downloading from https://letsencrypt.org/certs/isrgrootx1.pem ...
|warning: rewriting hashes in `/gnu/store/hr94djs87lwgcyhz9ks3id3r1a4pgx2b-isrgrootx1.pem'; cross fingers
building /gnu/store/gm8rfnhlbvdql9dm43vag5p0lha56g4r-letsencryptauthorityx3.pem.drv...
downloading from https://letsencrypt.org/certs/letsencryptauthorityx3.pem ...
\warning: rewriting hashes in `/gnu/store/nfdm0gaa4s34aacr3jjp14wqynphkxcx-letsencryptauthorityx3.pem'; cross fingers
building /gnu/store/733k3s05nribnbbgc99w766gv7q36zgs-letsencryptauthorityx4.pem.drv...
downloading from https://letsencrypt.org/certs/letsencryptauthorityx4.pem ...
|warning: rewriting hashes in `/gnu/store/1ldg5q59n2qmq9qmbvyjnkjyxxjmflgh-letsencryptauthorityx4.pem'; cross fingers
/gnu/store/nfdm0gaa4s34aacr3jjp14wqynphkxcx-letsencryptauthorityx3.pem
/gnu/store/hr94djs87lwgcyhz9ks3id3r1a4pgx2b-isrgrootx1.pem
/gnu/store/1ldg5q59n2qmq9qmbvyjnkjyxxjmflgh-letsencryptauthorityx4.pem

AFAICS, everything is up-to-date here. So I don’t get where the ‘guix
pull’ error above comes from.

Ideas?

Ludo’.
L
L
Leo Famulari wrote on 23 Mar 2021 23:43
(no subject)
(address . control@debbugs.gnu.org)
YFpvDpAB4Qw66oTl@jasmine.lan
block 47297 with 46829
L
L
Leo Famulari wrote on 10 Apr 2021 21:02
Re: bug#46829: Fresh install of 1.2.0 can't guix pull
(name . Christopher Baines)(address . mail@cbaines.net)(address . 46829@debbugs.gnu.org)
YHH2U3HtEcuV6gK3@jasmine.lan
On Sun, Feb 28, 2021 at 10:27:02AM +0000, Christopher Baines wrote:
Toggle quote (2 lines)
> I believe there's TLS issues with pulling for the current 1.2.0 release.

On a fresh Debian ISO image, I installed Guix 1.2.0 based on the
instructions in the manual section Binary Installation.

Then, `guix pull` succeeded for me, no problem.

Can anyone reproduce still reproduce this bug?

Toggle quote (6 lines)
> root@horna ~# guix pull
> substitute: updating substitutes from 'https://guix.cbaines.net'... 100.0%
> 0.0 MB will be downloaded
> downloading from https://guix.cbaines.net/nar/lzip/zg72c146skpca45ijvjigqhqgx0mwiny-le-certs-0 ...
> le-certs-0 4KiB 1.8MiB/s 00:00 [##################] 100.0%

If it's still around, maybe you can share this store item? I wonder if
it got corrupted.
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEsFFZSPHn08G5gDigJkb6MLrKfwgFAmBx9lMACgkQJkb6MLrK
fwgPnw/+O1oYSbNRPzoJFPGXhyCAaQb3TFRZ+9C18R7O5QfJk7saGVJgzMZRNIwO
SZCFic2ICi4uFIzSWWuthB0J72iy/Zn0SWquNlizj7BF6qFirgruIBpCPxHC7qye
Yhck6JCqQz44S/wDrWgt6MQ7yFIjJfJsSzm9xm/a7YfLVYsWaH8B6+2FNwt2r1Fy
GWsnmNWFOoPTGhAXtTKhdlFWVhoJlnHZOlK03tqpkUOiY5JdoSmujGu42EwdEqbx
9hYeWvk7uMcp395W6PpnhrRWzgYwer85uxLYZRlyDAQBtqejfarJd1vE1LhvcYRP
8gVY3oWcQvY/30PuCCdLn72Q24Tw1sEOYlwODqwEMozOR2c6lLm8L9sjlC5CMMgQ
yytf1ex59BuEDLg65qKGwFBPla49U9THVTUrc1D9JCBkEkCbbFxdBC7Y+WQ5qMNL
6v+aUmWXCAGmcV5DRU0o8tk6lZZtpszK0jisY+0iBWPYdxXWTjNpOZyC3VcUZpps
rn1bQI5/Q+F8mG2B6hyCodCaDtiDcRhuls0njaaeZONCOgdyc0OIRY+6WjLIfJTv
tqzPduqgJ1nnWliIVp8D9l1siZddGnYgD/f+DpXGFLBsrL5k87sAnsTgqwmFitvs
79jB+oxKM8B0jSqIJ6LVTyXhiLYYXLR9h7fIGnbebQNQKE50ERk=
=tAhp
-----END PGP SIGNATURE-----


C
C
Christopher Baines wrote on 10 Apr 2021 21:45
(name . Leo Famulari)(address . leo@famulari.name)(address . 46829@debbugs.gnu.org)
874kgd2ab1.fsf@cbaines.net
Leo Famulari <leo@famulari.name> writes:

Toggle quote (10 lines)
> On Sun, Feb 28, 2021 at 10:27:02AM +0000, Christopher Baines wrote:
>> I believe there's TLS issues with pulling for the current 1.2.0 release.
>
> On a fresh Debian ISO image, I installed Guix 1.2.0 based on the
> instructions in the manual section Binary Installation.
>
> Then, `guix pull` succeeded for me, no problem.
>
> Can anyone reproduce still reproduce this bug?

I'm pretty sure I experienced this with a fresh install of Guix System,
I should have given more information in the initial report.
-----BEGIN PGP SIGNATURE-----

iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAmByAFJfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF
ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2Jh
aW5lcy5uZXQACgkQXiijOwuE9XczmRAAmHUyrqkzx4+IkGBwKc79ximKrju4KpCT
zbY9o9Jk6ZUepnOQOJKsaPUgSsI6YAkDoHk1E/qvjRtpgwyJ/u78aulVA9XTy8mJ
3qT1rlQBIkw9FXPkZ0S9prkMqTVm3TH5WAg/IR/WKbWMAk0GgLVxEsuBrwSMGQwu
V6JwzTou3bZ8pxABXGYxn2JlPgHqZfb6NwLaQR55aoZ4Vlx2wQck2PUcX4Ds7vPN
DC5anbqV/q8O6cABMR0CHIyL91LFzY+uwy3bPpxKd2s1XSd85naU2TJuqThUgUD4
ov7hx9xGnEDJqzLtyJxkKwuMs/1FzXDM4AWyuZ58sIU0adQOG9yk5ipWlQZsEF85
On6TGGGktgBK/YWv/bDDzEGdKSmfL4y2uXVOQrrz3af667pYghQ3/KRruj78q5HV
w/ZI74T2fDP3ktS6kjYKe/ixgwr4Un9pEqtX9hUZIxCoZlTMl98nfJAWSZHHL3Xz
oxNP5GA8x1XhdshvYerftCKdifbPXkX6aC2o3VM2HPNxQHxmmtbvbP0M2BYm82aA
DsIxP5TDTL5KRNKkjPSSRJFJottQKwHbEmaT6zcCUXsFzZYvcyHFWFNU/lkHzIbh
nimcXO3REG8E/naBBlXAtKEWaL0XyaUIvs+8UD0BRgQG4OCX+3e0GHIKx4RYovyX
eG6c+fT71Wk=
=rv8N
-----END PGP SIGNATURE-----

L
L
Leo Famulari wrote on 10 Apr 2021 22:30
(name . Christopher Baines)(address . mail@cbaines.net)(address . 46829@debbugs.gnu.org)
YHIK8sKyyIEJJGzW@jasmine.lan
On Sat, Apr 10, 2021 at 08:45:22PM +0100, Christopher Baines wrote:
Toggle quote (16 lines)
>
> Leo Famulari <leo@famulari.name> writes:
>
> > On Sun, Feb 28, 2021 at 10:27:02AM +0000, Christopher Baines wrote:
> >> I believe there's TLS issues with pulling for the current 1.2.0 release.
> >
> > On a fresh Debian ISO image, I installed Guix 1.2.0 based on the
> > instructions in the manual section Binary Installation.
> >
> > Then, `guix pull` succeeded for me, no problem.
> >
> > Can anyone reproduce still reproduce this bug?
>
> I'm pretty sure I experienced this with a fresh install of Guix System,
> I should have given more information in the initial report.

Okay, I'm testing this now, in a VM.

I wonder if it's the same thing as
L
L
Leo Famulari wrote on 10 Apr 2021 23:09
(name . Christopher Baines)(address . mail@cbaines.net)(address . 46829@debbugs.gnu.org)
YHIT/KFNpXvndY3U@jasmine.lan
On Sat, Apr 10, 2021 at 04:30:42PM -0400, Leo Famulari wrote:
Toggle quote (5 lines)
> Okay, I'm testing this now, in a VM.
>
> I wonder if it's the same thing as
> <https://lists.gnu.org/archive/html/help-guix/2021-04/msg00075.html>?

I followed the instructions in the manual section Installing Guix in a
VM.

Then, I booted the new system, opened a terminal emulator in the XFCE
desktop environment, and ran `guix pull`. It succeeded.
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEsFFZSPHn08G5gDigJkb6MLrKfwgFAmByE/gACgkQJkb6MLrK
fwjE2g/8CraqmepnBO+oM/1aptkncSEmiXnhT67/pVJqT5RDgK/dkBdJ3RCV3Vpj
+ucaQ8zAzPzNK/nFUiUCFAoSIB+rZrFgc94z4Qa56B/Dp0z+gubRikabzs00JK66
eQYDqLLCgNyjzu1LtcDrs2WoaQxl6wCaGrEd80qjVvstCSBrQZ/EqYp2LgDDJX7x
sBHqubSXbNRLq8KDvapDC5wmoak02LDrppvQKK5oclFHZEV7UGxNih6MxM/nu6wr
BKkHXN6eKT63Jq3m6B6cSiEzKzW7OE7h9HoW7lEzoSlwXGhTcP6Gxn/+0XbxWfXc
X8rkbd7Ez8Paje+0dq2gomLjGhxM8H2JbmLveXI5KJzW6CJAqirty17UPndBhr3N
U30rNX1dovqzImVAC9mBp2bjrWB/bpBiKItbDHh+QYf9CtoKWr1XOAVy5f8qKQmn
3lJpGNn9tPmPEMFtPG5Q2bJafU/VrK6jBMcrNZqCjoEwxl6xi2MCvGQtP831zemm
D6491LCxxUk4X9qRrU84jsceDTlxXrK9kGS4zUvddHrfgaYUFcvIdssgO8x7TpO5
DRW4wlsEMqqgfmZUWEpKTwLu2MyGrmgjxgpjE2KsC5ZyVlTbwDpvUTMN8t0sog+v
iJVnWF9Fa5oiCSCe/yAgpEw1y9RkU5uRK6GUIvYmJSGEhyAws9Q=
=SJd1
-----END PGP SIGNATURE-----


C
C
Christopher Baines wrote on 10 Apr 2021 23:21
(name . Leo Famulari)(address . leo@famulari.name)(address . 46829@debbugs.gnu.org)
871rbh25uo.fsf@cbaines.net
Leo Famulari <leo@famulari.name> writes:

Toggle quote (12 lines)
> On Sat, Apr 10, 2021 at 04:30:42PM -0400, Leo Famulari wrote:
>> Okay, I'm testing this now, in a VM.
>>
>> I wonder if it's the same thing as
>> <https://lists.gnu.org/archive/html/help-guix/2021-04/msg00075.html>?
>
> I followed the instructions in the manual section Installing Guix in a
> VM.
>
> Then, I booted the new system, opened a terminal emulator in the XFCE
> desktop environment, and ran `guix pull`. It succeeded.

Maybe it just doesn't work for the root user... I encountered this when
running guix pull as the root user on a headless machine.
-----BEGIN PGP SIGNATURE-----

iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAmByFt9fFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF
ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2Jh
aW5lcy5uZXQACgkQXiijOwuE9XeD6xAAgNtwasNX+zTlC95YHMe1t90ds2oVoCGY
fEdfEwjCGSMKkemVA9V+HODECLDY2vcYios0Cwxi/fgntlG4l+gq6TvkctF1RwTX
CodP3mUmIYMK/+eGY/TQyUvVPsFHbPO4toEgTtSmCLHiMdw2SZdx2lkhq+mPwOXk
uVI+OxZATXOV8+jfnUQbq8gfvFdfWOU7BkyJV9MJj8pm1Q+Gb0qcW2eIh2tLOhe6
6Ul6lBGZa4aqM7pi918PDO8wMk42DOGexsR7/9mlX5xGNI4lc26Btk8CDP9CPTk3
d9k3BfVdGyLxZ56XQLdzadVOJ34lJZIiIhUhuOyTWi3qr1XRpCtXlY7izzihrzHE
84pRU69J72sK+bcPQWiRUZBK9ttl//xIZzADe2idCWhT1QstSjFeygWp3nWmJmUy
V6Bd/ZRDj/rL8klMsKmna4mJasCWhjHTcuWzHsJkyKT2Slvg8OctsSfH9YkuMEZU
6dC5DEu6tkdnfYhoTBl0TpOHIpNZA0oYraGdh7u/VejR8LCYZVaa7GvqrMwaGPgH
IqrwgZ/F5kMPsar/nlf7FbKfd8pbAeOoAZ7MvJcEs1iYxuVEGsnNI+WEkLssPTOY
WoR9NZS/bHJv5aUPIycDlGVa6HZSz2z4k+0Nv55wptV4PLOZq/KAjAjEIbuVqWbM
gqsKGP+oDkg=
=lpHl
-----END PGP SIGNATURE-----

L
L
Leo Famulari wrote on 11 Apr 2021 00:54
(name . Christopher Baines)(address . mail@cbaines.net)(address . 46829@debbugs.gnu.org)
YHIsn+kLD/FaKGY1@jasmine.lan
On Sat, Apr 10, 2021 at 10:21:35PM +0100, Christopher Baines wrote:
Toggle quote (3 lines)
> Maybe it just doesn't work for the root user... I encountered this when
> running guix pull as the root user on a headless machine.

I logged in as root from the console, and `guix pull` worked there too.
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEsFFZSPHn08G5gDigJkb6MLrKfwgFAmByLJ4ACgkQJkb6MLrK
fwgIcw/9FH8fV6eFN9nAoOXI15JiYweGThBzoJ9qjKhf9nSkmD6TH552prxuvUV9
i5gVEqV9G5Qtp0OThXh1FMhv22WPFr9o+ADWQT/WzGToCyUUwCxNVpLrGUF9NSe4
wTx+3rjza6wtVz/SXi1lv46FkaciQBC74nJKPGRa+lYStxroJ4jK2QIw2V1rkpQu
A+LOa4BVOK2B2zziNOdqDpW1SoLYagyyc7RTEunyA7yGj/8BW1CFigCAddA7w5A2
NUM+Q9y4PZ4L85/9Zop5TP1yhfKmtxqBytcqwsU7vzJWS0mCf0mXc6x2kJQkFaq/
l5gBKm3LAe3caRbdSiTX77a/8KUdfaMn0qaXxgeIf49QKvhQm7H9viZk6aM2BaR4
j/A69O4AUjITpg+bt8blkxlPp7Nez6U+axnNYpBt7yS1mpn6S/fJ2QZ6gp1fkjJB
9ofSeJrcdDhJE7qCcV7uIZ/aDmXp85KpeRWJle3wVamLrNRlkRPPabchCfLzHJNW
KadpSyjwviFbuQEEttOghtLqZ3JbEnaI8OegPOvGUC+eVmgyemhMhzidJd82wFup
NT9Ab+YKY/NTabOuJLP1dg+Q9DriVWWGHdkVvRCGXc7rWJ0sAzT0N+1bH7Q320ef
auiInlsDmyDAhMaBVgRFVkaUKYxUiD1P8GT7YE2MzUxZn8ByJi0=
=1JMY
-----END PGP SIGNATURE-----


L
L
Leo Famulari wrote on 11 Apr 2021 01:04
(name . Christopher Baines)(address . mail@cbaines.net)(address . 46829@debbugs.gnu.org)
YHIu/GrtQ1d7qYJE@jasmine.lan
On Sun, Feb 28, 2021 at 10:27:02AM +0000, Christopher Baines wrote:
Toggle quote (2 lines)
I downloaded this file, un-lzipped it, and extracted the nar. The
results are bit-identical to the le-certs from ci.guix.gnu.org.

Maybe there was a momentary misconfiguration on Savannah? Or something
like that?
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEsFFZSPHn08G5gDigJkb6MLrKfwgFAmByLvwACgkQJkb6MLrK
fwgN3Q//eneOUN5hVPMq5e8nKlnA6wttWHIQX8M07dJQBQAFk3fqGq/cnmluvF5z
AJmAjjGjy+RCBNeFOut0oiKl1AQ9cxn8arASGmIKhXI9CNddKxUj+DPTTBq1Qngh
VgQdUuDq+vn2iv0vYfhafJUHW6VXu0TZEABiA4P3rRSULZwV22WbQZih1m+pPKFB
yP6mBlFunNAW1vGr7dGFbPfI8Hkwr882vR2c8M4a78mYIhQMksPFd/ZWi7kI8iK2
OdcoIY6nq8VDDydHvPbscnfqjevVshs4CVdeZOagEOO2olxABC1GM4MdkpqpalLd
unPasXghb9mJ4grXQN+2uN40pcEjbWb9NPdOdTWLmn3/D+f8e3pO09xSvI5QVNIi
yqXbG5/uliaK2C3AKWDxOQ4TuBapjYAtVPNiFUKoN+sznowQD0U73enR/gm/1MB5
QeiLt7kiKKTQOf3ZnhWWnW9oOQEkLPDCyTneu81RMFE23tun7/IKSLTR+XxhguET
besiCoiN25vTzWFbUpRTfz7FBWMV6ZdrzQ+/lcZCu2iAuptrsU7M+C79VZGBzuDB
nhNH2vebgzm4FO5bGcT8b5eEOgB+uDqeCoreap2v0Ua7GBxqoqLjR7dmpwdQOy3P
lnrVZKMyvyPzs3ei0Oy6bKpCUVqdHlMlmX6l9ESshN/vxOELApk=
=OYY5
-----END PGP SIGNATURE-----


L
L
Leo Famulari wrote on 11 Apr 2021 01:13
(name . Christopher Baines)(address . mail@cbaines.net)(address . 46829@debbugs.gnu.org)
YHIxBQxdVtsnzKdX@jasmine.lan
On Sun, Feb 28, 2021 at 10:27:02AM +0000, Christopher Baines wrote:
Toggle quote (7 lines)
> --2021-02-28 11:22:49-- https://git.savannah.gnu.org/git/guix.git
> Resolving git.savannah.gnu.org (git.savannah.gnu.org)... 209.51.188.201, 2001:470:142:5::201
> Connecting to git.savannah.gnu.org (git.savannah.gnu.org)|209.51.188.201|:443... connected.
> ERROR: The certificate of ‘git.savannah.gnu.org’ is not trusted.
> ERROR: The certificate of ‘git.savannah.gnu.org’ doesn't have a known issuer.

By the way, it's expected that wget would fail here, if you had not
installed and configured nss-certs as directed in the manual.

`guix pull` uses its own certificate store (le-certs), and it's
suppposed to happen automatically.
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEsFFZSPHn08G5gDigJkb6MLrKfwgFAmByMQIACgkQJkb6MLrK
fwjQig//dCYXbYyJjtmhqZNfD5+ON5kK7DbguPTihFZwIv7Lsp/J5zIjh2F69jN6
8m9r0O/IVJDl6w90d/gdWA6222K+80hTBN49qQSAYVXAElmGk1/ecla5KtVtw9SR
zvT3XIz+TasNmV+jmieZWrGn8oIuxt0/3GNWXBKrLHDtX2NFhcWTsAoyA6e3fiPY
Mh2o/FBpMqJzjTVfDM8MexHG0FH0E/QAbE/m/gOxaTqnISF2kPt4Bq7oWG/WQ/BM
Mn8Ks0tovB1yI15G/WTQA+geTx2tQ5NLpnL6k4GVH0yGseM/qrYwpsfT7WwI3PEL
BL/3qZpl1CVDNjvEUYUrUuh3fufxTn8ABd4BEwo2uyhA/bhGmn2jVHRgJ0fgORau
ZBHw8Grp/ABYmdWt4EgeOp56IlV2uHMyI6Ay9OtVaFpGRsaFWhnI8Gt3lXOYLCNZ
mvCh7v23CpBf+y2rYkdBzGMlY5RN0wRvU2UAzXBV4bmlzCCs16IAssX840h+f+0b
IFS7jdBx4G62K0xhz47RRYFtmw+kHNNzlkeWxVTlS+gyM7vwc7YBoTPqajNMRbcI
SmdfOgL8RVo5zrD4d9A96zvwjjAqMe5F2+/tyL5zwGX8DBt1EcsBQZ6z8PDfC2Pa
Go60N5ozxs+EHuC2aM7cNqtfQJFLUeoDFzzkXPt1dxWkIvoT2js=
=HW43
-----END PGP SIGNATURE-----


L
L
Leo Famulari wrote on 11 Apr 2021 22:15
(no subject)
(name . GNU bug tracker automated control server)(address . control@debbugs.gnu.org)
YHNY8WY6DeV3Qqfd@jasmine.lan
retitle 46829 `guix pull` uses incorrect certificate store
L
L
Leo Famulari wrote on 11 Apr 2021 22:41
Re: bug#46829: Fresh install of 1.2.0 can't guix pull
(name . Ludovic Courtès)(address . ludo@gnu.org)
YHNe5+taYSQI70dt@jasmine.lan
On Wed, Mar 17, 2021 at 03:36:44PM +0100, Ludovic Courtès wrote:
Toggle quote (8 lines)
> (define (honor-x509-certificates store)
> "Use the right X.509 certificates for Git checkouts over HTTPS."
> (unless (honor-system-x509-certificates!)
> (honor-lets-encrypt-certificates! store)))
>
> By default, 1.2.0 installs ‘nss-certs’, so I would assume such
> installations are unaffected, right?

So, the bug here is that `guix pull` is using the wrong certificate
store. It should use le-certs, but is instead ignoring le-certs, and
looking for a system-wide store that doesn't exist.

I tested with an installer image from current master, and the bug still
exists.
L
L
Leo Famulari wrote on 12 Apr 2021 03:29
(name . Ludovic Courtès)(address . ludo@gnu.org)
YHOiXP0JJZZej+7H@jasmine.lan
On Sun, Apr 11, 2021 at 04:41:11PM -0400, Leo Famulari wrote:
Toggle quote (16 lines)
> On Wed, Mar 17, 2021 at 03:36:44PM +0100, Ludovic Courtès wrote:
> > (define (honor-x509-certificates store)
> > "Use the right X.509 certificates for Git checkouts over HTTPS."
> > (unless (honor-system-x509-certificates!)
> > (honor-lets-encrypt-certificates! store)))
> >
> > By default, 1.2.0 installs ‘nss-certs’, so I would assume such
> > installations are unaffected, right?
>
> So, the bug here is that `guix pull` is using the wrong certificate
> store. It should use le-certs, but is instead ignoring le-certs, and
> looking for a system-wide store that doesn't exist.
>
> I tested with an installer image from current master, and the bug still
> exists.

I checked and, although there have been some changes upstream at Let's
Encrypt [0], our le-certs still works for contacting Savannah with TLS.

[0] Some new root and intermediate certificates:


Once we fix this bug, we should look into updating the le-certs package.
L
L
Leo Famulari wrote on 12 Apr 2021 08:42
(name . Ludovic Courtès)(address . ludo@gnu.org)
YHPrv2NdqqaLWh42@jasmine.lan
On Sun, Apr 11, 2021 at 09:29:00PM -0400, Leo Famulari wrote:
Toggle quote (3 lines)
> I checked and, although there have been some changes upstream at Let's
> Encrypt [0], our le-certs still works for contacting Savannah with TLS.

I checked wrong; le-certs needs to be updated. I'm testing the update
now...

Toggle quote (3 lines)
> [0] Some new root and intermediate certificates:
>
> https://letsencrypt.org/certificates/
L
L
Leo Famulari wrote on 12 Apr 2021 10:30
(name . Ludovic Courtès)(address . ludo@gnu.org)
YHQFDOGNyqVlmWm0@jasmine.lan
On Mon, Apr 12, 2021 at 02:42:07AM -0400, Leo Famulari wrote:
Toggle quote (3 lines)
> I checked wrong; le-certs needs to be updated. I'm testing the update
> now...

I couldn't figure out how to test an update of the Guix package, but
here is my patch updating le-certs.

`make update-guix-package` segfaults for me, sometime after it updates
the source tree but before adding the source checkout to the store.

I did `guix build guix --with-git-url=guix=$PWD`, which succeeded, but
using --with-git-url changes the derivation, so I couldn't test this in
a VM sans nss-certs.
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEsFFZSPHn08G5gDigJkb6MLrKfwgFAmB0BQgACgkQJkb6MLrK
fwhNAw/9EYzBZ6zQc+zbIUvaR9agVJLJp+lqxy7uJBx7e0hTaCZWo8mXLMLLejF/
YlRkgmplAp+80whDoVByB7N7YjF1Qa8hDRsrVy7LwAFtUdCOGEOKkGmsfVVN7JoY
27tOXTf/kSM9x5GrFxT1koiGxVW3Jrp2wXlfs3ctLVR1fueIHGT7mEwYkBrvtRJ9
WT8wCbXScsqWXmeDx+wJDcxEJEC2fnOx4SVA91x3W9zaL8UtQ3qe2+83Iy5K0Brs
qhR5HMFrS++GQ2zGly+rBwEAEdtXtfTak7NHTlXc4PYkERTnjkjN/y9s+xJIr9Zc
o9f4J8NoSpDevxj1ifbsFOL+VzSKw8QTWt+7TGepAbjMd4361VAP0ScsL1yIMiNf
TcAiNIh4kUwQxtEfjGwI69TuIInnFALgz/5x6tPmb4m45SNfvJGTsr+mvzMrPYnI
AYSfRMBzQHBJLWry10XRY97tHEde88U4qmvObnSRnBpwG9LmlvXUkk0zbVC9WhXg
dR8W9Ye9joADDC1n1gkW9+O1KeQwyrnPeNzK+PZrwqCxUBPHU3OBYrEPhSBYTugs
aD8uyMVZECi2Ia2jTqjrL1c6aygoOu7A3KyrJUSpS6ZgMSHQ4HnOATRlgeTCziyO
41qvaP4KEYD00aeR+JOSFx25OHnjZ/wgsLnibNQnP0AQ/saX22E=
=Gnic
-----END PGP SIGNATURE-----


L
L
Ludovic Courtès wrote on 12 Apr 2021 14:25
(name . Leo Famulari)(address . leo@famulari.name)
87y2dnpu48.fsf@gnu.org
Hi Leo,

Leo Famulari <leo@famulari.name> skribis:

Toggle quote (3 lines)
> I couldn't figure out how to test an update of the Guix package, but
> here is my patch updating le-certs.

Cool!

Toggle quote (3 lines)
> `make update-guix-package` segfaults for me, sometime after it updates
> the source tree but before adding the source checkout to the store.

Could you grab a backtrace, with:

gdb $(which guile) core

where ‘core’ is the core file (it might live elsewhere on a foreign
distro). It could be that the foreign distro packages being used are
buggy, or that a mixture of Guix- and distro-provided libraries are
being loaded.

In the meantime, you could also update the ‘guix’ package by hand for
testing purposes.

Toggle quote (12 lines)
> From f0da45e7b78a6dd2b51dec1a948ea95866811c02 Mon Sep 17 00:00:00 2001
> From: Leo Famulari <leo@famulari.name>
> Date: Mon, 12 Apr 2021 02:19:33 -0400
> Subject: [PATCH] gnu: le-certs: Update to new Let's Encrypt certificates.
>
> * gnu/packages/certs.scm (le-certs): Update the certificate store.
> [inputs]: Add isrgrootx2.pem, letsencryptauthorityr3.pem,
> letsencryptauthorityr4.pem, letsencryptauthoritye1.pem, and
> letsencryptauthoritye2.pem. Remove letsencryptauthorityx3.pem and
> letsencryptauthorityx4.pem.
> [arguments]: Adjust the builder accordingly.

Nice! So how do we know if/when this has to be updated? Maybe we can
add a ‘release-monitoring-url’ property?

I just checked that the files currently in use were still there, and
they are, but they’re outdated.

Thanks!

Ludo’.
L
L
Ludovic Courtès wrote on 12 Apr 2021 14:25
(name . Leo Famulari)(address . leo@famulari.name)
87zgy3pu54.fsf@gnu.org
Hi Leo,

Leo Famulari <leo@famulari.name> skribis:

Toggle quote (3 lines)
> I couldn't figure out how to test an update of the Guix package, but
> here is my patch updating le-certs.

Cool!

Toggle quote (3 lines)
> `make update-guix-package` segfaults for me, sometime after it updates
> the source tree but before adding the source checkout to the store.

Could you grab a backtrace, with:

gdb $(which guile) core

where ‘core’ is the core file (it might live elsewhere on a foreign
distro). It could be that the foreign distro packages being used are
buggy, or that a mixture of Guix- and distro-provided libraries are
being loaded.

In the meantime, you could also update the ‘guix’ package by hand for
testing purposes.

Toggle quote (12 lines)
> From f0da45e7b78a6dd2b51dec1a948ea95866811c02 Mon Sep 17 00:00:00 2001
> From: Leo Famulari <leo@famulari.name>
> Date: Mon, 12 Apr 2021 02:19:33 -0400
> Subject: [PATCH] gnu: le-certs: Update to new Let's Encrypt certificates.
>
> * gnu/packages/certs.scm (le-certs): Update the certificate store.
> [inputs]: Add isrgrootx2.pem, letsencryptauthorityr3.pem,
> letsencryptauthorityr4.pem, letsencryptauthoritye1.pem, and
> letsencryptauthoritye2.pem. Remove letsencryptauthorityx3.pem and
> letsencryptauthorityx4.pem.
> [arguments]: Adjust the builder accordingly.

Nice! So how do we know if/when this has to be updated? Maybe we can
add a ‘release-monitoring-url’ property?

I just checked that the files currently in use were still there, and
they are, but they’re outdated.

Thanks!

Ludo’.
L
L
Leo Famulari wrote on 12 Apr 2021 19:02
(name . Ludovic Courtès)(address . ludo@gnu.org)
YHR9ERShZCqY//6Q@jasmine.lan
On Mon, Apr 12, 2021 at 02:25:43PM +0200, Ludovic Courtès wrote:
Toggle quote (3 lines)
> In the meantime, you could also update the ‘guix’ package by hand for
> testing purposes.

I tried this, but I can't figure out how to actually build the updated
Guix package, since the source code isn't added to the store.
L
L
Leo Famulari wrote on 12 Apr 2021 19:15
(name . Ludovic Courtès)(address . ludo@gnu.org)
YHSAH66jr+zxk232@jasmine.lan
On Mon, Apr 12, 2021 at 02:25:11PM +0200, Ludovic Court�s wrote:
Toggle quote (4 lines)
> Could you grab a backtrace, with:
>
> gdb $(which guile) core

I don't know where to find this 'core' file. I'm on Guix System (the
Berlin server).
L
L
Leo Famulari wrote on 12 Apr 2021 19:32
(name . Ludovic Courtès)(address . ludo@gnu.org)
YHSEJVTsObt2Zia+@jasmine.lan
On Mon, Apr 12, 2021 at 01:15:11PM -0400, Leo Famulari wrote:
Toggle quote (8 lines)
> On Mon, Apr 12, 2021 at 02:25:11PM +0200, Ludovic Courtès wrote:
> > Could you grab a backtrace, with:
> >
> > gdb $(which guile) core
>
> I don't know where to find this 'core' file. I'm on Guix System (the
> Berlin server).

I did `ulimit -c unlimited`, and then the core file was created at
/tmp/core.

I ran your command, and this is the output:

------
gdb $(which guile) /tmp/core
GNU gdb (GDB) 10.1
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
Find the GDB manual and other documentation resources online at:

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /gnu/store/ildwvd8sl92znmwpxlnp7pbjkfwccih4-profile/bin/guile...
(No debugging symbols found in /gnu/store/ildwvd8sl92znmwpxlnp7pbjkfwccih4-profile/bin/guile)

warning: Can't open file /home/lfam/.cache/guile/ccache/3.0-LE-8-4.4/home/lfam/guix/gnu/packages/package-management.scm.go (deleted) during file-backed mapping note processing
[New LWP 70404]
[New LWP 70409]
[New LWP 70408]
[New LWP 70412]
[New LWP 70411]
[New LWP 70413]
[New LWP 70410]
[New LWP 70417]
[New LWP 70414]
[New LWP 70416]
[New LWP 70415]
[New LWP 70418]
[New LWP 70419]
[New LWP 70421]
[New LWP 70422]
[New LWP 70420]
[New LWP 70423]
[New LWP 70424]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libthread_db.so.1".
Core was generated by `/gnu/store/66xwl53f9ws7gin8iaqkhg111gimw1li-profile/bin/guile ./build-aux/updat'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000000000000000 in ?? ()
[Current thread is 1 (Thread 0x7eff7d8cdb80 (LWP 70404))]
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;; or pass the --no-auto-compile argument to disable.
;;; compiling /gnu/store/m5iprcg6pb5ch86r9agmqwd8v6kp7999-guile-3.0.5/lib/libguile-3.0.so.1.3.0-gdb.scm
;;; /gnu/store/m5iprcg6pb5ch86r9agmqwd8v6kp7999-guile-3.0.5/lib/libguile-3.0.so.1.3.0-gdb.scm:293:20: warning: possibly unbound variable `program-debug-info-name'
;;; /gnu/store/m5iprcg6pb5ch86r9agmqwd8v6kp7999-guile-3.0.5/lib/libguile-3.0.so.1.3.0-gdb.scm:326:9: warning: possibly unbound variable `find-source-for-addr'
;;; /gnu/store/m5iprcg6pb5ch86r9agmqwd8v6kp7999-guile-3.0.5/lib/libguile-3.0.so.1.3.0-gdb.scm:326:31: warning: possibly unbound variable `program-debug-info-addr'
;;; /gnu/store/m5iprcg6pb5ch86r9agmqwd8v6kp7999-guile-3.0.5/lib/libguile-3.0.so.1.3.0-gdb.scm:327:31: warning: possibly unbound variable `program-debug-info-context'
;;; compiled /home/lfam/.cache/guile/ccache/3.0-LE-8-4.2/gnu/store/m5iprcg6pb5ch86r9agmqwd8v6kp7999-guile-3.0.5/lib/libguile-3.0.so.1.3.0-gdb.scm.go
;;; compiling /gnu/store/m5iprcg6pb5ch86r9agmqwd8v6kp7999-guile-3.0.5/share/guile/3.0/system/base/types.scm
;;; compiled /home/lfam/.cache/guile/ccache/3.0-LE-8-4.2/gnu/store/m5iprcg6pb5ch86r9agmqwd8v6kp7999-guile-3.0.5/share/guile/3.0/system/base/types.scm.go
------
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEsFFZSPHn08G5gDigJkb6MLrKfwgFAmB0hCEACgkQJkb6MLrK
fwi+ChAA6o/hwKUGJML6FVUtPlzXVSvwxyubC3pA9IaLqAYqz+uZvU/y3qsFADcg
hNLsGN4eVo7yX6JkTnR72IEVq33NEr6svImuqta7+/tIkCnyRejZvN82w4kOdVZI
n8yr2sFP4r7ikKepAJPbELSv5u9itiHscmeufOG/yOjaKN39vHJ8DHqnTjYbt1wR
Ns0fD2op24OXfYqKiGI9wreI4RVim/Bj2fyOFAaooFz66uwnCauEFiyf0r2ncKBC
uH0Y5wCTla/a4MXKgJevDQM4tZJ3Dcy2kf/ydVk3RX922DOYQ6izIelNurjoEaBC
3AM06Pm2OmoNq6BvgWwsYJVYd44hGi5Ff/UeqFzf5m2Cs/HxY9SJQa1m/jC87jVO
x9Q98/YSz3ADINhCFAL1icA9zWISbzuOoGbw4Adu0mR3h85r0OjBiubyrAtIXz0O
dPfE/lcY4R0ZEGwhe4V9tXL5IUK1vsLYJBCffRyg1GTnGYnumY+3UxfA3zyjJ97c
ohu7ieS/4g6Eh3BqjO20BKPZRYmiKfwM6Jg79jZf2aitdD+ltAWtzBUMpPXeqwP2
9Z4di89Uam+v6JI4pQU5xCvVvkdgTld9rxeGwSl9fxvwlc2NMHg2yS+e028vi5hu
FBs0RCicUSnHRUmBPtm/GPlYle8uz4kgwN8oBCrJYGYFfvpsMAA=
=eWjS
-----END PGP SIGNATURE-----


L
L
Leo Famulari wrote on 12 Apr 2021 20:26
(name . Ludovic Courtès)(address . ludo@gnu.org)
YHSQ567O1M+NIMSK@jasmine.lan
On Mon, Apr 12, 2021 at 01:02:09PM -0400, Leo Famulari wrote:
Toggle quote (7 lines)
> On Mon, Apr 12, 2021 at 02:25:43PM +0200, Ludovic Courtès wrote:
> > In the meantime, you could also update the ‘guix’ package by hand for
> > testing purposes.
>
> I tried this, but I can't figure out how to actually build the updated
> Guix package, since the source code isn't added to the store.

Alright, I pushed a branch 'wip-update-le-certs' to Savannah and built
the Guix package, and then a VM image sans nss-certs.

I confirm that updating the le-certs package fixes this bug.
L
L
Ludovic Courtès wrote on 13 Apr 2021 10:12
(name . Leo Famulari)(address . leo@famulari.name)
877dl6mwma.fsf@gnu.org
Hi,

Leo Famulari <leo@famulari.name> skribis:

Toggle quote (2 lines)
> I ran your command, and this is the output:

Could you type ‘bt’ (backtrace) at the GDB prompt?

Ludo’.
L
L
Ludovic Courtès wrote on 13 Apr 2021 11:29
Re: bug#46829: `guix pull` uses incorrect certificate store
(name . Leo Famulari)(address . leo@famulari.name)
87zgy2leg9.fsf_-_@gnu.org
Hi,

Leo Famulari <leo@famulari.name> skribis:

Toggle quote (7 lines)
> On Sun, Apr 11, 2021 at 09:29:00PM -0400, Leo Famulari wrote:
>> I checked and, although there have been some changes upstream at Let's
>> Encrypt [0], our le-certs still works for contacting Savannah with TLS.
>
> I checked wrong; le-certs needs to be updated. I'm testing the update
> now...

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.

Indeed, running ‘guix pull’ in the 1.2.0 live VM image works (it has
‘nss-certs’ installed in /etc/ssl/certs). Likewise, a Guix System 1.2.0
installation that includes ‘nss-certs’ (which is the default) is
unaffected.

For those who do not have ‘nss-certs’ installed, a workaround is to do
avoid HTTPS:


This is fine because the ‘guix’ channel is authenticated anyway.

We could also add a ‘--no-check-certificates’ option to ‘guix pull’.
For that, Guile-Git needs to implement
‘git_transport_certificate_check_cb’ & co. I started doing that but
it’s a bit of work (wrapping ‘struct git_cert’ is cumbersome) so I’m
willing to punt on it for now.

Thoughts?

Ludo’.
L
L
Leo Famulari wrote on 13 Apr 2021 19:44
(name . Ludovic Courtès)(address . ludo@gnu.org)
YHXYkTHmMk3FbxMu@jasmine.lan
On Tue, Apr 13, 2021 at 11:29:58AM +0200, Ludovic Courtès wrote:
Toggle quote (5 lines)
> 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.

Toggle quote (3 lines)
> 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.

Toggle quote (4 lines)
>
> This is fine because the ‘guix’ channel is authenticated anyway.

Yes, that works and is pretty safe. Although Guix will complain because
it can't tell that this is the same repo.

Toggle quote (2 lines)
> 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.

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.
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEsFFZSPHn08G5gDigJkb6MLrKfwgFAmB12I0ACgkQJkb6MLrK
fwgBkBAAimaqfE2V3M0HYK0V/guKj4FLgEEM+DQ0T+G5v2VbqkSG4fJW5xxHyY+g
oO79+nlNx5xrCKKOBo5Ka9Vyk/TXS4fIFXpqMPxOox8czRGXD/MdUVazXeyrfaor
P5BFISc5pT9TYE0iCa7JL/Ttas1Uhv2OdhAydfe9pcsgJFg7c4ou/qXO0CgVsZY6
DKLvKAPZjT5bIpdpzTWASq4yYxj5Bwzr5j4Hg8KGF6drG3juMZK+v0OG7mpLgFa3
lkRUCADKgbG4ig1vILOZpijQ8PN0foOtBY9MbOXjYUjwsHZyo2wTWsP95IkcXBMT
TjnlKbu8U/FtgmmD48g7U1FWaaQQ1h0YTIE2lJaW8fnafgo4q98TUTUrjhd1a4in
uXOp37gKeBwage7RiTyFx4/2G34EIvGq8vBY5uIJE8O/7UrzPg0TJ6jxq/BngwXE
da0z1Pyx6hefk7jVlZjcDNS9aHoKM/uv/T1dG+bNRrwZ0CCzGrNIf/jgxHWzLHBC
iZiowjmj2NYzneYM7PNre+vHsT1MG/iV4o7Nh+HFsAcuyzFfMnQU3rT1aXngc0PG
wSYRV//mdmPYAco1ZKapPUaaFNKj1IIE8jB48K0NdhdJOxY3fqzqOJbHOZKBhOWw
umQ4y6Yc7xx/cRxzjZqvMk6ABXCwHXE9qadpxX1yiFHxqLBv2J4=
=iN7B
-----END PGP SIGNATURE-----


L
L
Leo Famulari wrote on 13 Apr 2021 19:47
Re: bug#46829: Fresh install of 1.2.0 can't guix pull
(name . Ludovic Courtès)(address . ludo@gnu.org)
YHXZK5y5bT2Zamr1@jasmine.lan
On Mon, Apr 12, 2021 at 02:26:47PM -0400, Leo Famulari wrote:
Toggle quote (11 lines)
> On Mon, Apr 12, 2021 at 01:02:09PM -0400, Leo Famulari wrote:
> > On Mon, Apr 12, 2021 at 02:25:43PM +0200, Ludovic Courtès wrote:
> > > In the meantime, you could also update the ‘guix’ package by hand for
> > > testing purposes.
> >
> > I tried this, but I can't figure out how to actually build the updated
> > Guix package, since the source code isn't added to the store.
>
> Alright, I pushed a branch 'wip-update-le-certs' to Savannah and built
> the Guix package, and then a VM image sans nss-certs.

I've pushed the update patch as
15de49e60b255b98a53c6de4780e1ae95a8beada.

Now, we just need to update Guix package for it to take effect for
users, IIUC.
L
L
Leo Famulari wrote on 13 Apr 2021 20:09
(name . Ludovic Courtès)(address . ludo@gnu.org)
YHXeR63MF4sQ4NGe@jasmine.lan
On Tue, Apr 13, 2021 at 10:12:13AM +0200, Ludovic Courtès wrote:
Toggle quote (2 lines)
> Could you type ‘bt’ (backtrace) at the GDB prompt?

It goes like this:

------
Using host libthread_db library "/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libthread_db.so.1".
Core was generated by `/gnu/store/66xwl53f9ws7gin8iaqkhg111gimw1li-profile/bin/guile ./build-aux/updat'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000000000000000 in ?? ()
[Current thread is 1 (Thread 0x7eff7d8cdb80 (LWP 70404))]
(gdb) bt
#0 0x0000000000000000 in ?? ()
#1 0x00007eff61d9d4c4 in git_buf_try_grow () from /gnu/store/2rwa9h8w3ha0hj3zkbnrq1p2z199s2hn-libgit2-1.1.0/lib/libgit2.so
#2 0x00007eff61d9d7a5 in git_buf_set () from /gnu/store/2rwa9h8w3ha0hj3zkbnrq1p2z199s2hn-libgit2-1.1.0/lib/libgit2.so
#3 0x00007eff61deffe7 in git_path_prettify () from /gnu/store/2rwa9h8w3ha0hj3zkbnrq1p2z199s2hn-libgit2-1.1.0/lib/libgit2.so
#4 0x00007eff61e043ad in find_repo () from /gnu/store/2rwa9h8w3ha0hj3zkbnrq1p2z199s2hn-libgit2-1.1.0/lib/libgit2.so
#5 0x00007eff61e0528b in git_repository_discover () from /gnu/store/2rwa9h8w3ha0hj3zkbnrq1p2z199s2hn-libgit2-1.1.0/lib/libgit2.so
#6 0x00007eff7de6166d in ffi_call_unix64 () from /gnu/store/bw15z9kh9c65ycc2vbhl2izwfwfva7p1-libffi-3.3/lib/libffi.so.7
#7 0x00007eff7de5fac0 in ffi_call_int () from /gnu/store/bw15z9kh9c65ycc2vbhl2izwfwfva7p1-libffi-3.3/lib/libffi.so.7
#8 0x00007eff7df4efbe in scm_i_foreign_call () from /gnu/store/m5iprcg6pb5ch86r9agmqwd8v6kp7999-guile-3.0.5/lib/libguile-3.0.so.1
#9 0x00007eff7dfbd904 in foreign_call () from /gnu/store/m5iprcg6pb5ch86r9agmqwd8v6kp7999-guile-3.0.5/lib/libguile-3.0.so.1
#10 0x00007eff7dfc4118 in vm_regular_engine () from /gnu/store/m5iprcg6pb5ch86r9agmqwd8v6kp7999-guile-3.0.5/lib/libguile-3.0.so.1
#11 0x00007eff7dfc55b5 in scm_call_n () from /gnu/store/m5iprcg6pb5ch86r9agmqwd8v6kp7999-guile-3.0.5/lib/libguile-3.0.so.1
#12 0x00007eff7df42d27 in scm_primitive_eval () from /gnu/store/m5iprcg6pb5ch86r9agmqwd8v6kp7999-guile-3.0.5/lib/libguile-3.0.so.1
#13 0x00007eff7df42d83 in scm_eval () from /gnu/store/m5iprcg6pb5ch86r9agmqwd8v6kp7999-guile-3.0.5/lib/libguile-3.0.so.1
#14 0x00007eff7df9b830 in scm_shell () from /gnu/store/m5iprcg6pb5ch86r9agmqwd8v6kp7999-guile-3.0.5/lib/libguile-3.0.so.1
#15 0x00007eff7df5a73d in invoke_main_func () from /gnu/store/m5iprcg6pb5ch86r9agmqwd8v6kp7999-guile-3.0.5/lib/libguile-3.0.so.1
#16 0x00007eff7df3cb0a in c_body () from /gnu/store/m5iprcg6pb5ch86r9agmqwd8v6kp7999-guile-3.0.5/lib/libguile-3.0.so.1
#17 0x00007eff7dfc4149 in vm_regular_engine () from /gnu/store/m5iprcg6pb5ch86r9agmqwd8v6kp7999-guile-3.0.5/lib/libguile-3.0.so.1
#18 0x00007eff7dfc55b5 in scm_call_n () from /gnu/store/m5iprcg6pb5ch86r9agmqwd8v6kp7999-guile-3.0.5/lib/libguile-3.0.so.1
#19 0x00007eff7df41bba in scm_call_2 () from /gnu/store/m5iprcg6pb5ch86r9agmqwd8v6kp7999-guile-3.0.5/lib/libguile-3.0.so.1
#20 0x00007eff7df433ba in scm_c_with_exception_handler () from /gnu/store/m5iprcg6pb5ch86r9agmqwd8v6kp7999-guile-3.0.5/lib/libguile-3.0.so.1
#21 0x00007eff7dfbac3d in scm_c_catch () from /gnu/store/m5iprcg6pb5ch86r9agmqwd8v6kp7999-guile-3.0.5/lib/libguile-3.0.so.1
#22 0x00007eff7df3d0b3 in scm_i_with_continuation_barrier () from /gnu/store/m5iprcg6pb5ch86r9agmqwd8v6kp7999-guile-3.0.5/lib/libguile-3.0.so.1
#23 0x00007eff7df3d145 in scm_c_with_continuation_barrier () from /gnu/store/m5iprcg6pb5ch86r9agmqwd8v6kp7999-guile-3.0.5/lib/libguile-3.0.so.1
#24 0x00007eff7dfb96df in with_guile () from /gnu/store/m5iprcg6pb5ch86r9agmqwd8v6kp7999-guile-3.0.5/lib/libguile-3.0.so.1
#25 0x00007eff7de97c78 in GC_call_with_stack_base () from /gnu/store/zg126cjicrpm2p6zc08ra5vh4ddag7ww-libgc-8.0.4/lib/libgc.so.1
#26 0x00007eff7dfb99f8 in scm_with_guile () from /gnu/store/m5iprcg6pb5ch86r9agmqwd8v6kp7999-guile-3.0.5/lib/libguile-3.0.so.1
#27 0x00007eff7df5a8b2 in scm_boot_guile () from /gnu/store/m5iprcg6pb5ch86r9agmqwd8v6kp7999-guile-3.0.5/lib/libguile-3.0.so.1
#28 0x0000000000401100 in main ()
------

By the way, I can no longer reproduce the crash, now that I am using
`make update-guix-package` with a commit that has been pushed to
Savannah.
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEsFFZSPHn08G5gDigJkb6MLrKfwgFAmB13kcACgkQJkb6MLrK
fwhvqQ//fedCnrvE2aiDEvW504qW2mnCwjZhKLxo/aJJIR2Rq/CbAVT+E4aiB/ej
A51A+kcrakhkxvLHKHWp6n2COA6GfbHJ0dnYFw20kJpl59wfH4Ed8jiSU4bw12pm
OPxopqOS08wij63hYWXmFq3ok2CZ28N8t7qlY40CtgR5uL2ZmXFHmvPiGjO8YDE5
fuGbP2pSSeTRkyQZ1+FoHaC6m3REDZDzYjINa0sN3kHQRvUEbN933PZmyqtmptKT
c9rmcMngRqNTU9/d/KVE6u97YHMYeGW5X06/LZN0f8FXOni54jIwCz5lRBD8z0AD
ZO+z34yvyWhFqeXtRogFTudZX/YROinYjpO8pZrA8goiF+5fqDIuTZ+4N/yt6aaI
My9XIPs8kJE6aEEz+wvnF8Z0B62sizKcYlI+7IPf1Rtbv46rQcRQFcDpLvzwvYfO
WCiJ/IyRkO+fabkXZ2wbr8VTl7Tk3D/UIdRYUeGLr608ceJDTJWoNJmPZRhgtO/x
Xf9qR68Wl37lfa40o1m7UYDJ3yZ5SFNlzD0M3r5x7S1lM39Eo8VnrWBVqL9lHqD4
PEcLJzzqxkb19TnKjlh0QfjmtfPSvjel3UMqKJTVEastd2L319A+4EJI9JB/QnIe
92pu6CbT3YvvwKXQQ0t3lHFBri0hwlk2Gffp+/Kav5s+qjVopus=
=PqCw
-----END PGP SIGNATURE-----


L
L
Leo Famulari wrote on 13 Apr 2021 20:26
(no subject)
(name . GNU bug tracker automated control server)(address . control@debbugs.gnu.org)
YHXiYmmOzjF6UPCy@jasmine.lan
retitle 46829 Let's Encrypt certificate store (le-certs) expired
L
L
Leo Famulari wrote on 14 Apr 2021 03:08
Re: bug#46829: Fresh install of 1.2.0 can't guix pull
(name . Christopher Baines)(address . mail@cbaines.net)(address . 46829-done@debbugs.gnu.org)
YHZAhP90p6o49811@jasmine.lan
On Sun, Feb 28, 2021 at 10:27:02AM +0000, Christopher Baines wrote:
Toggle quote (9 lines)
> root@horna ~# guix pull
> substitute: updating substitutes from 'https://guix.cbaines.net'... 100.0%
> 0.0 MB will be downloaded
> downloading from https://guix.cbaines.net/nar/lzip/zg72c146skpca45ijvjigqhqgx0mwiny-le-certs-0 ...
> le-certs-0 4KiB 1.8MiB/s 00:00 [##################] 100.0%
>
> Updating channel 'guix' from Git repository at 'https://git.savannah.gnu.org/git/guix.git'...
> guix pull: error: Git error: the SSL certificate is invalid

This should be fixed with commit
a758a8a3c20052c5f1228e1ec80068652bbc3849, which updates the Guix package
to include commit 15de49e60b255b98a53c6de4780e1ae95a8beada.

There's nothing we can do for the 1.2.0 release artifacts at this point.
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEsFFZSPHn08G5gDigJkb6MLrKfwgFAmB2QHkACgkQJkb6MLrK
fwj6vRAA7Q7c3047G5EmNxkem4ISVcAQkELX7MSuVocs7rrWJB5uxS1tY94ko9Ez
TKDwX/iMQ2AxQOtlkXpGoRq0cNOtEUk8AjZDxaQpWxExAvtJL3scSINDhYvgdWW+
y5ae06vT73GAnitN+eePJZD6Kkx2URCtrmjEMgysi8+kufE24ehaIm+EzYAYX3rU
5qCqAYBG2ehG/VbdyMSg2s5eqbXCmWBeAiRffXR1R2meC8hDXVxml5Ov1JKch2OM
ccgkMV74l4gPbcHj+p3II40IFhfbt+7IIptLrQq+x6B/aFGOw8dmiZ94tsiT9xHy
YKjfa4GofRRod6BpDtWHotAtNL1JGXqJXb4mBCnlC0QuGKW6Ls9j30iS4dz6/JMJ
ZD5X/wwJLrfJm+H+S6hx13v/OJuP/q7hjCuEy38VhTRzLUwEkkUmj+rrhPAEYjLC
EGCwmuVF3WqukXybYn1vBIH8eFd3pbmMM3L5ZPwWrsByAmLE7DOyjhSOkOt4xGkV
jumAMvCwPLAxswKI/CVYFmz9nffouNNZMbpvkzmsKkozKsuJTWlZwi1kMD5kjBBj
gboyfag91e/E8VkW+2dD1qJnLiYP0krsb1DM3klLwZYGXvsS5X0CPSQVE9gu5e+7
5Mze7BMe3VNQN8JIcC5yW0cLDruK/oiJzY7VCb//CU8wi0kRDt8=
=g5uh
-----END PGP SIGNATURE-----


Closed
L
L
Ludovic Courtès wrote on 14 Apr 2021 12:50
Re: bug#46829: `guix pull` uses incorrect certificate store
(name . Leo Famulari)(address . leo@famulari.name)
87im4pf8cg.fsf@gnu.org
Hi,

Leo Famulari <leo@famulari.name> skribis:

Toggle quote (16 lines)
> 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’?

Toggle quote (7 lines)
>> 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.

Toggle quote (5 lines)
>> 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.

Toggle quote (4 lines)
> 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’.
F
F
François wrote on 14 Apr 2021 11:44
Re: bug#46829: Fresh install of 1.2.0 can't guix pull
20210414094410.kbdzlzjrgn3d3rr5@noop.avalenn.eu
Hello,

On Tue, Apr 13, 2021 at 09:08:20PM -0400, Leo Famulari wrote:
Toggle quote (2 lines)
> There's nothing we can do for the 1.2.0 release artifacts at this point.

Is there any place were we could document the problem and the suggested
workaround by Ludo (--url=http://)? Perhaps on the "Installation"
chapter of the manual, near the line documenting "guix pull"?

Cheers,
Fran�ois
M
M
Maxime Devos wrote on 14 Apr 2021 21:57
Re: bug#46829: `guix pull` uses incorrect certificate store
(address . 46829@debbugs.gnu.org)
bd2e02c02a294adce2c197060539d6c84af9538c.camel@telenet.be
On Wed, 2021-04-14 at 12:50 +0200, Ludovic Courtès wrote:
Toggle quote (10 lines)
> [...]
> > > 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.

Maybe call the option '--tolerate-eavesdropping' then? That name:

* is technically correct
* doesn't suggest the option is "Insecure"
* but still sounds like something you don't want
* should be clear to people not knowing about TLS' PKI infrastructure,
‘will eventually’™ be replaced with GNS + <insert GNUnet protocol here> or
something like that, which wouldn't use such a centralised structure.

Thoughts?
Maxime.
-----BEGIN PGP SIGNATURE-----

iI0EABYKADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYHdJDxccbWF4aW1lZGV2
b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7luoAP9A6PJ8JYMiez4NCY+sSs+fPFNV
gG30EsOrb46PRSQuYwD/a26PFL5fKPA6GdeYk6bbcq5yUxc/rPAnb7/U3KyGXgE=
=1YSV
-----END PGP SIGNATURE-----


L
L
Ludovic Courtès wrote on 21 Apr 2021 15:14
Re: bug#46829: Fresh install of 1.2.0 can't guix pull
(name . Leo Famulari)(address . leo@famulari.name)
87sg3j6aqh.fsf@gnu.org
Leo Famulari <leo@famulari.name> skribis:

Toggle quote (22 lines)
> On Tue, Apr 13, 2021 at 10:12:13AM +0200, Ludovic Courtès wrote:
>> Could you type ‘bt’ (backtrace) at the GDB prompt?
>
> It goes like this:
>
> ------
> Using host libthread_db library "/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libthread_db.so.1".
> Core was generated by `/gnu/store/66xwl53f9ws7gin8iaqkhg111gimw1li-profile/bin/guile ./build-aux/updat'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0 0x0000000000000000 in ?? ()
> [Current thread is 1 (Thread 0x7eff7d8cdb80 (LWP 70404))]
> (gdb) bt
> #0 0x0000000000000000 in ?? ()
> #1 0x00007eff61d9d4c4 in git_buf_try_grow () from /gnu/store/2rwa9h8w3ha0hj3zkbnrq1p2z199s2hn-libgit2-1.1.0/lib/libgit2.so
> #2 0x00007eff61d9d7a5 in git_buf_set () from /gnu/store/2rwa9h8w3ha0hj3zkbnrq1p2z199s2hn-libgit2-1.1.0/lib/libgit2.so
> #3 0x00007eff61deffe7 in git_path_prettify () from /gnu/store/2rwa9h8w3ha0hj3zkbnrq1p2z199s2hn-libgit2-1.1.0/lib/libgit2.so
> #4 0x00007eff61e043ad in find_repo () from /gnu/store/2rwa9h8w3ha0hj3zkbnrq1p2z199s2hn-libgit2-1.1.0/lib/libgit2.so
> #5 0x00007eff61e0528b in git_repository_discover () from /gnu/store/2rwa9h8w3ha0hj3zkbnrq1p2z199s2hn-libgit2-1.1.0/lib/libgit2.so
> #6 0x00007eff7de6166d in ffi_call_unix64 () from /gnu/store/bw15z9kh9c65ycc2vbhl2izwfwfva7p1-libffi-3.3/lib/libffi.so.7
> #7 0x00007eff7de5fac0 in ffi_call_int () from /gnu/store/bw15z9kh9c65ycc2vbhl2izwfwfva7p1-libffi-3.3/lib/libffi.so.7
> #8 0x00007eff7df4efbe in scm_i_foreign_call () from /gnu/store/m5iprcg6pb5ch86r9agmqwd8v6kp7999-guile-3.0.5/lib/libguile-3.0.so.1

BTW, this must be fixed by 5b35c9adc899749a0bd96a0e6d2c3bbf88e38963.

Ludo'.
L
L
Leo Famulari wrote on 31 May 2021 21:17
(no subject)
(address . control@debbugs.gnu.org)
YLU2PnE64K52ntAn@jasmine.lan
unarchive 46829
L
L
Leo Famulari wrote on 31 May 2021 21:17
Re: bug#46829: `guix pull` uses incorrect certificate store
(name . Ludovic Courtès)(address . ludo@gnu.org)
YLU2YScq51IQuFVk@jasmine.lan
On Wed, Apr 14, 2021 at 12:50:39PM +0200, Ludovic Courtès wrote:
Toggle quote (8 lines)
> 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’?

Yeah, that's bad.

Let's go ahead with adding some kind of '--allow-insecure-transport'
option to `guix pull` for this use case. Bonus points for making it
sounds as scary as possible :)
?
Your comment

This issue is archived.

To comment on this conversation send an email to 46829@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 46829
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch