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

[Simon Tournier]

Hi,

On Mon, 6 May 2024 at 17:49, Ludovic Courtès <ludo@gnu.org> wrote:

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

Yes, this wording clarifies the issue of badges.  For what my view is
worth here, I would write: badges acts as a service, as with an
infrastructure as a service or platform as a service.  Else LGTM.


> I hope that clarifies my intention.

Thanks for the clarification.

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

Deal. :-)

Cheers,
simon