bug#58149: guix pull error

[bokr@bokr.com]

Hi Ludo, Simon, et interested ..

On +2022-10-04 12:11:52 +0200, Ludovic Courtès wrote:
> Hi,
> 
> Matthieu Haefele <matthieu.haefele@cnrs.fr> skribis:
> 
> > Le 03/10/2022 à 16:03, Ludovic Courtès a écrit :
> 
> [...]
> 
> >> You should be able to get around it by first building things locally:
> >>
> >>    guix build --no-substitutes \
> >>      $(guix gc --derivers /gnu/store/r658y3cgpnf99nxjxqgjiaizx20ac4k0-guile-2.2.4)
> >>
> >> This is going to take a while though…
> >>
> >> I’m sorry this upgrade turns out to be so painful.  We know what to work
> >> on next.
> >>
> > Problems at fetching the kernel sources apparently...
> >
> > (base) mhaefele@mdlspc113:m2-mms-hpc (master)*$ guix build --no-substitutes \
> >>     $(guix gc --derivers /gnu/store/r658y3cgpnf99nxjxqgjiaizx20ac4k0-guile-2.2.4)
> > The following derivations will be built:
> >   /gnu/store/16c8c8hm1qdn6xz8014939mirc7c4d4j-guile-2.2.4.drv
> >   /gnu/store/06pscnfdljxnyb673pqyhnvz1x5rjl1l-libgc-7.6.6.drv
> > /gnu/store/4k028mc8dnnx478dirgx90rpby465jqr-ld-wrapper-boot3-0.drv
> >   /gnu/store/agrwc0hhkxjb96z66nb6hakimb4a2vg3-module-import.drv
> 
> [...]
> 
> > Starting download of /gnu/store/f2j6pi0d18pbz35ypflp61wzhbfcr8dp-linux-libre-4.14.67-gnu.tar.xz
> > From https://linux-libre.fsfla.org/pub/linux-libre/releases/4.14.67-gnu/linux-libre-4.14.67-gnu.tar.xz...
> > download failed "https://linux-libre.fsfla.org/pub/linux-libre/releases/4.14.67-gnu/linux-libre-4.14.67-gnu.tar.xz" 404 "Not Found"
> 
> [...]
> 
> > Starting download of /gnu/store/f2j6pi0d18pbz35ypflp61wzhbfcr8dp-linux-libre-4.14.67-gnu.tar.xz
> > From https://mirror.hydra.gnu.org/file/linux-libre-4.14.67-gnu.tar.xz/sha256/050zvdxjy6sc64q75pr1gxsmh49chwav2pwxz8xlif39bvahnrpg...
> > In procedure connect: Network is unreachable
> 
> You can fetch it with:
> 
>   wget -O linux-libre-4.14.67-gnu.tar.xz \
>        https://ci.guix.gnu.org/file/linux-libre-4.14.67-gnu.tar.xz/sha256/050zvdxjy6sc64q75pr1gxsmh49chwav2pwxz8xlif39bvahnrpg
>   guix download file://$PWD/linux-libre-4.14.67-gnu.tar.xz
> 
> Let’s see if you can proceed from there.
> 
> At any rate, it’s a good lesson for us developers, so thanks for
> persevering.
> 
> Ludo’.
> 

As you know, particular upstream kernels can be found like
--8<---------------cut here---------------start------------->8---
$ lynx -dump -listonly https://kernel.org/pub/linux/kernel/v4.x/ | egrep 4.14.67\|sha256 
 558. https://mirrors.edge.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.14.67
3155. https://mirrors.edge.kernel.org/pub/linux/kernel/v4.x/linux-4.14.67.tar.gz
3156. https://mirrors.edge.kernel.org/pub/linux/kernel/v4.x/linux-4.14.67.tar.sign
3157. https://mirrors.edge.kernel.org/pub/linux/kernel/v4.x/linux-4.14.67.tar.xz
7177. https://mirrors.edge.kernel.org/pub/linux/kernel/v4.x/patch-4.14.67.xz
9018. https://mirrors.edge.kernel.org/pub/linux/kernel/v4.x/sha256sums.asc
--8<---------------cut here---------------end--------------->8---

Well, you noticed the extra pattern in the search, I'm sure. :)

What's interesting about sha256sums.asc is that you can do this:
--8<---------------cut here---------------start------------->8---
$ wget -q -O- https://mirrors.edge.kernel.org/pub/linux/kernel/v4.x/sha256sums.asc|egrep 4\\.14\\.67
93b4ea4816a8a73e4ba2d9c26dc622035b1b504010f1048c0455a190a653166e  ChangeLog-4.14.67
a53d3a3b5877e1847fb34ecb75aabce2a1bf3cc0ee7236cf2aef02f0ecf83433  linux-4.14.67.tar.gz
3f4b056dc27233a78f7a4a35ed6fdcfd0a9680ec40b611a898bb6c8b905070ba  linux-4.14.67.tar.xz
42c7ff27d7cefbf0b4e313c757db1f2cfa2d65fa22cbe908c24aafafc995bd5f  patch-4.14.67.xz
--8<---------------cut here---------------end--------------->8---

Which provides a little menu of relevant things.
E.g, we can choose to download the .xz tarball and verify it like
--8<---------------cut here---------------start------------->8---
$ time wget -q https://mirrors.edge.kernel.org/pub/linux/kernel/v4.x/linux-4.14.67.tar.xz

real    0m47.015s
user    0m2.381s
sys     0m3.720s
$ sha256sum linux-4.14.67.tar.xz 
3f4b056dc27233a78f7a4a35ed6fdcfd0a9680ec40b611a898bb6c8b905070ba  linux-4.14.67.tar.xz
--8<---------------cut here---------------end--------------->8---

IMO it would significantly enhance the security and trust assurances
provided by guile and guix repos to adopt this practice from kernel.org.

It is cheap and easy to implement, and provides an integrity check
which can coexist with others provided in various distro VCSs and
package management systems.

UIAM it would also provide another option in writing a package definition
in the part that defines how to get the source and check hashes.
(who wants to show how it would look for the hello pachage? :)

WDYT?

For me, a really trusted well known figure like GkH or Linus as signer
is reassuring, but I think whoever the person is is less important
than providing a verifiable public coherent snapshot (if race-careful)
listing of hash names for the set of files.

People can then discuss the file contents and make references unambigously
by hash (and discuss duplicate hashes with different file names associated :)

A file identified by hash and creating trouble will soon have discussion
on the net, but unless its content is unambiguously specified by its name
people can't be certain they're talking about the exact same thing.

That obviously the role of the hash as verifiable name here.
Any decent search engine should then be able to list discussions
citing the hash for you.

Then we can have lists of discussions, signed by a curator ...  :-p
--
Regards,
Bengt Richter
PS. A cloned guile or guix repo is of course a directory, and selected files
    could be given a sha256sums.asc index and be tracked by git, updated at
    at specially significant commit times. Or is that crazy?
    WDYT??

    Also, would there be places in the https://ci.guix.gnu.org/ tree that it
    would make sense to put sha256sums.asc instances in?
          E.g., What directory does
    https://ci.guix.gnu.org/file/linux-libre-4.14.67-gnu.tar.xz/sha256/050zvdxjy6sc64q75pr1gxsmh49chwav2pwxz8xlif39bvahnrpg
          appear in by ordinary file name?