GNU bug report logs -
#70759
[PATCH guix-artwork] website: Add post about ‘guix git authenticate’.
Previous Next
Reported by: Ludovic Courtès <ludo <at> gnu.org>
Date: Fri, 3 May 2024 20:59:01 UTC
Severity: normal
Tags: patch
Done: Ludovic Courtès <ludo <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
Message #20 received at 70759 <at> debbugs.gnu.org (full text, mbox):
Hi,
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.
> 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
This bug report was last modified 1 year and 13 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.