Re: How to create and maintain a personal Guix fork?

[45mg]

Hi Tomas,

Tomas Volf <~@wolfsden.cz> writes:

> I do have some ideas regarding how to do it, but all of them are fixes
> intended to solve "authenticating my Guix fork", not general fixes for
> guix-git-authenticate.  But I think it can be made to work (sadly it
> will not be pretty though).

I think I may have an idea myself; one that seems reasonably clean,
would fix our use-case of authenticating our own personal Guix forks,
and would even allow pulling branches from other people's forks and
authenticating those.

We could allow users to specify additional channel introductions. So,
there's always one primary introduction, but there can also be one or
more additional ones.

Then, when authenticating commits, we choose the introduction that is
the most recent ancestor of the latest commit, and authenticate that
range.

For commits that have multiple parents - ie. merge commits - we weaken
the invariant as follows:

1. If all parents have the primary introduction as their most recent
   ancestor, then the invariant holds as usual.
   
2. If one or more parents has the primary introduction as its most
   recent ancestor (call these the 'primary parents'), and the rest have
   any of the additional introductions, then the merge commit is
   authenticated if and only if:
   a) it's signed by a key authorized in all of the primary parents, AND
   b) the /first parent/ [^] of the merge commit is a primary parent.
   
3. If all parents have the same additional introduction as their most
   recent ancestor, then the invariant holds as usual.

4. If none of the parents have the primary introduction as their most
   recent ancestor, nor do they have the same additional introduction,
   then the merge commit cannot be authenticated.

[^] Quoting from the Pro Git book [1]:
> ...the first parent of a merge commit is from the branch you were on
> when you merged (frequently master), while the second parent of a
> merge commit is from the branch that was merged...

The idea is - the primary introduction is for the part of the tree under
YOUR control. When you fork Guix and create your own branch, you use the
initial commit on your branch as the primary channel introduction. You
add upstream Guix's primary channel introduction as an additional
channel introduction. If you add anyone else's fork as a remote and pull
one of their branches, you add their primary introduction as one of your
additional introductions.

Thus, any merge into one of YOUR branches (ie. any branch with the
primary introduction as the most recent ancestor) only needs to be
signed by a key that's authorized on that branch.

But you can't merge into a branch from upstream Guix or someone else's
authenticated fork (unless you're authorized to commit to those),
because the first parent of the merge commit would not be a primary
parent (see 2b) - it would be a commit on someone else's branch. And
people not authorized by you can't merge into your branch either,
because of 2a. And finally, you can't merge someone else's fork and
upstream, or anything like that. The merge commit would not be
authenticated in any of these cases.

What do you think? I don't actually know when I can work on a patch for
this (I've spent far too much time on this issue already), but it'd be
nice to have a sanity check on this anyway, so that if the approach is
fundamentally flawed in some obvious way that I'm missing, then I don't
have to waste my time on it.

[1] https://git-scm.com/book/en/v2/Git-Tools-Revision-Selection