[bug#69780] [PATCH 4/4] DRAFT news: Add entry for ‘guix git authenticate’ changes.

[Ludovic Courtès]

Hi!

Skyler Ferris <skyvine@protonmail.com> skribis:

> Fair enough, that can be addressed in a separate patch. On a related note, 
> this patch reminded me of an idea I mentioned in a private thread with the 
> security team about writing a package that provides `guix git authenticate` 
> as a standalone script, which can be done by extracting the dependent modules 
> and building just them (I have successfully done this for the "(guix build 
> utils)" library, for shell-like guile scripts that have a lighter footprint 
> than all of guix). This will help people who are installing guix from source 
> for the first time. They will not have guix itself available, but it would be 
> easier for them to use the standalone script than to install all of guix 
> (which they will presumably be replacing anyway). Is there anything else 
> around `guix git authenticate` you are working on that might conflict with 
> this? I am starting to look at it now that I have been reminded.

I must say I’m usually focusing on the use case where people building
Guix from source already have a working Guix installation.  In that
case, it’s that installation that provides a source of trust.

For someone building entirely from source, I don’t know what the right
solution is.  It could be extracting ‘guix git authenticate’ as you say,
but then we’re just offsetting the problem.  We could just as well
recommend building from a signed tag (or signed source tarball) after
verifying it.  Dunno what a good bootstrapping story might be.

>> I spent time looking for the “right” hook and couldn’t find anything
>> really satisfying.  Ideally, I’d want a hook that runs on ‘fetch’, for
>> each new reference.
>>
>> Is post-merge better than post-checkout?  githooks(5) says ‘post-merge’
>> “is invoked by git-merge(1), which happens when a git pull is done on a
>> local repository.”  Is it actually invoked when ‘git pull’ does *not*
>> trigger a merge?
>
> That gave me pause too, but I tested it with a pull that caused a 
> fast-forward (no separate merge commit) and it still ran the hook. I looked 
> for a `post-fetch` hook but couldn't find one, I agree that would be ideal.

OK, thanks for checking.

>> Using this configuration format, it seems there’s no room left for a
>> branch name, or am I overlooking something?

[...]

> Hmm, I didn't realize that git limited the number of components available in 
> config names, but it looks like you're correct - my suggestion of appending 
> `.branch-name` caused git to produce an error that the config was invalid.
>
> But we don't necessarily need git to be aware of the semantic meaning of the 
> branch name since the value is calculated by the guile script. So we could 
> just use a hyphen as a separator and have "introduction-commit-master" and 
> "introduction-commit-feature" as separate values unrelated to each other 
> (aside from being in the "guix authentication" namespace).

Hmm right.  Not pretty, but why not.

We could still have ‘introduction-commit’ as a default, and
‘introduction-commit-BRANCH’ would take precedence over it when present.

Thanks for your feedback!

Ludo’.