guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: git-fetch without a hash


From: bokr
Subject: Re: git-fetch without a hash
Date: Sun, 5 Feb 2023 18:44:10 +0100
User-agent: Mutt/1.10.1 (2018-07-13)

Hi,

On +2023-01-11 16:34:41 +0100, Simon Tournier wrote:
> Hi,
> 
> On Mon, 09 Jan 2023 at 12:16, Ludovic Courtès <ludo@gnu.org> wrote:
> > Simon Tournier <zimon.toutoune@gmail.com> skribis:
> >
> >> Maybe my question is naive but what is the use case for this (sha256 #f)
> >> in the first place?  Because maybe it could just error using some
> >> ’sanitize’ for the hash record field.
> >
> > There’s a couple of uses: Chromium, IceCat, and Linux-libre (IIRC).
> >
> > I don’t like that, but I’m not sure what it would take to change these
> > to <computed-file> or something like that.
> 
> Well, from (gnu packages linux)
> 
> --8<---------------cut here---------------start------------->8---
>      (origin
>        (method computed-origin-method)
>        (file-name (string-append "linux-libre-" version "-guix.tar.xz"))
>        (sha256 #f)
> --8<---------------cut here---------------end--------------->8---
> 
> and from (gnu packages gnuzilla)
> 
> --8<---------------cut here---------------start------------->8---
>     (origin
>       (method computed-origin-method)
>       (file-name (string-append "icecat-" %icecat-version ".tar.xz"))
>       (sha256 #f)
> --8<---------------cut here---------------end--------------->8---
> 
> but not from Chromium, if I read correctly.
> 
> From my understanding, we could have something like,
> 
>       (sha256 (no-hash))
> 
> where ’no-hash’ would return a string, say
> "0000000000000000000000000000000000000000000000000000" or whatever else
> that would satisfy this hypothetical  ’sha256’ sanitizer.
> 
> 
> Cheers,
> simon
>

For portability to any hash algorithm that returns a hex string,
how about letting them hash a zero-length string (which can never
represent a package tarball or other archive), and using the
resulting strings as no-hash flags?

These strings must be unique for whatever hash algorithm,
so a short table could be used to recognize them as
no-hash indicators.

--8<---------------cut here---------------start------------->8---
$ sha256sum /dev/null
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855  /dev/null
$ sha256sum <(echo -n '')
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855  /dev/fd/63
$ echo -n ''|sha256sum
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855  -
$ echo -n ""|sha256sum
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855  -
--8<---------------cut here---------------end--------------->8---


For other hash values on your system, probably the below will show most.
Translating from hex to various base32 and other-base alphabets
is then trivial, (and open, i.e. permitting new hash representation strings).
--8<---------------cut here---------------start------------->8---
$ ls -1d /usr/bin/*sum|while read hasher;do \
  echo;echo "$hasher:"; "$hasher" /dev/null;done
--8<---------------cut here---------------end--------------->8---

WDYT?
--
Regards,
Bengt Richter



reply via email to

[Prev in Thread] Current Thread [Next in Thread]