Re: On raw strings in <origin> commit field

[Mark H Weaver]

Hi Liliana,

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

> Am Mittwoch, dem 29.12.2021 um 20:13 -0500 schrieb Mark H Weaver:
[...]
>> The simple fact is that the way Ricardo wrote the 'guile-aiscm' package
>> is the right way to ensure that it can be reliably reproduced in the
>> future.
> And here I disagree.  This reasoning presupposes that we have to ensure
> that the package still points to the same commit if the tag changes,
> which itself presupposes that the tag does change.

I disagree with the last line above.  What makes you think that I'm
presupposing that the tag does change?

There's a difference between "presupposing that the tag does change" and
"not assuming that the tag will not change".  Do you see the difference?

> However, if we are
> always talking about more than one possible "1.2.3" (with the included
> future tag that we have yet to witness), we lose the basis by which we
> currently assign "1.2.3" as the version 

I see what you're getting at here, but still I disagree.  Our basis for
associating version "1.2.3" with commit XYZ is simply that upstream had
indicated that version "1.2.3" was commit XYZ.  That historical fact is
immutable.

If upstream later indicates that version "1.2.3" is now commit YYZ, I
don't think that invalidates our basis for continuing to associate
version "1.2.3" with commit XYZ.  The aforementioned immutable
historical fact still remains our basis and justification for making
that association.

Perhaps some people would prefer to use a distro where version "1.2.3"
of package FOO could mean a different thing tomorrow than it means
today.  Personally, that's not what I want.

If upstream changes their mind about the meaning of version "1.2.3", I
want that to correspond to a different version number in Guix, perhaps
"1.2.3a" or something, as Taylan suggested.  Incidentally, I vaguely
recall that we've done that in the past, but I don't know if we've done
it consistently.

> As pointed out elsewhere, SWH keeps a history of the tags that we could
> look up until one matches,

Only if SWH took a snapshot at the right time.  I would guess that
mutations of release tags usually happen within a few days after the
release tag is first created.  Relying on SWH to take a snapshot within
that possibly quite small time interval doesn't sound very robust to me.

> and there'd also be the option to keep a
> secondary index ourselves (or have a third party do it).

That's true, but then we'd be adding another piece of centralized
infrastructure that users would need to rely upon in order to reliably
reproduce their systems.  That infrastructure would have to be
maintained indefinitely.  If we failed to keep up maintenance, then
users could run into problems reproducing their older systems.

It seems to me clearly better to avoid relying on a piece of centralized
infrastructure if it can be easily avoided, no?

>> On the other hand, if we refer to git _commit hashes_, then it *is*
>> feasible for us to fetch the archived source from SWH, regardless of
>> what upstream has done to its tags in the meantime.
>> 
>> For that reason alone, I think that the way Ricardo wrote the
>> guile-aiscm package definition is clearly the right approach, given
>> Guix's longstanding goals.
> To me, it rather sounds like a workaround for longstanding bugs [1, 2].
[...]
> [1] https://issues.guix.gnu.org/28659
> [2] https://issues.guix.gnu.org/39575

I don't understand how it's a workaround for those bugs.  Even if those
bugs were fixed, we'd still need a reliable way to find the git commit
that matches the one expected by a git-fetch <origin> record, i.e. the
one that will produce a source checkout with the expected SHA256 hash.

Am I missing something?

>> > On the note of fallbacks, we do also have the issue that Guix fails
>> > on the first download that does not match the hash instead of e.g.
>> > continuing to SWH to fetch an archive of the old tag (as well as
>> > other fallback-related issues, also including the "Tricking Peer
>> > Review" thread).
>> 
>> That's a bug that can, and should, be fixed.  The existence of that
>> bug might temporarily prevent us from enjoying the benefits of
>> Ricardo's approach, but that's not an argument for adopting practices
>> that push us farther from our core goals.
>> 
>> What do you think?
> Which bug are you talking about?  "Tricking Peer Review" or the
> fallback thing?

I was talking about the fallback issue.

> If it's the fallback thing, then that's an enabler for
> Ricardo's approach, since as you pointed out the commit will still be
> fetched correctly from SWH (if not from the main repo itself). 

Right.

> Now, "Tricking Peer Review" is a harder thing to circumvent.  We would
> need to issue a warning, preferably a big one if fallbacks do kick in
> unintended, i.e. particularly outside of time-machine.

Regarding "Tricking Peer Review": I think it would be ideal for package
definitions to include both the git tag _and_ the git commit hash, and
to teach our linter to raise an alarm when the expected tags are missing
or fail to match the expected commit hash.

For similar reasons, it would also be good to include the fingerprints
of upstream PGP signing keys in our package definitions, and to teach
our linter to check those signatures and that they match the SHA256
hashes in our recipes.

What do you think?

      Regards,
        Mark

-- 
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about <https://stallmansupport.org>.