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

["Ludovic Courtès" <ludo@gnu.org>]

Hi,

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

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

OK, pushed:

  https://guix.gnu.org/en/blog/2024/authenticate-your-git-checkouts/

Thanks for your feedback!

Ludo’.