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

[Ludovic Courtès]

Hi Simon,

Simon Tournier <zimon.toutoune@gmail.com> skribis:

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

If you do not see the problem with badges, then this paragraph might
need to be revisited!

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

Thanks for explaining.

I tried to reword it in a way similar to what I did in the Programming
paper to clarify that it’s not just about lock-in but also about
semantics:

  Signing commits is part of the solution, but it’s not enough to
  _authenticate_ a set of commits that you pull; all it shows is that,
  well, those commits are signed.  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.  It’s another source of lock-in and makes the hosting platform
  a trusted third-party.  Worse, there’s no notion of authorization (which
  keys are authorized), let alone tracking of the history of authorization
  changes.  Not helpful.

Does that clarify things?

>> +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?

Technically it requires quite a bit.

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

As I see it, the aim of the post is to invite interested parties to
either extract the relevant Guile code from Guix (this is quite a bit of
work and there are technico-social issues to solve) or to write their
own.

I did not intend to do that work before publishing the post; quite the
opposite.

I hope that clarifies my intention.

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

Yes well, I don’t think we should hold on until the work has been done;
like I wrote, that’s precisely the purpose of this post.

Now, if you get it done, you have my recognition *and* we can post a
followup saying: look, there’s now at least one standalone tool for you.
:-)

Thanks,
Ludo’.