[bug#54723] [PATCH] Check URI when verifying narinfo validity.

[bug#54723] [PATCH] Check URI when verifying narinfo validity.

[Guillaume Le Vaillant]

[-- Attachment #1.1: Type: text/plain, Size: 2981 bytes --]

When trying to upgrade a machine using a substitute server on the same
LAN, I get this crash a lot:

--8<---------------cut here---------------start------------->8---
# guix system reconfigure --substitute-urls="http://192.168.0.22:8080 https://ci.guix.gnu.org" /etc/guix/config.scm
substitute: mise à jour des substituts depuis « http://192.168.0.22:8080 »... 100.0 %
substitute: Backtrace:
substitute: In ice-9/boot-9.scm:
substitute:   1752:10 17 (with-exception-handler _ _ #:unwind? _ # _)
substitute: In unknown file:
substitute:           16 (apply-smob/0 #<thunk 7fe08afb72e0>)
substitute: In ice-9/boot-9.scm:
substitute:     724:2 15 (call-with-prompt _ _ #<procedure default-prompt-handle…>)
substitute: In ice-9/eval.scm:
substitute:     619:8 14 (_ #(#(#<directory (guile-user) 7fe08afbcc80>)))
substitute: In guix/ui.scm:
substitute:    2209:7 13 (run-guix . _)
substitute:   2172:10 12 (run-guix-command _ . _)
substitute: In ice-9/boot-9.scm:
substitute:   1752:10 11 (with-exception-handler _ _ #:unwind? _ # _)
substitute:   1752:10 10 (with-exception-handler _ _ #:unwind? _ # _)
substitute: In guix/scripts/substitute.scm:
substitute:    757:18  9 (_)
substitute:    348:26  8 (process-query #<output: file 4> _ #:cache-urls _ #:acl _)
substitute: In guix/substitutes.scm:
substitute:    369:45  7 (lookup-narinfos/diverse _ _ #<procedure 7fe088c9cbc0 …> …)
substitute: In unknown file:
substitute:            6 (filter #<procedure 7fe088c9cbc0 at guix/scripts/subst…> …)
substitute: In guix/narinfo.scm:
substitute:    215:32  5 (valid-narinfo? _ _ #:verbose? _)
substitute: In ice-9/boot-9.scm:
substitute:   1685:16  4 (raise-exception _ #:continuable? _)
substitute:   1685:16  3 (raise-exception _ #:continuable? _)
substitute:   1780:13  2 (_ #<&compound-exception components: (#<&assertion-fail…>)
substitute:   1685:16  1 (raise-exception _ #:continuable? _)
substitute:   1685:16  0 (raise-exception _ #:continuable? _)
substitute: 
substitute: ice-9/boot-9.scm:1685:16: In procedure raise-exception:
substitute: In procedure car: Wrong type argument in position 1 (expecting pair): ()
guix system: erreur : `/gnu/store/wgygsxcdy1z3pfvwhpgyl5vjp4xvwhhh-guix-1.3.0-23.a27e47f/bin/guix substitute' died unexpectedly
--8<---------------cut here---------------end--------------->8---

It looks like the 'narinfo-uri' field is an empty list instead of a list
of URIs. Is that supposed to be possible?
Does the the attached patch adding a check for the validity of
this field in the 'valid-narinfo?' function make sense?


The substitute server configuration is:

--8<---------------cut here---------------start------------->8---
(service guix-publish-service-type
         (guix-publish-configuration
          (host "0.0.0.0")
          (port 8080)
          (compression '(("zstd" 3)))
          (advertise? #t)))
--8<---------------cut here---------------end--------------->8---

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: 0001-narinfo-Check-URI-when-verifying-narinfo-validity.patch --]
[-- Type: text/x-patch, Size: 1295 bytes --]

From 8d9a45b2f38809fb3acfacf6f83532b7b556e78c Mon Sep 17 00:00:00 2001
From: Guillaume Le Vaillant <glv@posteo.net>
Date: Tue, 5 Apr 2022 11:50:48 +0200
Subject: [PATCH] narinfo: Check URI when verifying narinfo validity.

* guix/narinfo.scm (valid-narinfo?): Check if the 'uri' field is valid.
---
 guix/narinfo.scm | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/guix/narinfo.scm b/guix/narinfo.scm
index 4fc550aa6c..466ce20deb 100644
--- a/guix/narinfo.scm
+++ b/guix/narinfo.scm
@@ -209,11 +209,13 @@ (define %mandatory-fields
 
 (define* (valid-narinfo? narinfo #:optional (acl (current-acl))
                          #:key verbose?)
-  "Return #t if NARINFO's signature is not valid."
+  "Return #t if NARINFO's signature is valid."
   (let ((hash      (narinfo-sha256 narinfo))
         (signature (narinfo-signature narinfo))
-        (uri       (uri->string (first (narinfo-uris narinfo)))))
-    (and hash signature
+        (uri       (if (null? (narinfo-uris narinfo))
+                       #f
+                       (uri->string (first (narinfo-uris narinfo))))))
+    (and hash signature uri
          (signature-case (signature hash acl)
            (valid-signature #t)
            (invalid-signature
-- 
2.35.1


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

[bug#54723] [PATCH] Check URI when verifying narinfo validity.

[Ludovic Courtès]

Hi,

Guillaume Le Vaillant <glv@posteo.net> skribis:

> When trying to upgrade a machine using a substitute server on the same
> LAN, I get this crash a lot:
>
> # guix system reconfigure --substitute-urls="http://192.168.0.22:8080 https://ci.guix.gnu.org" /etc/guix/config.scm
> substitute: mise à jour des substituts depuis « http://192.168.0.22:8080 »... 100.0 %

[...]

> It looks like the 'narinfo-uri' field is an empty list instead of a list
> of URIs. Is that supposed to be possible?

I don’t think so.  Could you grab a narinfo and share it?

  wget -qO - http://192.168.0.22:8080/HASH.narinfo

where HASH is the hash part of a store item.

What could happen though is a situation where ‘guix publish’ only offers
a compression method not supported by the client.  In that case,
‘narinfo-best-uri’ throws a match-error because ‘choices’ is the empty
list.  We should fix that.

> Does the the attached patch adding a check for the validity of
> this field in the 'valid-narinfo?' function make sense?

Maybe, but I’d like to make sure we understand the issue.

Thanks,
Ludo’.

[bug#54723] [PATCH] Check URI when verifying narinfo validity.

[Guillaume Le Vaillant]

[-- Attachment #1: Type: text/plain, Size: 1896 bytes --]

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

> Hi,
>
> [...]
>
> Could you grab a narinfo and share it?
>
>   wget -qO - http://192.168.0.22:8080/HASH.narinfo
>
> where HASH is the hash part of a store item.
>
> What could happen though is a situation where ‘guix publish’ only offers
> a compression method not supported by the client.  In that case,
> ‘narinfo-best-uri’ throws a match-error because ‘choices’ is the empty
> list.  We should fix that.

I tried downloading a few narinfos and they don't look broken (2 of them
in attachment).

However for one of them it looks like the guix-publish server got stuck
on the request for several minutes (the second attempt worked):

--8<---------------cut here---------------start------------->8---
wget http://192.168.0.22:8080/184b50qkcrkchc6dpwwcd7ypqb5yvrm3.narinfo
--2022-04-05 19:33:56--  http://192.168.0.22:8080/184b50qkcrkchc6dpwwcd7ypqb5yvrm3.narinfo
Connexion à 192.168.0.22:8080… connecté.
requête HTTP transmise, en attente de la réponse… Erreur de lecture (Connexion ré-initialisée par le correspondant) dans les en-têtes.
Nouvel essai.

--2022-04-05 19:36:40--  (essai :  2)  http://192.168.0.22:8080/184b50qkcrkchc6dpwwcd7ypqb5yvrm3.narinfo
Connexion à 192.168.0.22:8080… connecté.
requête HTTP transmise, en attente de la réponse… 200 OK
Taille : 7428 (7,3K) [application/x-nix-narinfo]
Sauvegarde en : « 184b50qkcrkchc6dpwwcd7ypqb5yvrm3.narinfo »

184b50qkcrkchc6dpwwcd7ypqb5yvrm3.narinfo        100%[=====================================================================================================>]   7,25K  --.-KB/s    ds 0,02s   

2022-04-05 19:36:40 (391 KB/s) — « 184b50qkcrkchc6dpwwcd7ypqb5yvrm3.narinfo » sauvegardé [7428/7428]
--8<---------------cut here---------------end--------------->8---

Could that be the cause of the issue?

[-- Attachment #2: ly615k3xjapk0wq7y2n4ld6msi7307ba.narinfo --]
[-- Type: application/octet-stream, Size: 3602 bytes --]

StorePath: /gnu/store/ly615k3xjapk0wq7y2n4ld6msi7307ba-openscad-2021.01
NarHash: sha256:05ggj6c9dwh6n1mlrxq0sxdhk6cd175lmxgjhxy8f3v84cjcjqn7
NarSize: 13717792
References: 094bbaq6glba86h1d4cj16xhdi6fk2jl-gcc-10.3.0-lib 2gzjr3z5v4dls3waj2grmxc1gnr9b8pz-qscintilla-2.11.6 3x3dl71d4xm6y4hjwq110hmfyfx0xc6j-zstd-1.5.0-lib 4arnpk54k1hdp2j7zp8bchnp3gpvd80s-pulseaudio-15.0 4gcznd9r1r3hlmkb2m7s1a37radgnspn-libtasn1-4.17.0 55lyhpbqhaxhr40k4qj9z5pd2w4w209d-mesa-21.3.2 5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33 6npmblxxp4fxbng3xj3bdx65av9lc2ap-libxext-1.3.4 7b5qsjh2cbhwnqbdicvl81496k7b0g0j-libbsd-0.10.0 7vxkr7h1bf5ffhds0c036v386jjik0la-fontconfig-minimal-2.13.94 8pzphk5r4w0hxbyrlhpwvym3lq235sbk-eigen-3.3.8 8qv5kb2fgm4c3bf70zcg9l6hkf3qzpw9-zlib-1.2.11 91w1f06v63a0ihv1vbs08pqh304i5a9g-libxxf86vm-1.1.4 95mjqhlz4s1frrbc69hd8cvqdja9yjy7-dbus-1.12.20 9k6slxs8ynz46h85bcy3zk2mx0nn8rpf-libxau-1.0.9 a1vnwxgl18qn30yfl20lm0hrx1n78jvy-glib-2.70.2 a64idcxbd5sndxz61wra9hxwyprsnj10-libsndfile-1.0.30 aggsb6j1svxp70xlll4rqnx5f2pzz794-xz-5.2.5 ak70pk2hjks17cx7zjdmdmzpcpiy9gpi-freetype-2.10.4 b2fszyg2f2lmizawrq5zr1ag3cxdin5i-opus-1.3.1 dfzp4rhkzqqagx3djn2kcnaflz1m8446-libxdmcp-1.1.3 di5bqb45hi5lvp2q08hlxqjdcl9phjb1-pcre-8.45 f5l9m0dspdjxspdrnvfs4p0rncdhyigf-boost-1.77.0 fg76cjzdk413dfkx50fkcwd3wpbyfpi1-pcre2-10.37 fjq8aca46v502mrgvrfhvif0xb6m4fz0-libidn2-2.3.1 fl900q94dnjjfs2j24x8mdy6b2hgjzz3-cgal-5.2.2 fwbiihd2sbhai63y1pvvdh0f2bakfzrf-gmp-6.2.1 g3y6ifhm0751vgsxv90yipfw6mk189kj-libxml2-2.9.12 gw6d09acwld4pd9plmgnlhblzr7734cd-libxfixes-6.0.0 hbymc5z6rpj0m1a00iglc779kdnbglf0-libxshmfence-1.3 hi05v31jhlavn6cjkkz2k4713l8p2w1c-glew-2.1.0 hkhbq2q1gfs970gsp2nhsmcqb4vmv2xr-libunistring-0.9.10 hkz69y75pnhncvf0vm4c9417ybfsm039-qtmultimedia-5.15.2 hnk3q8ydll3jwd2b1r68yzlb673dkb4f-double-conversion-3.1.5 hscy2cjmbna801q1wpgsqyyfba9p8nv2-opencsg-1.4.2 hzic3ddl5yvnyw7gm4a0qc5icgqy2442-icu4c-69.1 ikghb2zrjjl5944gxqkls89rrbd1qn24-libdrm-2.4.107 in9a705nl7k6hql7hn2f4hic2dhxk8mq-libx11-1.7.3.1 izd9mlyszicbdb5j01k961k97bggm2s0-glu-9.0.1 jmpsh28j3fxf0df99p5dcn29dwldzw79-libzip-1.8.0 jn7vb79idxp7fk8h0hnn5mh1hwh0hlfl-qtbase-5.15.2 l69djprsj2vk7cdh8ya1z96060sw5p70-libvorbis-1.3.7 ly615k3xjapk0wq7y2n4ld6msi7307ba-openscad-2021.01 manq4lcakkcakcg14rsi7467qw4c5frj-nettle-3.7.3 msb7kyg7f0bzbxp4f1s5kdiymb5gblwc-libxcb-1.14 p7iq81hxxyk9zy7a9dngbf16zm8d4klx-libpng-1.6.37 pbvvr2542ql7352pqmdj7m0a5w9bfs78-graphite2-1.3.13 pmq05n0q25v4qjyibxfrp53v4391k7vh-mpfr-4.1.0 s3hl12jxz9ybs7nsy7kq7ybzz7qnzmsg-bzip2-1.0.8 vpbhfx3in1armf40mxvq9qclvv8ajncq-expat-2.4.7 wgqhlc12qvlwiklam7hz2r311fdcqfim-libffi-3.3 wiv3snwalzwjg7g9gqd1fmh66iimhlsf-libogg-1.3.5 x1jd7pqfn9ilb6x97azcfq1fhjr63p0z-p11-kit-0.23.22 xgp23kc3v9w7l10grjwd0n1a74v3fhx3-openssl-1.1.1n xx3r1xhbpbal3xkbv9syy8zfb7by9vc3-flac-1.3.3 zl9wf0zwq2ka9rpmayp53hnp2mn460xf-gnutls-3.7.2 zvvcnpkr14dpxk2jkm6alvr9gvka5nbk-harfbuzz-2.8.2
Deriver: nr1c83n5zh8krw90mppnsmk086ismbi9-openscad-2021.01.drv
Signature: 1;kitej;KHNpZ25hdHVyZSAKIChkYXRhIAogIChmbGFncyByZmM2OTc5KQogIChoYXNoIHNoYTI1NiAjRTg3M0JEN0VGOEFFNzNCNDZFQUI0NzU5OTAxQkMzNTZGNTYxMTJCRUMwNEM4NzMxQzc0M0RGRENEQzZFNTFGQSMpCiAgKQogKHNpZy12YWwgCiAgKGVjZHNhIAogICAociAjMDNFNURBREUzODU1NUE4ODI0NDE0QTZGNzkyOUZDOTdFMDM1MzdFNEI3Rjg4MDIzMEJDMjUwOUVDOUFGQjY0RiMpCiAgIChzICMwNEQzNEMyNjY3NzcyRkNCQjM0ODREMDE1REEzMkI4NzAyODdEMDU5QzMwNUVCMzY5NDhEOEEyNzhGQ0VFNEIzIykKICAgKQogICkKIChwdWJsaWMta2V5IAogIChlY2MgCiAgIChjdXJ2ZSBFZDI1NTE5KQogICAocSAjOTg4MTIzREM0MkYwMzQxMzhDMzA5MDNCODBBNzhBNkRDOEI5NzVBMjBEODkxRDhEQzNERDNDQzQzMDhEMEQwOCMpCiAgICkKICApCiApCg==
URL: nar/zstd/ly615k3xjapk0wq7y2n4ld6msi7307ba-openscad-2021.01
Compression: zstd

[-- Attachment #3: 184b50qkcrkchc6dpwwcd7ypqb5yvrm3.narinfo --]
[-- Type: application/octet-stream, Size: 7428 bytes --]

StorePath: /gnu/store/184b50qkcrkchc6dpwwcd7ypqb5yvrm3-qgis-3.16.3
NarHash: sha256:09cc5yzh4klf80x0gz8gc4ji5dl68faw5xnkfyz6azyf903yywqm
NarSize: 374542640
References: 094bbaq6glba86h1d4cj16xhdi6fk2jl-gcc-10.3.0-lib 10x8ljfmq4zkif1wniz0rbp2khqxi17j-qca-2.3.3 184b50qkcrkchc6dpwwcd7ypqb5yvrm3-qgis-3.16.3 1dh3ra00qakpp27jpl88m36rl1ij495z-python-pluggy-0.13.1 1hssss1mrxmsyrd4w9zv8gbpb7zncdq8-python-iniconfig-1.1.1 1na8fay44dnpbnkdzd3mv39014f6d9yq-minizip-1.2.11 1q438bh1817is0xpahacfski6k776b46-libspatialindex-1.9.3 2gzjr3z5v4dls3waj2grmxc1gnr9b8pz-qscintilla-2.11.6 2hfsmfzxj33izz2w4xcp7fkxp2c4irk4-netcdf-4.7.4 3kl94m3ksm45a880b6lnn3kagk857lj9-libgcrypt-1.8.8 3x3dl71d4xm6y4hjwq110hmfyfx0xc6j-zstd-1.5.0-lib 45ccg7khqkz7w9wm9w7xvwvsgjsr4rg5-json-c-0.15 4d0ssibbd2glk1vc93zj738awmy22xad-giflib-5.2.1 4gcznd9r1r3hlmkb2m7s1a37radgnspn-libtasn1-4.17.0 4gq7gyhpygzh0cqsz8ryf9yd1phw3nb1-python-urllib3-1.26.7 4y5m9lb8k3qkb1y9m02sw9w9a6hacd16-bash-minimal-5.1.8 55lyhpbqhaxhr40k4qj9z5pd2w4w209d-mesa-21.3.2 5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33 5ilf1cq3fn6mx3k20pv5pak2vnd3ybxd-python-asn1crypto-1.4.0 6c5mikm9bf59xnhkppzwf0sn0h49gp4a-python-chardet-3.0.4 6cq4h7cif6w674azxdsy40xl3xdla40m-qtlocation-5.15.2 6npmblxxp4fxbng3xj3bdx65av9lc2ap-libxext-1.3.4 6vmv2i9iqdy5j1ag5vpy2ggnw3w5acma-libsecret-0.20.4 74kivpqcjsn7r6n53zarspwdxgkgbl14-python-attrs-bootstrap-21.2.0 7b5qsjh2cbhwnqbdicvl81496k7b0g0j-libbsd-0.10.0 7nlzk7n90ib3llblxlpz725ym3k05gdj-util-linux-2.37.2-lib 83vic77rvwhi8jxvm35xfka9gv8axlmc-exiv2-0.27.5 84si0j45zxgbkmvya51yhrfj5iz0v2wx-python-six-bootstrap-1.16.0 8jkf66qwr30r7rvz0pwl0zsyd71x6x12-eudev-3.2.11 8qv5kb2fgm4c3bf70zcg9l6hkf3qzpw9-zlib-1.2.11 91w1f06v63a0ihv1vbs08pqh304i5a9g-libxxf86vm-1.1.4 95mjqhlz4s1frrbc69hd8cvqdja9yjy7-dbus-1.12.20 9ckx7nl47ml6ha4xc0rdh0glrzj7m1ah-qtserialport-5.15.2 9h020rymphf0zm27823yh9m6fa72p3jq-libtiff-4.3.0 9k6slxs8ynz46h85bcy3zk2mx0nn8rpf-libxau-1.0.9 9pyydl5w9xnz1qm56sxn1zh4qny6fkxz-protobuf-3.17.3 9qikfahx9wschf8jj1kc02qp8mzbfmcm-python-markupsafe-2.0.1 a1vnwxgl18qn30yfl20lm0hrx1n78jvy-glib-2.70.2 a4j8ymgk1cvbpn747x3l3plrpm48b7jb-python-owslib-0.19.2 aggsb6j1svxp70xlll4rqnx5f2pzz794-xz-5.2.5 ak70pk2hjks17cx7zjdmdmzpcpiy9gpi-freetype-2.10.4 az5yw33ifrrdwps0fqmaa1hsvdlgvwid-python-wcwidth-0.1.8 azs9f4q7kpwizvk2qw7if7ag4ngab77i-python-psycopg2-2.9.3 c3l9xd7c09cchmk475swghfa6sfkkw88-python-numpy-1.20.3 c8isj4jq6knv0icfgr43di6q3nvdzkx7-xz-5.2.5 cl3nc3lbzgjifp5c4fz0g0h34bjaibf6-python-six-1.16.0 cmn4zl10y7bi6mrw3bm77mvc79sj85yf-proj-7.2.1 d39sww9kp42vf7wxqkb9ig2ydbq519bb-python-pysocks-1.7.1 dfzp4rhkzqqagx3djn2kcnaflz1m8446-libxdmcp-1.1.3 di5bqb45hi5lvp2q08hlxqjdcl9phjb1-pcre-8.45 dphsw50ymfagw8qz5rzq6f9iqbhggqzn-qtdeclarative-5.15.2 ds61ad6g9gflba6k2z80a25q7vlvxxn0-python-nose2-0.9.2 f9a6smln5z5240d9k1mk5jg8b6mnqiwl-python-pyparsing-3.0.6 ffynx7n76vb5rby4b14yjcacqwq1w70h-mit-krb5-1.19.2 fg76cjzdk413dfkx50fkcwd3wpbyfpi1-pcre2-10.37 fjq8aca46v502mrgvrfhvif0xb6m4fz0-libidn2-2.3.1 fkxl8fnk6cab2jr2ymafmdl8x7x9pdj9-python-pytz-2021.1 fwbiihd2sbhai63y1pvvdh0f2bakfzrf-gmp-6.2.1 g17ish20hsidydzf0kdj7ybw947d7rgp-hdf5-1.10.7 g2471qand03zybad8iq401pw31cv3q9h-python-mock-3.0.5 g3y6ifhm0751vgsxv90yipfw6mk189kj-libxml2-2.9.12 g5s1v2fgwbpq63566kq4jdsmz77l6kzs-python-pygments-2.8.1 gw6d09acwld4pd9plmgnlhblzr7734cd-libxfixes-6.0.0 gzsdnk92gmfg5979dcgfh644cfhsc1yv-python-pyqt+qscintilla-5.15.2 hbymc5z6rpj0m1a00iglc779kdnbglf0-libxshmfence-1.3 hkhbq2q1gfs970gsp2nhsmcqb4vmv2xr-libunistring-0.9.10 hnk3q8ydll3jwd2b1r68yzlb673dkb4f-double-conversion-3.1.5 hyglphska1gknm3q0jfdzk820plql55i-python-certifi-2020.12.5 hzic3ddl5yvnyw7gm4a0qc5icgqy2442-icu4c-69.1 i0mgdg0m0knimajkl3lhcma8hmdrqyh2-qtsvg-5.15.2 i11i4xrx3gibdm012bqqhgrjs69qyia3-curl-7.79.1 ig30y8ldap717qh9477d1w9wcdcr56c6-gdal-3.3.3 ikghb2zrjjl5944gxqkls89rrbd1qn24-libdrm-2.4.107 in9a705nl7k6hql7hn2f4hic2dhxk8mq-libx11-1.7.3.1 j0zbkyslsmv4vcan7k8h1q4nmbhr7s0f-python-charset-normalizer-2.0.5 j4qjjgb400z0pxjl3xpglrvdpzihsqby-python-packaging-21.3 jakrgjvxh0raw530kz8vbrf8xah88nf4-python-cryptography-3.3.1 jlx0r8vnrl7ywdls9g9cmjlgw1kznlmv-python-iso8601-0.1.13 jmpsh28j3fxf0df99p5dcn29dwldzw79-libzip-1.8.0 jn7vb79idxp7fk8h0hnn5mh1hwh0hlfl-qtbase-5.15.2 k00jylznnra08y05p7nynsxdsz2qccj0-libgeotiff-1.5.1 k49pbvmdlv7cjhfgsgkdjqv4rd94gx7x-python-py-1.10.0 k7q038pwmh5dvi50rmnnxajw9g2d461b-python-pyopenssl-20.0.1 kggass7kq7rrvw9qw5jbas9lvnvs9ag0-python-pyyaml-5.4.1 lla4s9qm9w6hrdrwv68j5j5qzz09zdhp-libwebp-1.2.0 lz8jdqkwx0dm65x577yg6m7dhwiqwmlv-libjpeg-turbo-2.0.5 m5p8iinvgbylsym6j1bg9vp27cr7yb0q-python-pycparser-2.20 manq4lcakkcakcg14rsi7467qw4c5frj-nettle-3.7.3 mbpydvww83h9gvkf28l8md55y3aiba78-hdf4-alt-4.2.14 mpcslygybwv1v6jvail06df27nbgwwp8-python-more-itertools-8.2.0 msb7kyg7f0bzbxp4f1s5kdiymb5gblwc-libxcb-1.14 my06ayhsvkyq7igwmp36d3k0grp0wsf1-grass-7.8.6 mzhw8pimagwcvwc0970nbzqb9ik64hi8-python-sip-5.5.0 n2klq1ivfcpf3k2jnw25yjm9qy6q07fc-python-dateutil-2.8.2 n34w2q567rkrzjni773biqfm93jkdvbs-python-cov-core-1.15.0 nl58q651x8dbhmxp62i345pz4zmpi4rl-python-toml-0.10.2 nv76qrxwqbfqjlf89dwh7z66pkz58xv1-python-pyqt5-sip-12.8.1 p09ad3pwazgjcfblzw94lmwq0jgd41zp-python-cffi-1.14.4 p7iq81hxxyk9zy7a9dngbf16zm8d4klx-libpng-1.6.37 papscspynmdi5ljmngw5x5wbi9ijc1xj-python-3.9.9 pbs0gsb14w85ix7c5s0d894ywxbrgj0k-gsl-2.7 pbvvr2542ql7352pqmdj7m0a5w9bfs78-graphite2-1.3.13 pibag64qlr8aw6cxlb48srsqg6wjvxbq-python-gdal-3.3.3 pilv2s68v4xamxwk1ahfy7q32j6wnf7l-libgpg-error-1.42 q49ibl1dy7ihwdyrq1ihc6pjxvm7z0dn-freexl-1.0.6 qa70xl88f3pz9xkv7hps0l2bxzxhbsxi-python-requests-2.26.0 qfmvs0na1bja9qldx7xlh3r75vzcr7qb-python-coverage-5.2.1 qz82gy0cwak6qkb56qmf3wxk3f2wjk73-nghttp2-1.44.0-lib qzs5k2a5f8lkgcns6fj92ca7906f5z2q-libspatialite-5.0.1 qzwlc11dxmfsx9aglsi4labnm79p8rdy-geos-3.8.1 qzynp5lwlxpgzg6m1kych8cg1zlkawdq-qtkeychain-0.13.2 r3sbn64qiprnamv4l2zl1vz9l2jlycbk-qwt-6.1.5 rq94z9yzd9x6p8vp3wybmja2kf9hk73h-postgresql-13.4 s3hl12jxz9ybs7nsy7kq7ybzz7qnzmsg-bzip2-1.0.8 vpbhfx3in1armf40mxvq9qclvv8ajncq-expat-2.4.7 vpkg8yj8bl63yahfs498s5r06ddw3z52-python-jinja2-3.0.1 vqhamsanmlm8v6f90a635zc6gmhwlphp-gfortran-10.3.0-lib vr16bf0b1bzmzvckva708fpng3qlcfwh-python-packaging-bootstrap-21.3 w4hxd7w2nlwj4yj2yg3yif4mip508b59-python-idna-2.10 wab6v879ry7k75z2sm2pffrmadjfw04c-python-future-0.18.2 wgqhlc12qvlwiklam7hz2r311fdcqfim-libffi-3.3 x10nkg5sw8k7v7h3pdsmx2p3i23lvxfq-libtirpc-1.3.1 x1jd7pqfn9ilb6x97azcfq1fhjr63p0z-p11-kit-0.23.22 xgp23kc3v9w7l10grjwd0n1a74v3fhx3-openssl-1.1.1n xmzx5mzv4863yw9kmr2ykndgp37p8if0-sqlite-3.36.0 xn8kpcwzw3zc75zfr9nir4jqaqph293l-python-pytest-cov-2.8.1 xn9qd8d8aad2xgvczyfp0x8sx7gvs4jm-librttopo-1.1.0 zl9wf0zwq2ka9rpmayp53hnp2mn460xf-gnutls-3.7.2 zvvcnpkr14dpxk2jkm6alvr9gvka5nbk-harfbuzz-2.8.2 zwc5q57bff6314pjgfa0c6rj8pxmyn1j-python-pytest-6.2.5
Deriver: 9i2pihhs538vbfpkzpqiamdcad2v5xdd-qgis-3.16.3.drv
Signature: 1;kitej;KHNpZ25hdHVyZSAKIChkYXRhIAogIChmbGFncyByZmM2OTc5KQogIChoYXNoIHNoYTI1NiAjQkU1MzdBQzlGNDUzQUY2NjA5NTcxMjM4Njk2NEZBRjEwRDEyQkY2QTc5Q0YzNTM4NUUxMjA5QTI5QjBFRkYyMyMpCiAgKQogKHNpZy12YWwgCiAgKGVjZHNhIAogICAociAjMDQ3NDdGQjMxOUYxNTA3NjNDNzZFREUyMjExRjg2OTZBQzY4NDU5MDgwN0NBRTk3NEZDNzUxMDg3QTM2QzBFOCMpCiAgIChzICNFNDlDQTMzNEVCRjE2NjJGQzZGNzU0Q0U2RjExNzA2QzM3NTMwMjEyRDlFQzEzOEVFN0M2M0ExOTdGNTVBNSMpCiAgICkKICApCiAocHVibGljLWtleSAKICAoZWNjIAogICAoY3VydmUgRWQyNTUxOSkKICAgKHEgIzk4ODEyM0RDNDJGMDM0MTM4QzMwOTAzQjgwQTc4QTZEQzhCOTc1QTIwRDg5MUQ4REMzREQzQ0M0MzA4RDBEMDgjKQogICApCiAgKQogKQo=
URL: nar/zstd/184b50qkcrkchc6dpwwcd7ypqb5yvrm3-qgis-3.16.3
Compression: zstd

[bug#54723] [PATCH] Check URI when verifying narinfo validity.

[Ludovic Courtès]

Hi,

Guillaume Le Vaillant <glv@posteo.net> skribis:

> However for one of them it looks like the guix-publish server got stuck
> on the request for several minutes (the second attempt worked):
>
> wget http://192.168.0.22:8080/184b50qkcrkchc6dpwwcd7ypqb5yvrm3.narinfo
> --2022-04-05 19:33:56--  http://192.168.0.22:8080/184b50qkcrkchc6dpwwcd7ypqb5yvrm3.narinfo
> Connexion à 192.168.0.22:8080… connecté.
> requête HTTP transmise, en attente de la réponse… Erreur de lecture (Connexion ré-initialisée par le correspondant) dans les en-têtes.
> Nouvel essai.
>
> --2022-04-05 19:36:40--  (essai :  2)  http://192.168.0.22:8080/184b50qkcrkchc6dpwwcd7ypqb5yvrm3.narinfo
> Connexion à 192.168.0.22:8080… connecté.
> requête HTTP transmise, en attente de la réponse… 200 OK
> Taille : 7428 (7,3K) [application/x-nix-narinfo]
> Sauvegarde en : « 184b50qkcrkchc6dpwwcd7ypqb5yvrm3.narinfo »
>
> 184b50qkcrkchc6dpwwcd7ypqb5yvrm3.narinfo        100%[=====================================================================================================>]   7,25K  --.-KB/s    ds 0,02s   
>
> 2022-04-05 19:36:40 (391 KB/s) — « 184b50qkcrkchc6dpwwcd7ypqb5yvrm3.narinfo » sauvegardé [7428/7428]
>
> Could that be the cause of the issue?

Yes, it could be the issue.  Is there any clue as to why ‘guix publish’
hung up first?  Something in its log maybe?

Ludo’.

[bug#54723] [PATCH] Check URI when verifying narinfo validity.

[Guillaume Le Vaillant]

[-- Attachment #1.1: Type: text/plain, Size: 1916 bytes --]

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

> Hi,
>
> Guillaume Le Vaillant <glv@posteo.net> skribis:
>
>> However for one of them it looks like the guix-publish server got stuck
>> on the request for several minutes (the second attempt worked):
>>
>> wget http://192.168.0.22:8080/184b50qkcrkchc6dpwwcd7ypqb5yvrm3.narinfo
>> --2022-04-05 19:33:56--  http://192.168.0.22:8080/184b50qkcrkchc6dpwwcd7ypqb5yvrm3.narinfo
>> Connexion à 192.168.0.22:8080… connecté.
>> requête HTTP transmise, en attente de la réponse… Erreur de lecture (Connexion ré-initialisée par le correspondant) dans les en-têtes.
>> Nouvel essai.
>>
>> --2022-04-05 19:36:40--  (essai :  2)  http://192.168.0.22:8080/184b50qkcrkchc6dpwwcd7ypqb5yvrm3.narinfo
>> Connexion à 192.168.0.22:8080… connecté.
>> requête HTTP transmise, en attente de la réponse… 200 OK
>> Taille : 7428 (7,3K) [application/x-nix-narinfo]
>> Sauvegarde en : « 184b50qkcrkchc6dpwwcd7ypqb5yvrm3.narinfo »
>>
>> 184b50qkcrkchc6dpwwcd7ypqb5yvrm3.narinfo
>> 100%[=====================================================================================================>]
>> 7,25K --.-KB/s ds 0,02s
>>
>> 2022-04-05 19:36:40 (391 KB/s) — « 184b50qkcrkchc6dpwwcd7ypqb5yvrm3.narinfo » sauvegardé [7428/7428]
>>
>> Could that be the cause of the issue?
>
> Yes, it could be the issue.  Is there any clue as to why ‘guix publish’
> hung up first?  Something in its log maybe?
>
> Ludo’.

There are 2 errors that occur a lot in the guix-publish log files:

 - "In procedure fport_write: Broken pipe"
    It happens when trying to write to a socket apparently.

 - "In procedure sign: gcrypt: Cannot allocate memory"
    The machine has 64 GiB of RAM, of which at least 50 GiB is free, so
    gcrypt should have enough to make a signature...

Note: full log file with complete error messages in attachment.

[-- Attachment #1.2: guix-publish.log.gz --]
[-- Type: application/octet-stream, Size: 337147 bytes --]

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

[bug#54723] [PATCH] Check URI when verifying narinfo validity.

[Guillaume Le Vaillant]

[-- Attachment #1: Type: text/plain, Size: 2642 bytes --]

Guillaume Le Vaillant <glv@posteo.net> skribis:

> There are 2 errors that occur a lot in the guix-publish log files:
>
>  - "In procedure fport_write: Broken pipe"
>     It happens when trying to write to a socket apparently.
>
>  - "In procedure sign: gcrypt: Cannot allocate memory"
>     The machine has 64 GiB of RAM, of which at least 50 GiB is free, so
>     gcrypt should have enough to make a signature...

I captured the network traffic between the "guix publish" server and
a "guix upgrade" client to see if the "broken pipe" errors could
come from real networking issues.
According to wireshark the problem doesn't come from there, the TCP
stream didn't have any error.

However, looking at the full TCP stream in wireshark I saw that the
"guix publish" server sends some bad narinfo responses.
Sometimes some parts of the response are missing (here, Signature
incomplete, URL and Compression fields missing):
--8<---------------cut here---------------start------------->8---
HTTP/1.1 200 OK
Content-Length: 959
Content-Type: application/x-nix-narinfo;charset=UTF-8

StorePath: /gnu/store/dxpaqmix7zixm8pwcvvmq8q969q50jpp-pngload-2.0.0-2.91f1d70-checkout
NarHash: sha256:0s94fdbrbqj12qvgyn2g4lfwvz7qhhzbclrpz5ni7adwxgrmvxl1
NarSize: 245224
References: 
Deriver: ybdimrfjs090kzmimf5j1x5hs8y4d24p-pngload-2.0.0-2.91f1d70-checkout.drv
Signature: 1;kitej;KHNpZ25hdHVyZSAKIChkYXRhIAogIChmbGFncyByZmM2OTc5KQogIChoYXNoIHNoYTI1NiAjNDY3NDk2RTJEOTZBMzc0QzFGN0M1MzJCNjc3MTM1NzVFOTkyRjQ0Qzc3MzQwRDUwQTcyRTkyMDJGRURDQkQxMyMpCiAgKQogKHNpZy12YWwgCiAgKGVjZHNhIAogICAociAjMDZEQTAwMkQyNjE3MEQ3ODVDNkM3NkMyMUEwM0UzNDlCMkUwMDc4MTUyQzFBQURFNjhFMEZGOUJDRkUyMUFDNSMpCiAgIChzICMwNjNDM0UyNjg2MEU2OTIzNDdEMjNGNTQ4RUM3RDJGRUZGQjc0Q0I4NjNEMjlDMUE3QjA4REFCQjEzQjZDRjAxIykKICAgKQogICkKIChwdWJsaWMta2V5IAogIC
--8<---------------cut here---------------end--------------->8---

Sometimes the response looks like almost complete garbage:
--8<---------------cut here---------------start------------->8---
HTTP/1.1 200 OK
Content-Length: 970
Content-Type: application/x-nix-narinfo;charsetcharsetHTTP/=UTF-8

1
1

1
.S
--8<---------------cut here---------------end--------------->8---

When the client receives these bad narinfos, it often makes it crash
with errors like:
 - Wrong type (expecting exact integer): #f
 - unmatched line "1\r"
 - Wrong type argument in position 1 (expecting pair): ()

So it looks like the broken pipe problem comes from the "guix publish"
server, or from Guile... And making the code reconstructing narinfos
from HTTP responses more robust in case of bad input would be useful.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

[bug#54723] [PATCH] Check URI when verifying narinfo validity.

[Ludovic Courtès]

Hi,

Guillaume Le Vaillant <glv@posteo.net> skribis:

> However, looking at the full TCP stream in wireshark I saw that the
> "guix publish" server sends some bad narinfo responses.
> Sometimes some parts of the response are missing (here, Signature
> incomplete, URL and Compression fields missing):
>
> HTTP/1.1 200 OK
> Content-Length: 959
> Content-Type: application/x-nix-narinfo;charset=UTF-8
>
> StorePath: /gnu/store/dxpaqmix7zixm8pwcvvmq8q969q50jpp-pngload-2.0.0-2.91f1d70-checkout
> NarHash: sha256:0s94fdbrbqj12qvgyn2g4lfwvz7qhhzbclrpz5ni7adwxgrmvxl1
> NarSize: 245224
> References: 
> Deriver: ybdimrfjs090kzmimf5j1x5hs8y4d24p-pngload-2.0.0-2.91f1d70-checkout.drv
> Signature: 1;kitej;KHNpZ25hdHVyZSAKIChkYXRhIAogIChmbGFncyByZmM2OTc5KQogIChoYXNoIHNoYTI1NiAjNDY3NDk2RTJEOTZBMzc0QzFGN0M1MzJCNjc3MTM1NzVFOTkyRjQ0Qzc3MzQwRDUwQTcyRTkyMDJGRURDQkQxMyMpCiAgKQogKHNpZy12YWwgCiAgKGVjZHNhIAogICAociAjMDZEQTAwMkQyNjE3MEQ3ODVDNkM3NkMyMUEwM0UzNDlCMkUwMDc4MTUyQzFBQURFNjhFMEZGOUJDRkUyMUFDNSMpCiAgIChzICMwNjNDM0UyNjg2MEU2OTIzNDdEMjNGNTQ4RUM3RDJGRUZGQjc0Q0I4NjNEMjlDMUE3QjA4REFCQjEzQjZDRjAxIykKICAgKQogICkKIChwdWJsaWMta2V5IAogIC
>
>
> Sometimes the response looks like almost complete garbage:
>
> HTTP/1.1 200 OK
> Content-Length: 970
> Content-Type: application/x-nix-narinfo;charsetcharsetHTTP/=UTF-8
>
> 1
> 1
>
> 1
> .S
>
> When the client receives these bad narinfos, it often makes it crash
> with errors like:
>  - Wrong type (expecting exact integer): #f
>  - unmatched line "1\r"
>  - Wrong type argument in position 1 (expecting pair): ()

Woow.  How do you build and run ‘guix publish’?  Is it a distro package
or is it coming straight from Guix?  What command-line options are you
passing?

I’ve never seen this, although we have it running on several servers,
notably ci.guix.  I wonder what could cause this.

Thanks,
Ludo’.

[bug#54723] [PATCH] Check URI when verifying narinfo validity.

[Guillaume Le Vaillant]

[-- Attachment #1: Type: text/plain, Size: 1534 bytes --]

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

> Woow.  How do you build and run ‘guix publish’?  Is it a distro package
> or is it coming straight from Guix?  What command-line options are you
> passing?
>
> I’ve never seen this, although we have it running on several servers,
> notably ci.guix.  I wonder what could cause this.
>
> Thanks,
> Ludo’.

I'm using guix-publish-service-type in the operating-system definition
to manage the "guix publish" server, using the on-the-fly mode and
fast Zstandard compression:

--8<---------------cut here---------------start------------->8---
(service guix-publish-service-type
         (guix-publish-configuration
          (host "0.0.0.0")
          (port 8080)
          (compression '(("zstd" 3)))
          (advertise? #t)))
--8<---------------cut here---------------end--------------->8---

When booting the machine, shepherd starts the server with the following
command-line options:

--8<---------------cut here---------------start------------->8---
/gnu/store/059svbd32i4s0l9s5i7z0krcnl666bjy-guix-1.3.0-24.2fb4304/libexec/guix/guile \ /gnu/store/059svbd32i4s0l9s5i7z0krcnl666bjy-guix-1.3.0-24.2fb4304/bin/guix publish -u guix-publish -p 8080 -C zstd:3 --nar-path=nar --listen=0.0.0.0 --advertise
--8<---------------cut here---------------end--------------->8---

There's another report about this at <https://issues.guix.gnu.org/53668>
I had forgotten about, where Simon Streit and Maxim Cournoyer indicate
that they have seen this issue too.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

[bug#54723] [PATCH] Check URI when verifying narinfo validity.

[Guillaume Le Vaillant]

[-- Attachment #1: Type: text/plain, Size: 4328 bytes --]

Guillaume Le Vaillant <glv@posteo.net> skribis:

> Ludovic Courtès <ludo@gnu.org> skribis:
>
>> Woow.  How do you build and run ‘guix publish’?  Is it a distro package
>> or is it coming straight from Guix?  What command-line options are you
>> passing?
>>
>> I’ve never seen this, although we have it running on several servers,
>> notably ci.guix.  I wonder what could cause this.
>>
>> Thanks,
>> Ludo’.
>
> I'm using guix-publish-service-type in the operating-system definition
> to manage the "guix publish" server, using the on-the-fly mode and
> fast Zstandard compression:
>
> (service guix-publish-service-type
>          (guix-publish-configuration
>           (host "0.0.0.0")
>           (port 8080)
>           (compression '(("zstd" 3)))
>           (advertise? #t)))
>
>
> When booting the machine, shepherd starts the server with the following
> command-line options:
>
> /gnu/store/059svbd32i4s0l9s5i7z0krcnl666bjy-guix-1.3.0-24.2fb4304/libexec/guix/guile \ /gnu/store/059svbd32i4s0l9s5i7z0krcnl666bjy-guix-1.3.0-24.2fb4304/bin/guix publish -u guix-publish -p 8080 -C zstd:3 --nar-path=nar --listen=0.0.0.0 --advertise
>
> There's another report about this at <https://issues.guix.gnu.org/53668>
> I had forgotten about, where Simon Streit and Maxim Cournoyer indicate
> that they have seen this issue too.

I tested a few things, and it looks like there is a concurrency issue in
the 'http-write' function of the publish server.
After removing the 'call-with-new-thread' in the part of the function
sending narinfos, I can't reproduce the "broken pipe" error anymore.

--8<---------------cut here---------------start------------->8---
diff --git a/guix/scripts/publish.scm b/guix/scripts/publish.scm
index 870dfc11e9..e9fad5845a 100644
--- a/guix/scripts/publish.scm
+++ b/guix/scripts/publish.scm
@@ -1002,28 +1002,25 @@ (define compression
            (begin
              (when (keep-alive? response)
                (keep-alive client))
-             (call-with-new-thread
-              (lambda ()
-                (set-thread-name "publish narinfo")
-                (let* ((narinfo
-                        (with-store store
-                          (narinfo-string store (utf8->string body)
-                                          #:nar-path nar-path
-                                          #:compressions compressions)))
-                       (narinfo-bv (string->bytevector narinfo "UTF-8"))
-                       (narinfo-length
-                        (bytevector-length narinfo-bv))
-                       (response (write-response
-                                  (with-content-length response
-                                                       narinfo-length)
-                                  client))
-                       (output (response-port response)))
-                  (configure-socket client)
-                  (put-bytevector output narinfo-bv)
-                  (force-output output)
-                  (unless (keep-alive? response)
-                    (close-port output))
-                  (values)))))
+             (let* ((narinfo
+                     (with-store store
+                       (narinfo-string store (utf8->string body)
+                                       #:nar-path nar-path
+                                       #:compressions compressions)))
+                    (narinfo-bv (string->bytevector narinfo "UTF-8"))
+                    (narinfo-length
+                     (bytevector-length narinfo-bv))
+                    (response (write-response
+                               (with-content-length response
+                                                    narinfo-length)
+                               client))
+                    (output (response-port response)))
+               (configure-socket client)
+               (put-bytevector output narinfo-bv)
+               (force-output output)
+               (unless (keep-alive? response)
+                 (close-port output))
+               (values)))
            (%http-write server client response body))))
     (_
      (match (assoc-ref (response-headers response) 'x-raw-file)
--8<---------------cut here---------------end--------------->8---

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

[bug#54723] [PATCH] Check URI when verifying narinfo validity.

[Ludovic Courtès]

Hi!

Guillaume Le Vaillant <glv@posteo.net> skribis:

> I tested a few things, and it looks like there is a concurrency issue in
> the 'http-write' function of the publish server.
> After removing the 'call-with-new-thread' in the part of the function
> sending narinfos, I can't reproduce the "broken pipe" error anymore.

Ah ha!  Little has changed in this code, so I think the culprit must be
f743f2046be2c5a338ab871ae8666d8f6de7440b.

Could you try running it from master with this patch reverted?

You can spawn it from the build tree with:

  sudo -E ./pre-inst-env guix publish -u nobody

Bonus points if you have a script to reproduce the issue.  I guess that
involves making pipelined keep-alive narinfo requests the way ‘guix
substitute’ and ‘guix weather’ do.

Thanks,
Ludo’.

[bug#54723] [PATCH] Check URI when verifying narinfo validity.

[Guillaume Le Vaillant]

[-- Attachment #1: Type: text/plain, Size: 2504 bytes --]

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

> Hi!
>
> Guillaume Le Vaillant <glv@posteo.net> skribis:
>
>> I tested a few things, and it looks like there is a concurrency issue in
>> the 'http-write' function of the publish server.
>> After removing the 'call-with-new-thread' in the part of the function
>> sending narinfos, I can't reproduce the "broken pipe" error anymore.
>
> Ah ha!  Little has changed in this code, so I think the culprit must be
> f743f2046be2c5a338ab871ae8666d8f6de7440b.
>
> Could you try running it from master with this patch reverted?
>
> You can spawn it from the build tree with:
>
>   sudo -E ./pre-inst-env guix publish -u nobody
>
> Bonus points if you have a script to reproduce the issue.  I guess that
> involves making pipelined keep-alive narinfo requests the way ‘guix
> substitute’ and ‘guix weather’ do.
>
> Thanks,
> Ludo’.

Hi,

With master at 101edbe63a887678722bc26cd85a7b7f5637428f, I reproduce the
issue very often when trying to upgrade a profile with around 400
packages. The logs of the publish server show hundreds of narinfo
requests and tens of "broken pipe" errors.

With an additional commit reverting
f743f2046be2c5a338ab871ae8666d8f6de7440b, I can't reproduce the issue
anymore. The logs still show hundreds of narinfo requests, but no
errors.


I tried to make a script making many narinfo requests to reproduce the
issue more easily, but I didn't get it to work yet. I thought accessing
the 'fetch-narinfos' function from "guix/substitutes.scm" with:

--8<---------------cut here---------------start------------->8---
(use-modules (guix)
             (guix substitutes))

(define fetch-narinfos (@@ (guix substitutes) fetch-narinfos))
--8<---------------cut here---------------end--------------->8---

would work, but it doesn't:

--8<---------------cut here---------------start------------->8---
$ guix repl fetch-narinfos.scm
Backtrace:
           4 (primitive-load "/home/guillaume/fetch-narinfos.scm")
In ice-9/eval.scm:
   626:19  3 (_ #<directory (guix-user) 7faab8e0e8c0>)
   223:20  2 (proc #<directory (guix-user) 7faab8e0e8c0>)
In unknown file:
           1 (%resolve-variable (5 (guix substitutes) # . #f) #<dire…>)
In ice-9/boot-9.scm:
  1685:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1685:16: In procedure raise-exception:
erreur : fetch-narinfos : variable non liée
--8<---------------cut here---------------end--------------->8---

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

[bug#54723] [PATCH] Check URI when verifying narinfo validity.

[Ludovic Courtès]

Hi,

(+Cc: Mathieu.)

Guillaume Le Vaillant <glv@posteo.net> skribis:

> With master at 101edbe63a887678722bc26cd85a7b7f5637428f, I reproduce the
> issue very often when trying to upgrade a profile with around 400
> packages. The logs of the publish server show hundreds of narinfo
> requests and tens of "broken pipe" errors.
>
> With an additional commit reverting
> f743f2046be2c5a338ab871ae8666d8f6de7440b, I can't reproduce the issue
> anymore. The logs still show hundreds of narinfo requests, but no
> errors.

For the record, a simple way to reproduce it is to start ‘guix publish’:

  sudo -E ./pre-inst-env guix publish -u nobody -p 9999

and to spawn ‘guix weather’, for example with:

  guix weather $(guix package -I. -p ~/.guix-home/profile |cut -f1) \
    --substitute-urls=http://localhost:9999

which crashes with the dreaded backtrace:

--8<---------------cut here---------------start------------->8---
Backtrace:
          11 (primitive-load "/home/ludo/.config/guix/current/bin/guix")
In guix/ui.scm:
   2230:7 10 (run-guix . _)
  2193:10  9 (run-guix-command _ . _)
In ice-9/boot-9.scm:
  1752:10  8 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _)
In guix/scripts/weather.scm:
    595:9  7 (_)
In guix/build/utils.scm:
   677:23  6 (every* #<procedure 7f4af9621de0 at guix/scripts/weather.scm:595:17 (server)> _)
In guix/scripts/weather.scm:
   597:21  5 (_ "http://localhost:9999")
   120:17  4 (report-server-coverage _ ("/gnu/store/428bzp9325mfapyr4ywzwsz4ic7ssx2b-shepherd-0.9.0" "/gnu/store/sll9nfmqk8lkrraqbkyp3y…" …) …)
In unknown file:
           3 (_ #<procedure 7f4af896ca40 at guix/scripts/weather.scm:201:2 ()> #<procedure list _> . #w())
In guix/substitutes.scm:
   322:31  2 (lookup-narinfos "http://localhost:9999" _ #:open-connection _ #:make-progress-reporter _)
   245:26  1 (fetch-narinfos _ _ #:open-connection _ #:make-progress-reporter _)
In ice-9/boot-9.scm:
  1685:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1685:16: In procedure raise-exception:
Wrong type (expecting exact integer): #f
--8<---------------cut here---------------end--------------->8---

I looked more closely at f743f2046be2c5a338ab871ae8666d8f6de7440b and I
think it had a logical flaw: if you pipeline 100 GET requests, then,
with this commit, ‘guix publish’ would spawn 100 threads that would all
reply concurrently (more or less).  This is clearly wrong: replies
should be sent sequentially.

So in commit c1719a0adf3fa7611b56ca4d75b3ac8cf5c9c8ac I went ahead and
reverted it that commit.  I also added a test that reproduces the issue
above.


Now, commit f743f2046be2c5a338ab871ae8666d8f6de7440b was itself an
attempt to fix a bug whereby ‘narinfo-string’ would take too long,
thereby preventing ‘guix publish’ from accepting connections (since it’s
single-threaded).

I think the only reasonable way to fix it is by using Fibers to make
‘guix publish’ concurrent (using a fiberized server like in Cuirass).
We should do that at some point.  That’ll also allow us to remove some
of the hacks we’ve accumulated.

Now, the only way ‘narinfo-string’ can take too long these days is (I
think) if the store GC lock is held (we should check that hypothesis,
but I believe that if the GC lock is held, then the ‘query-path-info’
RPC made from ‘narinfo-string’ might block until the lock is released).
The GC lock is no longer held for hours on berlin, so there’s less
pressure to address that.

To summarize: I think ‘guix publish’ is okay as-is but we should
fiberize it sometime.

Thoughts?

Ludo’.

bug#54723: [PATCH] Check URI when verifying narinfo validity.

[Ludovic Courtès]

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

> So in commit c1719a0adf3fa7611b56ca4d75b3ac8cf5c9c8ac I went ahead and
> reverted it that commit.  I also added a test that reproduces the issue
> above.

Commit 9eca13094d9bdf091f9096e0f3a8b450dac0e595 updates the ‘guix’
package, so you can now pull, reconfigure, and enjoy.  :-)

Ludo’.

bug#54723: [PATCH] Check URI when verifying narinfo validity.

[Guillaume Le Vaillant]

[-- Attachment #1: Type: text/plain, Size: 472 bytes --]

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

> Ludovic Courtès <ludo@gnu.org> skribis:
>
>> So in commit c1719a0adf3fa7611b56ca4d75b3ac8cf5c9c8ac I went ahead and
>> reverted it that commit.  I also added a test that reproduces the issue
>> above.
>
> Commit 9eca13094d9bdf091f9096e0f3a8b450dac0e595 updates the ‘guix’
> package, so you can now pull, reconfigure, and enjoy.  :-)
>
> Ludo’.

I just tried and everything worked without a glitch.
Thanks.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

bug#54723: [PATCH] Check URI when verifying narinfo validity.

[Mathieu Othacehe]

Hey Ludo,

> Now, the only way ‘narinfo-string’ can take too long these days is (I
> think) if the store GC lock is held (we should check that hypothesis,
> but I believe that if the GC lock is held, then the ‘query-path-info’
> RPC made from ‘narinfo-string’ might block until the lock is released).
> The GC lock is no longer held for hours on berlin, so there’s less
> pressure to address that.

Thanks for having a look to that issue. On my side, I'd like to take
some time to look closely at the situation.

> To summarize: I think ‘guix publish’ is okay as-is but we should
> fiberize it sometime.

I think however that it would be nice to create a wip branch for those
changes, deploy it and monitor it closely on Berlin before pushing. From
experience, the publish code is really fragile and the I/O pressure on
Berlin can exhibit a lot of unexpected issues.

Mathieu

bug#54723: [PATCH] Check URI when verifying narinfo validity.

[Ludovic Courtès]

Hi,

Mathieu Othacehe <othacehe@gnu.org> skribis:

> I think however that it would be nice to create a wip branch for those
> changes, deploy it and monitor it closely on Berlin before pushing. From
> experience, the publish code is really fragile and the I/O pressure on
> Berlin can exhibit a lot of unexpected issues.

Agreed, it looks like we have to be more cautious now.

Ludo’.