Re: On raw strings in <origin> commit field

[Liliana Marie Prikler <liliana.prikler@gmail.com>]

Hi Simon,

Am Sonntag, dem 02.01.2022 um 20:30 +0100 schrieb zimoun:
> Last on this point, using ’git-version’ and commit or tag to define
> Guix version (the field ’version’) is not related to the issue of
> referring by tag or commit in ’uri’ field.  That’s not the same
> level.
Look at the title, now back to me, now back to the title, now back to
me.  Sadly, that title is not about whether to use a commit in the
<git-reference>, but whether to use a *raw* commit string and not
indicating so in the version field of the <package>.  So while a
preference of git-fetch over url-fetch, commit over tag (or the other
way round) are perhaps adjacent, the use of this style rather than let-
bound commits with git-versions is pretty damn relevant.

> The statement still appears to me wrong because Git commit hash only
> depends on the content itself.
If you define content through the NAR hash used by Guix, I'm pretty
sure vanity commits invalidate that statement.

> If your point is that Git using SHA-1 is subject to chose-prefix
> attack, yeah it is well-known since,
> 
>     https://sha-mbles.github.io/
> 
> and it is even discussed in the long thread “Tricking peer review”
> <https://yhetil.org/guix/874k9if7am.fsf@inria.fr>.  For instance, see
> my email about SWH case <
> https://yhetil.org/guix/86r1cgcb8r.fsf@gmail.com>.
> 
> Even more, we discussed chosen-prefix attack and SHA-1 for channel
> fallback starting here <https://issues.guix.gnu.org/44187#10>.
> 
> Somehow, as always and even outside content-address system, you have
> to distinguish between identifier and integrity.  Anyway.
That might work against injecting evil content, but the attack surface
for a denial of surface (which is what we need to consider in our
robustness argument) is a little larger, don't you think?  Heck, if I'm
in control of the forge and I used a preimage attack to push a
different commit under the same hash, Guix would not even bother using
SWH and just error out (once substitutes have been garbage-collected,
which again is a prerequisite for any robustness argument and may
therefore be assumed).

> In despite of being aware (before this discussion) of many flaws, I
> am still thinking that intrinsic values is better than extrinsic
> values for referencing source or paper or else.  And yes, intrinsic
> values are not the perfect solution but it is really better than
> extrinsic ones; and it is not because it is not perfect that it is
> not worth or preferable.
> Although not perfect, it is still better.  Where the impression of
> all your lengthy answers provide is that intrinsic referencing has
> some well-known issues so let find overcomplicated strategies to fix
> extrinsic referencing which has even more issues.
If intrinsic values are so good, why wouldn't you use them for versions
then?  :P

Our issues here are not of technological nature, they are social
issues.  I don't care if we're using SemVer, CalVer, jiffies the start
of the pandemic, BibleVerse or years since the birth of Kim Il Sŏng to
version and url-fetch, svn-fetch, git-fetch, or butterfly-fetch to
fetch software.  I care about consistency, both internal and external,
which for any given package means using (V(T), T) or (V(T, C), C) and
not (V(T), C), though of course the choice of which might vary.

> Well, I am confused by what you are trying to raise in all this now
> lengthy thread – I have read it several times. :-)
> 
> To me, the points for more intrinsic values and less extrinsic ones
> in ’uri’ field are:
> 
>  1. yes, upstream extrinsic addressing are handy
>  2. but they add burden for lookup
>  3. uri requires intrinsic addressing to ease long term
>  4. it is not clear what intrinsic values pick and how to transition
> 
> and for ’version’ field, we can do whatever we want as Guix
> packagers.
There are a few equivalent ways of formulating my core point here, so
pick the one you're most comfortable with:
1. If you can't trust tag T to uniquely label version V(T), you cannot
do so for the commit C it points to either.
2. If you can't trust tag T to always point to commit C, there is no
basis on which you can claim V(T) is provided by C.
3. If you version a package V(T) and fetch it using commit C, but T
points to C', that's an issue.

Bonus claim as a length extender:
4. If you cannot trust commit C to remain for as long as you want it to
stay... well, then you'd better not use git-fetch at all, don't you
think?

> Guix history is just one DAG we collectively agree on – I would not
> say it is a social construct though, anyway.
Oh, but it is, and it has been changed in the past.  Now try finding
out when.  Bonus points if you do so in 10 years without referring to
logs.guix.gnu.org.  Jackpot if you do so after Guix switched its
version control system because Git still uses SHA-1 in year N and it
has been utterly broken at that point.

All our versioning systems, whether "intrinsic" or extrinsic are
socially constructed through our collective agreement to use the same
software to assign meaning to a particular mapping.