Re: On raw strings in <origin> commit field

[zimoun]

Hi Mark, Liliana, all,

On Sat, 01 Jan 2022 at 15:37, Mark H Weaver <mhw@netris.org> wrote:

>>> Where is the Cantor-style diagonalization argument that you spoke of?
>>
>> You skipped over it, read again.  The key point is that you're
>> referencing the thing you think will be invalidated to create your
>> scheme.
>
> I've carefully read your message at least 4 times, but I've been unable
> to find anything resembling Cantor's diagonalization argument in there.
> Does anyone else see it?  Perhaps my powers of recognition are too weak.

Mark, I do not see the diagonalization either.  Liliana, please point
explicitly what acts as diagonale in your reasoning.  Or anyone else if
I am missing the obvious.

That’s said, I think the reasoning is doomed earlier.  It reads,

        Okay, so let's write out the full argument.  At a certain date,
        we package or update P to version V through reference to tag T
        (at commit C).  Because we can't trust T to remain valid, we
        only keep (V, C) around for "robustness".

        Now notice, how version V is generated by referring to T.  Without loss
        of generality, assume that T is invalidated, otherwise nothing to
        prove.  Since V is created through reference to T, it is also
        invalidated as being the canonical V, whichever it is.  A similar
        argument can be made for C as well.  So both (V, C) are invalidated and
        the only thing we can claim is "yeah, upstream did tag that T at some
        point".

<https://yhetil.org/guix/762e9fb7116c442bf0f8f63221bf32fa2b77f2cf.camel@gmail.com>


And this statement «Without loss of generality, assume that T is
invalidated, otherwise nothing to prove.  Since V is created through
reference to T, it is also invalidated as being the canonical V,
whichever it is.» is not enough precise.

Because the pair (V,C) is fixed by Guix packagers; thus whatever T is
becoming, then the pair (V,C) is not invalidated.  What is invalidated
is the match between what upstream calls version (what we can name
upstream canonical) and what the Guix project considers as version (what
the end-user expects similar to the upstream canonical one).  Timothy
provided an example of such mismatch.

The reasoning requires 2 versions: the upstream canonical version V’
linked to T.  And the Guix-related version noted V and used by the pair
(V,C) in the package definition.  It appears to me hard to infer logical
arguments for the link between V and V’.

Moreover, the pair (V,C) is stored inside the immutable Guix history.
Yeah, maybe tomorrow we will all be crazy and rewrite all the Guix
history, because yes Guix history is just one DAG we collectively agree
on – I would not say it is a social construct though, anyway.


As I tried to explain
<https://yhetil.org/guix/86ilv46hls.fsf@gmail.com>, the Guix ’version’
field matches as much as possible upstream “canonical” version defined
by tag, commit, url, revision, etc. but both are not the same thing.  In
addition, Git-tag and Git-commit are not the same philosophical
ontology.

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.


Moreover, Liliana you wrote:

        Git commit hashes do not just depend on the content.  They also
        depend on how much effort you put into solving a proof of work
        challenge that won't ever earn you crypto coins [1].

pointing to <https://github.com/tochev/git-vanity>.  The statement «Git
commit hashes do not just depend on the content» is wrong.
Specifically, it is by adding more well-chosen content that the hash is
tricked.  Now, Liliana, you can define “content“ by useful content
opposed as meta-content, etc.  Well, it is fine but the statement still
appears to me wrong because Git commit hash only depends on the content
itself.

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.


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.

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.

Then, we can come up and question by overcomplicated philosophico-logics
and metaphysics arguments the meaning of life, fore sure it is
interesting – at least I find it sometimes interesting :-) – but I am
doubtful it helps in cooking the rice. ;-)

Cheers,
simon