From unknown Sat Jun 21 10:42:27 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#70759 <70759@debbugs.gnu.org> To: bug#70759 <70759@debbugs.gnu.org> Subject: Status: [PATCH guix-artwork] website: Add post about =?UTF-8?Q?=E2=80=98guix?= git =?UTF-8?Q?authenticate=E2=80=99.?= Reply-To: bug#70759 <70759@debbugs.gnu.org> Date: Sat, 21 Jun 2025 17:42:27 +0000 retitle 70759 [PATCH guix-artwork] website: Add post about =E2=80=98guix gi= t authenticate=E2=80=99. reassign 70759 guix-patches submitter 70759 Ludovic Court=C3=A8s severity 70759 normal tag 70759 patch thanks From debbugs-submit-bounces@debbugs.gnu.org Fri May 03 16:58:43 2024 Received: (at submit) by debbugs.gnu.org; 3 May 2024 20:58:43 +0000 Received: from localhost ([127.0.0.1]:48684 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s2zzO-0007Qg-Hd for submit@debbugs.gnu.org; Fri, 03 May 2024 16:58:43 -0400 Received: from lists.gnu.org ([2001:470:142::17]:42848) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s2zzL-0007QW-9J for submit@debbugs.gnu.org; Fri, 03 May 2024 16:58:40 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s2zyn-0005UE-Ah for guix-patches@gnu.org; Fri, 03 May 2024 16:58:05 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s2zym-00025k-27; Fri, 03 May 2024 16:58:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:Subject:To:From:in-reply-to: references; bh=zmD0NA+tMWls66mlTQVN5DRMRHILz04aVbV/gvsW3Ao=; b=p5m5yFVCp2mP/6 x/WFTWPY6aY5ElIg7DPuQWeSkLoTCCyGeTGIv3i6tOSS/OGpRd2NzcJH+4/TuUQMjpmo/hsRYJ4ea TD3kXEY1HjWU8UleeY+QXOiJLLQf5ggmNa2aRCEy2XZoTYZikEmehh2piZJpgKG3ABJ4BDak+CsMV Mld4RhLEzp0gGtoJLy4tte1mXHM6yH+kUByLVP6arooLf6aItZ1dfuQfwa/C1TjZZ1dSCLJzbh4hU foc+QvbCQ8EVpnCAtw9x2Wumf8zuUxBsqxz8U2bJ39dzSok8nvWgyD3caZbU2pblDfokG7aqvhuM1 CwxXgFUIOAQmxTpydBMg==; From: =?UTF-8?q?Ludovic=20Court=C3=A8s?= To: guix-patches@gnu.org Subject: [PATCH guix-artwork] =?UTF-8?q?website:=20Add=20post=20about=20?= =?UTF-8?q?=E2=80=98guix=20git=20authenticate=E2=80=99.?= Date: Fri, 3 May 2024 22:57:29 +0200 Message-ID: <20240503205729.6354-1-ludo@gnu.org> X-Mailer: git-send-email 2.41.0 X-Debbugs-Cc: guix-blog@gnu.org, Tomas Volf <~@wolfsden.cz>, Skyler Ferris MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: submit Cc: =?UTF-8?q?Ludovic=20Court=C3=A8s?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) * website/posts/git-authenticate.md: New file. --- website/posts/git-authenticate.md | 217 ++++++++++++++++++++++++++++++ 1 file changed, 217 insertions(+) create mode 100644 website/posts/git-authenticate.md Hello Guix! In my quest to make the world a better place *cough* I thought I’d take the recent improvements to ‘guix git authenticate’¹ as an opportunity to spread the word about Git checkout authentication, about the tool, and to send a call for action—I’d love to see someone implement it or a variant thereof for a broader audience. I’d like to publish this blog post in the coming days. Feedback welcome! Thanks, Ludo’. ¹ https://issues.guix.gnu.org/69780 diff --git a/website/posts/git-authenticate.md b/website/posts/git-authenticate.md new file mode 100644 index 0000000..9950b37 --- /dev/null +++ b/website/posts/git-authenticate.md @@ -0,0 +1,217 @@ +title: Authenticate your Git checkouts! +author: Ludovic Courtès +tags: Security, Software development +date: 2024-05-06 14:14 +--- + +You clone a Git repository, then pull from it. How can you tell its +contents are “authentic”—i.e., coming from the “genuine” project you +think you’re pulling from, written by the fine human beings you've been +working with? With commit signatures and “verified” badges ✅ +flourishing, you’d think this has long been solved—but nope! + +Four years after Guix [deployed its own +tool](https://guix.gnu.org/en/blog/2020/securing-updates/) to allow +users to authenticate updates fetched with `guix pull` (which uses Git +under the hood), the situation hasn’t changed all that much: the vast +majority of developers using Git simply do not authenticate the code +they pull. That’s pretty bad. It’s the modern-day equivalent of +sharing unsigned tarballs and packages like we’d blissfully do in the +past century. + +The authentication mechanism Guix uses for +[channels](https://guix.gnu.org/manual/devel/en/html_node/Channels.html) +is available to any Git user through the [`guix git +authenticate`](https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix-git-authenticate.html) +command. This post is a guide for Git users who are not necessarily +Guix users but are interested in using this command for their own +repositories. Before looking into the command-line interface and how we +improved it to make it more convenient, let’s dispel any +misunderstandings or misconceptions. + +# Why you should care + +When you run `git pull`, you’re fetching a bunch of commits from a +server. If it’s over HTTPS, you’re authenticating *the server* itself, +which is nice, but that does not tell you who the code actually comes +from—the server might be compromised and an attacker pushed code to the +repository. Not helpful. At all. + +But hey, maybe you think you’re good because everyone on your project is +signing commits and tags, and because you’re disciplined, you routinely +run `git log --show-signature` and check those “Good signature” GPG +messages. Maybe you even have those fancy “✅ verified” badges as found +[on +GitLab](https://docs.gitlab.com/ee/user/project/repository/signed_commits/gpg.html) +and [on +GitHub](https://docs.github.com/en/authentication/managing-commit-signature-verification). + +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. 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. + +Being able to ensure that when you run `git pull`, you’re getting code +that _genuinely_ comes from authorized developers of the project is +basic security hygiene. Obviously it cannot protect against efforts to +infiltrate a project to eventually get commit access and insert +malicious code—the kind of multi-year plot that led to the [xz +backdoor](https://tukaani.org/xz-backdoor/)—but if you don’t even +protect against unauthorized commits, then all bets are off. + +Authentication is something we naturally expect from `apt update`, +`pip`, `guix pull`, and similar tools; why not treat `git pull` to the +same standard? + +# Initial setup + +The [`guix git +authenticate`](https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix-git-authenticate.html) +command authenticates Git checkouts, unsurprisingly. It’s currently +part of Guix because that’s where it was brought to life, but it can be +used on any Git repository. This section focuses on how to use it; you +can learn about the motivation, its design, and its implementation in +[the 2020 blog +post](https://guix.gnu.org/en/blog/2020/securing-updates/), in the 2022 +peer-reviewed academic paper entitled [_Building a Secure Software +Supply Chain with +GNU Guix_](https://doi.org/10.22152/programming-journal.org/2023/7/1), +or in this 20mn +[presentation](https://archive.fosdem.org/2023/schedule/event/security_where_does_that_code_come_from/). + +To support authentication of your repository with `guix git +authenticate`, you need to follow these steps: + + 0. Enable commit signing on your repo: `git config commit.gpgSign + true`. (Git now supports other signing methods but here we need + OpenPGP signatures.) + + 1. Create a `keyring` branch containing all the OpenPGP keys of all + the committers, along these lines: + + ``` + git checkout --orphan keyring + git reset --hard + gpg --export alice@example.org > alice.key + … + git add *.key + git commit -a -m "Add committer keys." + ``` + + All the files must end in `.key`. You must never remove keys from + that branch: keys of users who left the project are necessary to + authenticate past commits. + + 2. Back to the main branch, add a `.guix-authorizations` file, listing + the OpenPGP keys of authorized committers—we’ll get back to its + format below. + + 3. Commit! This becomes the _introductory commit_ from which + authentication can proceed. The _introduction_ of your repository + is the ID of this commit and the OpenPGP fingerprint of the key + used to sign it. + +That’s it. From now on, anyone who clones the repository can +authenticate it. The first time, run: + +``` +guix git authenticate COMMIT SIGNER +``` + +… where `COMMIT` is the commit ID of the introductory commit, and +`SIGNER` is the OpenPGP fingerprint of the key used to sign that commit +(make sure to enclose it in double quotes if there are spaces!). As a +repo maintainer, you must advertise this introductory commit ID and +fingerprint on a web page or in a `README` file so others know what to +pass to `guix git authenticate`. + +The commit and signer are now recorded on the first run in +`.git/config`; next time, you can run it without any arguments: + +``` +guix git authenticate +``` + +The other new feature is that the first time you run it, the command +installs *pre-push and pre-merge hooks* (unless preexisting hooks are +found) such that your repository is automatically authenticated from +there on every time you run `git pull` or `git push`. + +`guix git authenticate` exits with a non-zero code and an error message +when it stumbles upon a commit that lacks a signature, that is signed by +a key not in the `keyring` branch, or that is signed by a key not listed +in `.guix-authorizations`. + +# Maintaining the list of authorized committers + +The `.guix-authorizations` file in the repository is central: it lists +the OpenPGP fingerprints of authorized committers. Any commit that is +*not* signed by a key listed in the `.guix-authorizations` file of its +parent commit(s) is considered inauthentic—and an error is reported. +The [format of +`.guix-authorizations`](https://guix.gnu.org/manual/devel/en/html_node/Specifying-Channel-Authorizations.html#channel_002dauthorizations) +is based on [S-expressions](https://en.wikipedia.org/wiki/S-expression) +and looks like this: + +```scheme +;; Example '.guix-authorizations' file. + +(authorizations + (version 0) ;current file format version + + (("AD17 A21E F8AE D8F1 CC02 DBD9 F8AE D8F1 765C 61E3" + (name "alice")) + ("2A39 3FFF 68F4 EF7A 3D29 12AF 68F4 EF7A 22FB B2D5" + (name "bob")) + ("CABB A931 C0FF EEC6 900D 0CFB 090B 1199 3D9A EBB5" + (name "charlie")))) +``` + +The `name` bits are hints and do not have any effect; what matters is +the fingerprints that are listed. You can obtain them with GnuPG by +running commands like: + +``` +gpg --fingerprint charlie@example.org +``` + +At any time you can add or remove keys from `.guix-authorizations` and +commit the changes; those changes take effect for child commits. For +example, if we add Billie’s fingerprint to the file in commit _A_, then +Billie becomes an authorized committer in *descendants* of commit _A_ +(we must make sure to add Billie’s key as a file in the `keyring` +branch, too, as we saw above); Billie is still unauthorized in branches +that lack _A_. If we remove Charlie’s key from the file in commit _B_, +then Charlie is no longer an authorized committer, except in branches +that start before _B_. This should feel rather natural. + +That’s pretty much all you need to know to get started! [Check the +manual](https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix-git-authenticate.html) +for more info. + +All the information needed to authenticate the repository is contained +in the repository itself—it does not depend on a forge or key server. +That’s a good property to allow anyone to authenticate it, to ensure +determinism and transparency, and to avoid lock-in. + +# Interested? You can help! + +`guix git authenticate` is a great tool that you can start using today +so you and fellow co-workers can be sure you’re getting the right code! +It solves an important problem that, to my knowledge, hasn’t really been +addressed by any other tool. + +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. + +That’s OK, we can talk! We’re open to discussing with folks who’d like +to come up with alternative implementations—check out the articles +mentioned above if you’d like to take that route. And we’re open to +contributing to a standardization effort. Let’s [get in +touch](https://guix.gnu.org/contact/)! base-commit: a4153e25c8fc37920a56330a60734f4205f3dcb0 -- 2.41.0 From debbugs-submit-bounces@debbugs.gnu.org Sat May 04 09:29:06 2024 Received: (at 70759) by debbugs.gnu.org; 4 May 2024 13:29:06 +0000 Received: from localhost ([127.0.0.1]:53723 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s3FRp-0000OE-Vh for submit@debbugs.gnu.org; Sat, 04 May 2024 09:29:06 -0400 Received: from relay.yourmailgateway.de ([46.38.247.119]:33873) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s3FRj-0000Nz-PJ for 70759@debbugs.gnu.org; Sat, 04 May 2024 09:29:04 -0400 Received: from mors-relay-8404.netcup.net (localhost [127.0.0.1]) by mors-relay-8404.netcup.net (Postfix) with ESMTPS id 4VWpQq1xBRz80Wk; Sat, 4 May 2024 15:28:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=pelzflorian.de; s=key2; t=1714829315; bh=nGFG2B1oUhes42wTBtchB/XYZqKH6zpulKimFnDq8a0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=RHOgYcfELmJtwLCkx6dQTD696vduj87+0CW4dcvZqT/xU9eaP+ReD79YTJrEE/Yj+ sq1r7z07p6OPFKzbF9imT6+OUyzezOVPzLTebujNWpnRjiISe5r/nMvlAqW2ew4Cvn UVTe9Pz93AXRW1jWB62O8SBuknS6RKPrdE4/BCp+e+jbZwaxwFrQs99GBDlYwaTPO+ 58VEvVWBqxTd0tu1bjRqvnWDFpNnmc5eZA3BivdV0DGn0vo8Fe4H1tKItYC8c3lw+e ejerdF2gpjMCwxmOqe+oUKg/rLl2m+VA31bVFmyz3O2Zl799V4zuoEu4KLyLM2f8Aj LGEB4CymhUdAg== Received: from policy02-mors.netcup.net (unknown [46.38.225.35]) by mors-relay-8404.netcup.net (Postfix) with ESMTPS id 4VWpQq1YZ7z4x8f; Sat, 4 May 2024 15:28:35 +0200 (CEST) Received: from mxe217.netcup.net (unknown [10.243.12.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by policy02-mors.netcup.net (Postfix) with ESMTPS id 4VWpQp5nfXz8svC; Sat, 4 May 2024 15:28:34 +0200 (CEST) Received: from florianrock64 (ipb2186896.dynamic.kabel-deutschland.de [178.24.104.150]) by mxe217.netcup.net (Postfix) with ESMTPSA id 30E5583AAA; Sat, 4 May 2024 15:28:26 +0200 (CEST) From: "pelzflorian (Florian Pelz)" To: Ludovic =?utf-8?Q?Court=C3=A8s?= Subject: Re: [bug#70759] [PATCH guix-artwork] website: Add post about =?utf-8?Q?=E2=80=98guix?= git =?utf-8?Q?authenticate=E2=80=99=2E?= In-Reply-To: <20240503205729.6354-1-ludo@gnu.org> ("Ludovic =?utf-8?Q?Cour?= =?utf-8?Q?t=C3=A8s=22's?= message of "Fri, 3 May 2024 22:57:29 +0200") References: <20240503205729.6354-1-ludo@gnu.org> Date: Sat, 04 May 2024 15:28:24 +0200 Message-ID: <87jzk91zbb.fsf@pelzflorian.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 30E5583AAA X-Rspamd-Server: rspamd-worker-8404 X-NC-CID: m+sCyCJP29yXheDwnk9Wh34mXN/5hH7B6wgkFsWmZ61/P348nLJ4b5pE X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 70759 Cc: 70759@debbugs.gnu.org, Tomas Volf <~@wolfsden.cz>, guix-blog@gnu.org, Skyler Ferris X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hi Ludo and thank you for the tool and this presentation of it! It is all well-written. I only notice that there are typewriter apostrophes like =E2=80=9Cyou've=E2=80=9D mixed with typographic apostrophe= s =E2=80=9Cyou=E2=80=99d=E2=80=9D. Ludovic Court=C3=A8s writes: > +# Why you should care It is good how this lists all the concepts that are insufficient. :) I think the explanations suffice. However I hesitate here: > + ``` > + git checkout --orphan keyring > + git reset --hard > + gpg --export alice@example.org > alice.key > + =E2=80=A6 > + git add *.key > + git commit -a -m "Add committer keys." Why the -a? Regards, Florian From debbugs-submit-bounces@debbugs.gnu.org Sun May 05 12:31:52 2024 Received: (at 70759) by debbugs.gnu.org; 5 May 2024 16:31:52 +0000 Received: from localhost ([127.0.0.1]:60549 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s3emE-0001TC-7l for submit@debbugs.gnu.org; Sun, 05 May 2024 12:31:51 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:59314) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s3em8-0001T4-9S for 70759@debbugs.gnu.org; Sun, 05 May 2024 12:31:48 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s3elb-0002vE-Ed; Sun, 05 May 2024 12:31:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=5t5RCcaEOWxcb4xq3X4cAiE3b9VHgNITNFobv/XiIfk=; b=I7WcqmpDaiCVykGWJkNi VQQp6LNGvjLM1L5tLil4hrQuFz2R+oG8u3JY3Bjn8/O16avR/697P2fusp42UqZD+CM0umtZQ9QFG iW9Ba05W4u+k0UIk5UyM12zBqh1edLAZNT8Rfg2pdXTLCT6/Sj1bT5zmvBjAEAlqRanf+5LAFN3e3 l8n1q4+TThpDZ47XRpRckCq6i4v/0ezB2kAEj7xz3/E7ORvTpyOIHVQZOxkGgemd51R0ZHfksslD5 LIm00x8968QBwdM4bt4KhmQrwmeXE+qobYI1stucQeIUeVw/UVg5Deu9d2Bw33y+fTBbwEFlao9gm zHc13ZzJl/xyPA==; From: =?utf-8?Q?Ludovic_Court=C3=A8s?= To: "pelzflorian (Florian Pelz)" Subject: Re: bug#70759: [PATCH guix-artwork] website: Add post about =?utf-8?Q?=E2=80=98guix?= git =?utf-8?Q?authenticate=E2=80=99=2E?= In-Reply-To: <87jzk91zbb.fsf@pelzflorian.de> (pelzflorian@pelzflorian.de's message of "Sat, 04 May 2024 15:28:24 +0200") References: <20240503205729.6354-1-ludo@gnu.org> <87jzk91zbb.fsf@pelzflorian.de> Date: Sun, 05 May 2024 18:31:07 +0200 Message-ID: <87zft4qkz8.fsf_-_@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 70759 Cc: 70759@debbugs.gnu.org, Tomas Volf <~@wolfsden.cz>, guix-blog@gnu.org, Skyler Ferris X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Hi Florian, "pelzflorian (Florian Pelz)" skribis: > It is all well-written. I only notice that there are typewriter > apostrophes like =E2=80=9Cyou've=E2=80=9D mixed with typographic apostrop= hes =E2=80=9Cyou=E2=80=99d=E2=80=9D. Oops! Fixed locally. > Ludovic Court=C3=A8s writes: >> +# Why you should care > > It is good how this lists all the concepts that are insufficient. :) > I think the explanations suffice. Great, I=E2=80=99m glad it makes sense. There seems to be a common percept= ion that =E2=80=9Cthere=E2=80=99s no problem=E2=80=9D so if this section manage= s to dispel that myth, that=E2=80=99s good. > However I hesitate here: > >> + ``` >> + git checkout --orphan keyring >> + git reset --hard >> + gpg --export alice@example.org > alice.key >> + =E2=80=A6 >> + git add *.key >> + git commit -a -m "Add committer keys." > > Why the -a? Oh you=E2=80=99re right, it=E2=80=99s unnecessary. Removed! Thanks for the quick feedback! Ludo=E2=80=99. From debbugs-submit-bounces@debbugs.gnu.org Mon May 06 05:40:19 2024 Received: (at 70759) by debbugs.gnu.org; 6 May 2024 09:40:19 +0000 Received: from localhost ([127.0.0.1]:36819 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s3upX-0007Jt-3b for submit@debbugs.gnu.org; Mon, 06 May 2024 05:40:19 -0400 Received: from mail-wm1-x330.google.com ([2a00:1450:4864:20::330]:41918) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s3upS-0007Jk-KE for 70759@debbugs.gnu.org; Mon, 06 May 2024 05:40:17 -0400 Received: by mail-wm1-x330.google.com with SMTP id 5b1f17b1804b1-41bd8bdd065so2379665e9.3 for <70759@debbugs.gnu.org>; Mon, 06 May 2024 02:39:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1714988384; x=1715593184; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=U5VlmXCtttaHT/zTp6TqGokjY0EF494ogvu3+p2A7lk=; b=Mo7ECFDYdrLIVHPJScLxSLJl5a8/hJ4dD1aME84kM9lDUJcytwmhvXBJGbCkvZZunY 4oqHuvluNch6qk0D6bhOIfx6EbLma26ChtyLmC181ArR3Q36bQOKyZ7+2EFKX8X57KOQ D8CSRE+aAhMAXY1+7MPNINakHrQxketTj3/MVTMwO+vfxcpx27C1H+vhr1Mp5pRihhPq 4IC6COtduwXjU39H5EwLTLkj6F8iBeGrNL4n+dzjjDA9cN6Lpch27g2oaZcQcoWEUzdC RKKT7avndrwOA9mWy0iY8ptymWftM7nWtQlc+1CW6TTGKF5Jj264Fv6JO8KZNlpXMf51 wAcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714988384; x=1715593184; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=U5VlmXCtttaHT/zTp6TqGokjY0EF494ogvu3+p2A7lk=; b=aFqfLh5XFqBbEy+gz/7x59uG7bHiwu7H2d5R8nZ6MoCgiAYZFJBRL2R+Jk52ifgBht p/04g0Zxw07v+60WZwz1Isu4gq2eJ8PV2FLyZJ0nlPh5IK4q43yTyHWfM5TUZWz+Vray hJsDfiz9chVOgZIlfB8LOrH/bBKDYQmcZsk1dtKaEQZuoXfcl0JO1lHgAZtUZpZFvNRf AmYdxmPJhjdne8KAMsEPr6XY2qZzylvdUSluq2bcgLmjfHJWQZlp4is4chPSgScvbcgr 2JhQtOHe17r9BNZtzXqv2fOKSG+Ri0JLmUsRPzZ9tdZdvnPLoGbJyOnU3FNY0UvOUNBL GL1g== X-Gm-Message-State: AOJu0YyS46ytn/Q6tn9ZHUNFZER4E723XybsPtKdzU8QC3GS1fYSbWPG dE9v8knSypNGKGh/x30fntKGgJNujoqc5Fo6FhANFmDj9UoIGvp3 X-Google-Smtp-Source: AGHT+IEWFeAmiIIo6LVNZOJf1LJSgiYhFvMWWQHbv+yNJUBpLr6mWio1rPKj8qtU9CT9QQwuSDkklg== X-Received: by 2002:a5d:6b81:0:b0:34d:9d4c:53ec with SMTP id n1-20020a5d6b81000000b0034d9d4c53ecmr7241322wrx.5.1714988384392; Mon, 06 May 2024 02:39:44 -0700 (PDT) Received: from pfiuh07 ([193.48.40.241]) by smtp.gmail.com with ESMTPSA id i15-20020adfb64f000000b0034af40b2efdsm10232758wre.108.2024.05.06.02.39.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 May 2024 02:39:43 -0700 (PDT) From: Simon Tournier To: Ludovic =?utf-8?Q?Court=C3=A8s?= Subject: Re: bug#70759: [PATCH guix-artwork] website: Add post about =?utf-8?Q?=E2=80=98guix?= git =?utf-8?Q?authenticate=E2=80=99=2E?= In-Reply-To: <20240503205729.6354-1-ludo@gnu.org> ("Ludovic =?utf-8?Q?Cour?= =?utf-8?Q?t=C3=A8s=22's?= message of "Fri, 3 May 2024 22:57:29 +0200") References: <20240503205729.6354-1-ludo@gnu.org> Date: Mon, 06 May 2024 11:39:39 +0200 Message-ID: <87fruvl1no.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 70759 Cc: 70759@debbugs.gnu.org, Tomas Volf <~@wolfsden.cz>, guix-blog@gnu.org, Skyler Ferris X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hi Ludo, On ven., 03 mai 2024 at 22:57, Ludovic Court=C3=A8s wrote: > +# Why you should care [...] > Badges aren=E2=80=99t much better: the = presence > +of a =E2=80=9Cverified=E2=80=9D badge only shows that the commit is sign= ed 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=E2=80=99re on, outside of Git=E2=80= =99s control. Well, there is a double-sword here, IMHO. Because considering the =E2=80=9Ckeyring=E2=80=9D branch approach, it reads: =C2=AB keys of users w= ho left the project are necessary to authenticate past commits. =C2=BB 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. 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 =E2=80=9Cclaim=E2=80=9C, i.e., it forces developer to login i= n such services; it locks all contributors in one service. Somehow, the =E2=80=9Ckeyring=E2=80=9D branch approach is about software an= d =E2=80=9Cbadges=E2=80=9D is about service. It=E2=80=99s easy to have the control on the former and it= =E2=80=99s much harder to control the latter. > +# Initial setup [...] > +That=E2=80=99s 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? 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 =E2=80=9Cguix=E2=80=9D. If there is a Guile script, named =E2=80=99git-authenticate=E2=80=99, then = any user putting this script somewhere in PATH would have it. They would just run: git authenticate COMMIT SIGNER then it does all the dance. :-) For sure, there is a maintenance issue; duplicate code, etc. However, the call-product would be this autonomous Guile script, infrequently updated =E2=80=93 displaying a HUGE warning and asking to rely on =E2=80=9C= guix git authenticate=E2=80=9D instead. I think this strategy would be better if the aim is to reach non-Guix people. :-) > +# Interested? You can help! > + > +`guix git authenticate` is a great tool that you can start using today > +so you and fellow co-workers can be sure you=E2=80=99re getting the righ= t code! > +It solves an important problem that, to my knowledge, hasn=E2=80=99t rea= lly been > +addressed by any other tool. > + > +Maybe you=E2=80=99re interested but don=E2=80=99t feel like installing G= uix =E2=80=9Cjust=E2=80=9D for > +this tool. Maybe you=E2=80=99re not into Scheme and Lisp and would rath= er use a > +tool written in your favorite language. Or maybe you think=E2=80=94and > +rightfully so=E2=80=94that 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. :-) Cheers, simon From debbugs-submit-bounces@debbugs.gnu.org Mon May 06 11:50:07 2024 Received: (at 70759) by debbugs.gnu.org; 6 May 2024 15:50:07 +0000 Received: from localhost ([127.0.0.1]:38773 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s40bO-0006FY-JW for submit@debbugs.gnu.org; Mon, 06 May 2024 11:50:07 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:35468) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s40bJ-0006F6-2K for 70759@debbugs.gnu.org; Mon, 06 May 2024 11:50:04 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s40ak-00044Q-P4; Mon, 06 May 2024 11:49:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=QL67bHtDJJ/sUQAk8NFRdh1l5TTYXJ73lxOX8sXXlxE=; b=r4kqP6d1BlHq5O2vK0HH IS2d2WbMIvlaTJzIna9xpkGb5g0VdYodnhzU+QvELAj655vAhGIDcWmoZTtXsSjYbnwobbCdWSxBH ldPX2f2mWVL1pRNfNBLJm7Z7+niMh2fEDd4G3lsBVlWCl5ASVTCOIqlDSzZrrIDOSmoPAFmeTB/P+ q0ST69QkZ+b11/OTpwaw4pxbsQNqEzWhsqr4xU2axWmKJvaZ+WHtZOOmIJX1c1kmqu9jnaDiejTZ0 ClPR8ZvWe/josuZwICuxzrfQrrQX4K4vTDaYZw89i6bUL7TBgkN2os6Onow8ZxFwvKlUbdvEiVsx0 3+GqjO3iWFlE9Q==; From: =?utf-8?Q?Ludovic_Court=C3=A8s?= To: Simon Tournier Subject: Re: bug#70759: [PATCH guix-artwork] website: Add post about =?utf-8?Q?=E2=80=98guix?= git =?utf-8?Q?authenticate=E2=80=99=2E?= In-Reply-To: <87fruvl1no.fsf@gmail.com> (Simon Tournier's message of "Mon, 06 May 2024 11:39:39 +0200") References: <20240503205729.6354-1-ludo@gnu.org> <87fruvl1no.fsf@gmail.com> X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: Octidi 18 =?utf-8?Q?Flor=C3=A9al?= an 232 de la =?utf-8?Q?R=C3=A9volution=2C?= jour de la Corbeille-d'or X-PGP-Key-ID: 0x090B11993D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-pc-linux-gnu Date: Mon, 06 May 2024 17:49:19 +0200 Message-ID: <87le4nhreo.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 70759 Cc: 70759@debbugs.gnu.org, Tomas Volf <~@wolfsden.cz>, "pelzflorian \(Florian Pelz\)" , guix-blog@gnu.org, Skyler Ferris X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Hi Simon, Simon Tournier skribis: > On ven., 03 mai 2024 at 22:57, Ludovic Court=C3=A8s wrote: > >> +# Why you should care > > [...] > >> Badges aren=E2=80=99t much better: the= presence >> +of a =E2=80=9Cverified=E2=80=9D badge only shows that the commit is sig= ned 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=E2=80=99re on, outside of Git=E2=80= =99s control. > > Well, there is a double-sword here, IMHO. Because considering the > =E2=80=9Ckeyring=E2=80=9D branch approach, it reads: =C2=AB keys of users= who left the > project are necessary to authenticate past commits. =C2=BB > > 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 =E2=80=9Cclaim=E2=80=9C, i.e., it forces developer to login= in such > services; it locks all contributors in one service. > > Somehow, the =E2=80=9Ckeyring=E2=80=9D branch approach is about software = and =E2=80=9Cbadges=E2=80=9D is > about service. It=E2=80=99s easy to have the control on the former and i= t=E2=80=99s > 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=E2=80=99s not just about lock-in but also about semantics: Signing commits is part of the solution, but it=E2=80=99s not enough to _authenticate_ a set of commits that you pull; all it shows is that, well, those commits are signed. Badges aren=E2=80=99t much better: the p= resence of a =E2=80=9Cverified=E2=80=9D badge only shows that the commit is signe= d by the OpenPGP key *currently registered* for the corresponding GitLab/GitHub account. It=E2=80=99s another source of lock-in and makes the hosting pl= atform a trusted third-party. Worse, there=E2=80=99s no notion of authorization= (which keys are authorized), let alone tracking of the history of authorization changes. Not helpful. Does that clarify things? >> +That=E2=80=99s 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 =E2=80=9Cgu= ix=E2=80=9D. 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=E2=80=99re interested but don=E2=80=99t feel like installing = Guix =E2=80=9Cjust=E2=80=9D for >> +this tool. Maybe you=E2=80=99re not into Scheme and Lisp and would rat= her use a >> +tool written in your favorite language. Or maybe you think=E2=80=94and >> +rightfully so=E2=80=94that 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=E2=80=99t think we should hold on until the work has been d= one; like I wrote, that=E2=80=99s 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=E2=80=99s now at least one standalone tool for= you. :-) Thanks, Ludo=E2=80=99. From debbugs-submit-bounces@debbugs.gnu.org Mon May 06 12:27:27 2024 Received: (at 70759) by debbugs.gnu.org; 6 May 2024 16:27:27 +0000 Received: from localhost ([127.0.0.1]:38936 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s41BX-0006em-1g for submit@debbugs.gnu.org; Mon, 06 May 2024 12:27:27 -0400 Received: from mail-qv1-xf2c.google.com ([2607:f8b0:4864:20::f2c]:40625) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s41BV-0006ee-3w for 70759@debbugs.gnu.org; Mon, 06 May 2024 12:27:25 -0400 Received: by mail-qv1-xf2c.google.com with SMTP id 6a1803df08f44-6a0f5765069so4533246d6.2 for <70759@debbugs.gnu.org>; Mon, 06 May 2024 09:27:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1715012815; x=1715617615; darn=debbugs.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=wkkAGsdClTsoeZGEu7ZtvHK5REc6rd7MkW6CPqEA6+s=; b=UpA9CgPsZKLNHC/1osP+cRp3PydzNTMjZYE/meCH0qHXJ/IW/7byAK/dfr9BvVb49B FczEZfx6CXyusoNFY6sRB7OCt0D7CjBALHNgn0eA8d9R/iwdjGEkv29HPJZ09CYl9Wfu Z5gzXNHhDd+swGKbQS1Ar037851X6D0ttiHPnVK8WbjQmd/+nti2VDuZmnjS2qFpiR7U rg6AemG4VPuL4ZRF/XWkJr7emrlF3tVkK8aBoa3LIKUtPi8Nh16GdOVlarpc4OMsWAGx cjX1urmn0Kvl8xllXObZKGYFRH2sKZZHSvIDGg9t3r4JTwk9f1TEDUgGOVzDknUSZRE7 dMLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715012815; x=1715617615; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=wkkAGsdClTsoeZGEu7ZtvHK5REc6rd7MkW6CPqEA6+s=; b=PI4r/Hifz4tJmwaTpQs9ko2vMP/9LyNiARUpwagRhOsjZeZ8mhp8pPJafv5rYLBWSN OEmKMbd4GxAOWCdvRvpmRw8+aF8IGFmM5v4nYXptA/Fq0MVuW45TTbKcG/NM2q9VNe6N xw4ymri3v1wErLYdO+ba6K1ORuNfQaQuIL4wlcahJIK57aRJk43UvmiGQPEApCY06Ufc 7FCRLCgr7YA4FBjsCbBrFALw/o47SP1nbc1+RLQVoQP6xXGKCOnv6uMQe+Ov1xjxuTzC pBE3hxdcnWMenk0dGZh+KlpHvX/vzCBfp72e2VhitCz5IYHxyaPQMoKYAPclP5i4FT1e Znrg== X-Gm-Message-State: AOJu0YxX9NgvKcaCrt6ZkyE1mq1w0Xm/6zbwdyFkYcgEtvMOdCDGbK5I lyD4585nsD8wVpbB7/tBKU1c0/dSjnZF5I/kRdieMiOfPGc/5VsRUrYfZAJNsdhVChJkl0udm0y e5S5KCfAFOpxiRW62SQtPctwsn80= X-Google-Smtp-Source: AGHT+IFip29GhZVkaQR1L8HJbkfBwZs1OASOhBflcuY8Hqu8HqbCOEPv8RMGdCt9uQIdyFB3oYnSejZHBLQDk1Y2m9I= X-Received: by 2002:ad4:5c89:0:b0:6a0:71c2:e929 with SMTP id o9-20020ad45c89000000b006a071c2e929mr12777332qvh.1.1715012814880; Mon, 06 May 2024 09:26:54 -0700 (PDT) MIME-Version: 1.0 References: <20240503205729.6354-1-ludo@gnu.org> <87fruvl1no.fsf@gmail.com> <87le4nhreo.fsf@gnu.org> In-Reply-To: <87le4nhreo.fsf@gnu.org> From: Simon Tournier Date: Mon, 6 May 2024 18:26:41 +0200 Message-ID: Subject: =?UTF-8?Q?Re=3A_bug=2370759=3A_=5BPATCH_guix=2Dartwork=5D_website=3A_Add_pos?= =?UTF-8?Q?t_about_=E2=80=98guix_git_authenticate=E2=80=99=2E?= To: =?UTF-8?Q?Ludovic_Court=C3=A8s?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 70759 Cc: 70759@debbugs.gnu.org, Tomas Volf <~@wolfsden.cz>, "pelzflorian \(Florian Pelz\)" , guix-blog@gnu.org, Skyler Ferris X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hi, On Mon, 6 May 2024 at 17:49, Ludovic Court=C3=A8s wrote: > I tried to reword it in a way similar to what I did in the Programming > paper to clarify that it=E2=80=99s not just about lock-in but also about > semantics: > > Signing commits is part of the solution, but it=E2=80=99s not enough to > _authenticate_ a set of commits that you pull; all it shows is that, > well, those commits are signed. Badges aren=E2=80=99t much better: the= presence > of a =E2=80=9Cverified=E2=80=9D badge only shows that the commit is sig= ned by the > OpenPGP key *currently registered* for the corresponding GitLab/GitHub > account. It=E2=80=99s another source of lock-in and makes the hosting = platform > a trusted third-party. Worse, there=E2=80=99s no notion of authorizati= on (which > keys are authorized), let alone tracking of the history of authorizatio= n > 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=E2=80=99s now at least one standalone tool f= or you. > :-) Deal. :-) Cheers, simon From debbugs-submit-bounces@debbugs.gnu.org Tue May 07 08:18:23 2024 Received: (at 70759-done) by debbugs.gnu.org; 7 May 2024 12:18:23 +0000 Received: from localhost ([127.0.0.1]:42580 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s4Jm3-0003k7-71 for submit@debbugs.gnu.org; Tue, 07 May 2024 08:18:23 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:46858) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s4Jm0-0003jW-PW for 70759-done@debbugs.gnu.org; Tue, 07 May 2024 08:18:21 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s4JlT-0001U6-DA; Tue, 07 May 2024 08:17:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=v4Io88uw35CghcxPNll2yu0/Rukxj2F8ys9454Ryp/Y=; b=jxN7ffARhT6wqBt2PH/5 Rt+firFb+EhxsUe281WNwcRImfIFSEhCyLq8HiUI/vDaqYGen7qfvjTjkqlYC1adjf0C1KaxVLT/b xeYmvWBce/TrxiS2PU+TSrEFl34FMaldYcYO73eo+wmUMzAgP8C15/9Xt/AvxNbINpz9EYCH36agF N9BwGCgPogOcvUegrbZ8XY/NcO9Ob66oiyFy/LKMJBENW0S9zt46xtG4sbcqQ1DWCfCIledjclpt4 OUonPeK0SIqXmqlHAIkmS/AWKHPrNuF5FFFLf95ddRufFB3XduHWHwIc9BA3/yUK6XoC8jQI6hgXq 48N/jMg90+wDng==; From: =?utf-8?Q?Ludovic_Court=C3=A8s?= To: Simon Tournier Subject: Re: bug#70759: [PATCH guix-artwork] website: Add post about =?utf-8?Q?=E2=80=98guix?= git =?utf-8?Q?authenticate=E2=80=99=2E?= In-Reply-To: (Simon Tournier's message of "Mon, 6 May 2024 18:26:41 +0200") References: <20240503205729.6354-1-ludo@gnu.org> <87fruvl1no.fsf@gmail.com> <87le4nhreo.fsf@gnu.org> Date: Tue, 07 May 2024 14:17:41 +0200 Message-ID: <87msp17r4q.fsf_-_@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 70759-done Cc: Tomas Volf <~@wolfsden.cz>, 70759-done@debbugs.gnu.org, "pelzflorian \(Florian Pelz\)" , Skyler Ferris , guix-blog@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Hi, Simon Tournier skribis: > On Mon, 6 May 2024 at 17:49, Ludovic Court=C3=A8s wrote: > >> I tried to reword it in a way similar to what I did in the Programming >> paper to clarify that it=E2=80=99s not just about lock-in but also about >> semantics: >> >> Signing commits is part of the solution, but it=E2=80=99s not enough to >> _authenticate_ a set of commits that you pull; all it shows is that, >> well, those commits are signed. Badges aren=E2=80=99t much better: th= e presence >> of a =E2=80=9Cverified=E2=80=9D badge only shows that the commit is si= gned by the >> OpenPGP key *currently registered* for the corresponding GitLab/GitHub >> account. It=E2=80=99s another source of lock-in and makes the hosting= platform >> a trusted third-party. Worse, there=E2=80=99s no notion of authorizat= ion (which >> keys are authorized), let alone tracking of the history of authorizati= on >> 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=E2=80=99. From unknown Sat Jun 21 10:42:27 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Wed, 05 Jun 2024 11:24:09 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator