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

[Skyler Ferris via Guix-patches via <guix-patches@gnu.org>]

[-- Attachment #1: Type: text/plain, Size: 3441 bytes --]

On 3/19/24 07:12, Ludovic Courtès wrote:

> Right.  Like I wrote when replying to Tomas, I view this as a helper
> primarily for people outside Guix itself, because Guix already has its
> own hooks installed as you write.
>
> We could discuss what to do with Guix’s own hooks, but to me that’s a
> separate issue.

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 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.

> Very good point.  Now, what would it look like?
>
> Currently we have:
>
> --8<---------------cut here---------------start------------->8---
> [guix "authentication"]
>         introduction-commit = 9edb3f66fd807b096b48283debdcddccfea34bad
>         introduction-signer = BBB0 2DDF 2CEA F6A8 0D1D  E643 A2A0 6DF2 A33A 54FA
>         keyring = keyring
> --8<---------------cut here---------------end--------------->8---
>
> Using this configuration format, it seems there’s no room left for a
> branch name, or am I overlooking something?
>
> Or we could take the risk of removing ‘guix’ and make it:
>
> --8<---------------cut here---------------start------------->8---
> [authentication "master"]
>         introduction-commit = 9edb3f66fd807b096b48283debdcddccfea34bad
>         introduction-signer = BBB0 2DDF 2CEA F6A8 0D1D  E643 A2A0 6DF2 A33A 54FA
>         keyring = keyring
> --8<---------------cut here---------------end--------------->8---
>
> WDYT?

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).

Regards,
Skyler

[-- Attachment #2: Type: text/html, Size: 4502 bytes --]