[bug#70759] [PATCH guix-artwork] website: Add post about ‘guix git authenticate’.

[Simon Tournier <zimon.toutoune@gmail.com>]

Hi Ludo,

On ven., 03 mai 2024 at 22:57, Ludovic Courtès <ludo@gnu.org> wrote:

> +# Why you should care

[...]

>                                   Badges aren’t much better: the presence
> +of a “verified” badge only shows that the commit is signed by the
> +OpenPGP key *currently registered* for the corresponding GitLab/GitHub
> +account.  If you register a new key, or if you leave the project, your
> +commits lose their badge.  Not helpful either, not to mention that this
> +is all tied to the hosting site you’re on, outside of Git’s control.

Well, there is a double-sword here, IMHO.  Because considering the
“keyring” branch approach, it reads: « keys of users who left the
project are necessary to authenticate past commits. »

Therefore, I do not see the problem with badges if you apply the same
constraint: do not remove the keys.  Somehow, I would mitigate this
paragraph.

Other said, the main (and maybe only one) cons against badges is that
the (meta)information does not belong to the Git repository itself but
is registered somewhere in the platform^W service.  And that breaks the
decentralized “claim“, i.e., it forces developer to login in such
services; it locks all contributors in one service.

Somehow, the “keyring” branch approach is about software and “badges” is
about service.  It’s easy to have the control on the former and it’s
much harder to control the latter.


> +# Initial setup

[...]

> +That’s it.  From now on, anyone who clones the repository can
> +authenticate it.  The first time, run:
> +
> +```
> +guix git authenticate COMMIT SIGNER
> +```

This command does not require much Guix, right?  Since the aim of this
post is to convince non-Guix, I would try to extract the Guile code and
have something without the call of “guix”.

If there is a Guile script, named ’git-authenticate’, then any user
putting this script somewhere in PATH would have it.  They would just
run:

   git authenticate COMMIT SIGNER

then it does all the dance. :-)

For sure, there is a maintenance issue; duplicate code, etc.  However,
the call-product would be this autonomous Guile script, infrequently
updated – displaying a HUGE warning and asking to rely on “guix git
authenticate” instead.

I think this strategy would be better if the aim is to reach non-Guix
people. :-)


> +# Interested? You can help!
> +
> +`guix git authenticate` is a great tool that you can start using today
> +so you and fellow co-workers can be sure you’re getting the right code!
> +It solves an important problem that, to my knowledge, hasn’t really been
> +addressed by any other tool.
> +
> +Maybe you’re interested but don’t feel like installing Guix “just” for
> +this tool.  Maybe you’re not into Scheme and Lisp and would rather use a
> +tool written in your favorite language.  Or maybe you think—and
> +rightfully so—that such a tool ought to be part of Git proper.

Hum, I am doing a big cup of coffee, starting loud music in my
headphones and I would do right now what I am proposing above. :-)

Could you wait one or two days before publishing?  I think it could be
nice to come with a Guile script so let me copy/paste some code around.
If there is no news from me, it means: more work than my
constraints. :-)

Cheers,
simon