all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Simon Josefsson via <help-guix@gnu.org>
To: help-guix@gnu.org
Subject: authenticating git checkouts
Date: Thu, 09 May 2024 11:28:45 +0200	[thread overview]
Message-ID: <87frurpc4y.fsf@kaka.sjd.se> (raw)

[-- Attachment #1: Type: text/plain, Size: 9326 bytes --]

Hi

I read https://guix.gnu.org/blog/2024/authenticate-your-git-checkouts/
and wondered why I hadn't tried that long ago, but better late than
never, and thanks for writing this blog post to nudge us in the right
direction!

I tried to adopt this approach for the libntlm project, but failed.
Chronological list of first impression thoughts I had:

x) How about introducing an enforcable file-name convention for the key
filenames?  While using human readable names like 'alice.key' looks
nice, it isn't possible to look at content of the filename and determine
what the filename should be.  The filename doesn't appear to convey any
important information, so I think it would be better to have it be
reproducible.  You could use some transliteration of the e-mail address,
but I think there are corner cases here.  So how about merely using the
primary PGP fingerprint value?  For me it would be
B1D2BD1375BECB784CF4F8C4D73CF638C53C06BE.key assuming PGP fingerprints
are specified as case sensitive.

x) How about using ASCII armored PGP blobs instead of binary PGP files
for the *.key files?  While storing binary files in git mostly work
these days, I ran into a CRLF-related problem for a small binary file in
git on Windows lately, so it still seems to happen sometimes.  I tried
this, but it seems 'guix git authenticate' doesn't cope with ASCII
armored PGP keys:

Backtrace:
          12 (primitive-load "/home/jas/.config/guix/current/bin/guix")
In guix/ui.scm:
   2312:7 11 (run-guix . _)
  2275:10 10 (run-guix-command _ . _)
In ice-9/boot-9.scm:
  1752:10  9 (with-exception-handler _ _ #:unwind? _ # _)
  1752:10  8 (with-exception-handler _ _ #:unwind? _ # _)
  1747:15  7 (with-exception-handler #<procedure 7f8d006dc7e0 at ic…> …)
In guix/scripts/git/authenticate.scm:
   309:10  6 (_)
In guix/git-authenticate.scm:
    403:4  5 (authenticate-repository #<git-repository 1ddef20> _ # # …)
In srfi/srfi-1.scm:
   460:18  4 (fold #<procedure 7f8d006feb00 at guix/git-authenticat…> …)
In guix/git-authenticate.scm:
   255:29  3 (_ _ #<<openpgp-keyring> ids: #<vlist ()> fingerprints:…>)
In unknown file:
           2 (open-bytevector-input-port #f #<undefined>)
In ice-9/boot-9.scm:
  1685:16  1 (raise-exception _ #:continuable? _)
  1685:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1685:16: In procedure raise-exception:
In procedure open-bytevector-input-port: Wrong type argument in position 1 (expecting bytevector): #f

x) How about exporting minimal keys rather than keys with a bunch of
signatures on?  This makes the key files a bit more reproducible.  The
downside is that it kills the web-of-trust key authentication process,
so maybe actually recommend NOT using minimal keys?  I'm mixed on this,
and this probably needs more discussion.  Maybe minimizing the keys are
more GDPR-compliant :-)  Doing so also reduces size:

jas@kaka:~/src/libntlm$ gpg --export simon@josefsson.org > jas.key
jas@kaka:~/src/libntlm$ ls -la jas.key 
-rw-rw-r-- 1 jas jas 105243 maj  9 10:28 jas.key
jas@kaka:~/src/libntlm$ gpg --export-options export-minimal --export simon@josefsson.org > jas.key
jas@kaka:~/src/libntlm$ ls -la jas.key 
-rw-rw-r-- 1 jas jas 3534 maj  9 10:28 jas.key
jas@kaka:~/src/libntlm$ 

x) How about support of non-PGP formats?  You could put PGP keys in a
sub-directory pgp/foo.key and allow for future expansion as ssh/bar.key
or x509/baz.key etc.

x) The 'name' field in .guix-authenticate doesn't seem to be necessary
at all?  Maybe not even suggest including it.

x) While using s-exp's for .guix-authenticate are fine, I don't think
this will go down well with the git crowd.  How about a yet another YAML
format a'la git?  Let's call it ~/.gitauthenticate:

gpg-introduction-commit = a94cffff085b17dd72904d8913411e1e85477e12
gpg-introduction-keyid = "B1D2 BD13 75BE CB78 4CF4  F8C4 D73C F638 C53C 06BE"
gpg-keyring-branch = gpg-keyring

This could be extended for ssh and x509 too:

ssh-introduction-commit = a94cffff085b17dd72904d8913411e1e85477e12
ssh-introduction-keyfile = "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAILzCFcHHrKzVSPDDarZPYqn89H5TPaxwcORgRg+4DagE cardno:FFFE42315277"
ssh-keyring-branch = ssh-keyring

x509-introduction-commit = a94cffff085b17dd72904d8913411e1e85477e12
x509-introduction-keyfile = 0xA7C7D7A7
x509-keyring-branch = x509-keyring

and $someone can write a new tool 'git-authenticate'.

x) Running this command:

guix git authenticate 2e6e8027c75942450a0e4ae0f58e876715782cae "B1D2 BD13 75BE CB78 4CF4  F8C4 D73C F638 C53C 06BE"

sets up .git/config properly, but running it again with a different git
commit does not alter .git/config, which was a bit unexpected.  Is this
intentional?  The second invocation exit fine but running 'guix git
authenticate' again failed.  Removing the configuration from .git/config
and re-running both commands made it work, but this feels a bit unsafe.

5) The implementation seems confused by PGP subkeys.  Verifying the
initial commit after adding .guix-authenticate works fine:

jas@kaka:~/src/libntlm$ git log -1 -p 
commit 2e6e8027c75942450a0e4ae0f58e876715782cae (HEAD -> master)
Author: Simon Josefsson <simon@josefsson.org>
Date:   Thu May 9 10:34:15 2024 +0200

    maint: Support guix git authenticate.

diff --git a/.guix-authenticate b/.guix-authenticate
new file mode 100644
index 0000000..94c6df6
--- /dev/null
+++ b/.guix-authenticate
@@ -0,0 +1,3 @@
+(authorizations
+ (version 0)
+ (("B1D2 BD13 75BE CB78 4CF4  F8C4 D73C F638 C53C 06BE"))
jas@kaka:~/src/libntlm$ guix git authenticate
guix git: successfully authenticated commit 2e6e8027c75942450a0e4ae0f58e876715782cae
jas@kaka:~/src/libntlm$ 

however if I make another commit updating README to mention the new way
of working, it stops working:

jas@kaka:~/src/libntlm$ git log -p -1
commit f9102615b9f20b1da87a8d6b406d8a419214892b (HEAD -> master)
Author: Simon Josefsson <simon@josefsson.org>
Date:   Thu May 9 10:44:26 2024 +0200

    maint: Mention guix git introductory commit.

diff --git a/README.md b/README.md
index 0141f03..55982aa 100644
--- a/README.md
+++ b/README.md
@@ -128,6 +128,14 @@ cd libntlm
 Then build it as usual.  See [CONTRIBUTING.md](CONTRIBUTING.md) for
 more information.
 
+You can verify the integrity of the git clone by using [guix git
+authenticate](https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix-git-authenticate.html)
+like this:
+
+```
+guix git authenticate 2e6e8027c75942450a0e4ae0f58e876715782cae "B1D2 BD13 75BE CB78 4CF4  F8C4 D73C F638 C53C 06BE"
+```
+
 # Usage
 
 The application program must convert these structures to/from base64
jas@kaka:~/src/libntlm$ guix git authenticate
Authenticating commits 2e6e802 to f910261 (1 new commits)...
guix git: fel: initial commit 2e6e8027c75942450a0e4ae0f58e876715782cae is signed by 'A3CC 9C87 0B9D 310A BAD4  CF2F 5172 2B08 FE47 45A2' instead of 'B1D2 BD13 75BE CB78 4CF4  F8C4 D73C F638 C53C 06BE'
jas@kaka:~/src/libntlm$ 

I don't want to be signing git commits with my primary key.  I tried to
solve this by specifying the subkey as the trusted .guix-authenticate
key identifier but it didn't work either:

jas@kaka:~/src/libntlm$ git log -p -1
commit a94cffff085b17dd72904d8913411e1e85477e12 (HEAD -> master)
Author: Simon Josefsson <simon@josefsson.org>
Date:   Thu May 9 10:45:44 2024 +0200

    maint: Support guix git authenticate.

diff --git a/.guix-authenticate b/.guix-authenticate
new file mode 100644
index 0000000..132881e
--- /dev/null
+++ b/.guix-authenticate
@@ -0,0 +1,3 @@
+(authorizations
+ (version 0)
+ (("A3CC 9C87 0B9D 310A BAD4  CF2F 5172 2B08 FE47 45A2"))
jas@kaka:~/src/libntlm$ guix git authenticate a94cffff085b17dd72904d8913411e1e85477e12 "A3CC 9C87 0B9D 310A BAD4  CF2F 5172 2B08 FE47 45A2"
guix git: introduction and keyring recorded in repository configuration file
guix git: varning: not overriding pre-existing hooks '/home/jas/src/libntlm/.git/hooks/pre-push' and '/home/jas/src/libntlm/.git/hooks/post-merge'
tips: Consider running `guix git authenticate' from your pre-push and post-merge hooks so your repository is automatically authenticated before you push and when
you pull updates.

guix git: successfully authenticated commit a94cffff085b17dd72904d8913411e1e85477e12
jas@kaka:~/src/libntlm$ guix git authenticate
guix git: successfully authenticated commit a94cffff085b17dd72904d8913411e1e85477e12
jas@kaka:~/src/libntlm$ git commit -m"maint: Mention guix git introductory commit." README.md 
[master 4f64fd9] maint: Mention guix git introductory commit.
 1 file changed, 8 insertions(+)
jas@kaka:~/src/libntlm$ guix git authenticate
Authenticating commits a94cfff to 4f64fd9 (1 new commits)...
▕██████████████████████████████████████████████████████████████████████████████▏guix git: fel: commit 4f64fd94d5e11b0f9226a3e15cae69ef9fdbb585 not signed by an authorized key: A3CC 9C87 0B9D 310A BAD4  CF2F 5172 2B08 FE47 45A2
jas@kaka:~/src/libntlm$ 

I'm using guix --version 9cf0f714636cb9a21875f15c0172211d7def661e.

/Simon

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 255 bytes --]

             reply	other threads:[~2024-05-09  9:29 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-09  9:28 Simon Josefsson via [this message]
2024-05-09  9:41 ` authenticating git checkouts Simon Josefsson via

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87frurpc4y.fsf@kaka.sjd.se \
    --to=help-guix@gnu.org \
    --cc=simon@josefsson.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.