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

Previous Next

Full log

Message #25 received at 70759-done <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Simon Tournier <zimon.toutoune <at> gmail.com>
Cc: Tomas Volf <~@wolfsden.cz>, 70759-done <at> debbugs.gnu.org, "pelzflorian
 \(Florian Pelz\)" <pelzflorian <at> pelzflorian.de>,
 Skyler Ferris <skyvine <at> protonmail.com>, guix-blog <at> gnu.org
Subject: Re: bug#70759: [PATCH guix-artwork] website: Add post about
 ‘guix git authenticate’.
Date: Tue, 07 May 2024 14:17:41 +0200

Hi,

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

> On Mon, 6 May 2024 at 17:49, Ludovic Courtès <ludo <at> 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’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.