[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
- Re: git-fetch without a hash,
bokr <=