authenticating git checkouts

authenticating git checkouts

[Simon Josefsson via]

[-- 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 --]

Re: authenticating git checkouts

[Simon Josefsson via]

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

Simon Josefsson via <help-guix@gnu.org> writes:

> 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 forgot to show git log output here, proving that this git commit was
actually signed: see below.  I suspect there is some primary vs subkey
confusion, but maybe it could be some parsing issue?  I'm using guix on
Trisquel 11 with fairly old gpg and git.

jas@kaka:~/src/libntlm$ git log -1 --show-signature
commit 4f64fd94d5e11b0f9226a3e15cae69ef9fdbb585 (HEAD -> master)
gpg: Signatur gjord tor  9 maj 2024 10:49:27 CEST
gpg:              med EDDSA-nyckeln A3CC9C870B9D310ABAD4CF2F51722B08FE4745A2
gpg: Korrekt signatur från "Simon Josefsson <simon@josefsson.org>" [förbehållslös]
Author: Simon Josefsson <simon@josefsson.org>
Date:   Thu May 9 10:49:27 2024 +0200

    maint: Mention guix git introductory commit.
jas@kaka:~/src/libntlm$ 

/Simon

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

Re: authenticating git checkouts

[Simon Tournier]

Hi,

Thanks for this report.  Sorry for the late reply.


On Thu, 09 May 2024 at 11:28, Simon Josefsson via <help-guix@gnu.org> wrote:

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

You mean the file ’.guix-authorizations’, right?

Well, I think it’s useful for maintaining this list accurate; for
quickly identifying authorized people, it’s easier for a human to check
a name or nickname, say some human-key than long-sequence key.

For instance, Guix has 44 people authorized and I have no clue if "705A
29B7 01EE 410E B6F9 236E 92F1 D22C 608E E7E5" is still active or not.  I
would need to check with GPG (import the key and identify who the person
then check if this person is still active).  From the nickname, it’s
almost straightforward and ease the maintenance, IMHO.


> x) While using s-exp's for .guix-authenticate are fine, I don't think
> this will go down well with the git crowd.  

[...]

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

Well, S-exps are straightforward to manipulate with Guile/Scheme.
Another format would require an extra step.  Hence, we could imagine:
let $someone implements the authentication strategy relying on the
keyring branch etc. on the top of their preferred format. :-)

Strategical laziness? ;-)


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

Ah it does not fail for me.  I do not know.


> 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

Just to be sure, the file is ’.guix-authorizations’, right?

To my knowledge, this name is hard-encoded in the Guile module ’(guix
git-authenticate)’ that is called when running ’guix git authenticate’.
Maybe I am missing something.


Cheers,
simon

Re: authenticating git checkouts

[Ludovic Courtès]

Hi Simon,

Sorry for not noticing your message earlier!

Simon Josefsson via <help-guix@gnu.org> skribis:

> I tried to adopt this approach for the libntlm project, but failed.

Oops!

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

The convention you propose sounds fine; the one we have in Guix is
convenient too (hash prefix followed by nickname).

I don’t feel a need to enforce a convention, I think it’s fine to let
people do it the way they want.

> x) How about using ASCII armored PGP blobs instead of binary PGP files
> for the *.key files?

Both are accepted.  In the Guix repo, we use ASCII-armored files:

  https://git.savannah.gnu.org/cgit/guix.git/tree/?h=keyring

> 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

Clearly error reporting is completely bogus here; looking at the code,
the core issue seems to be that one of these files did not contain valid
radix64, but it could be a CRLF issue leading to that.  Worth reporting
a bug with a reproducer if you can!

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

I agree about exporting minimal keys.  This is not enforced, but clearly
there are many benefits to that: GDPR, right, but also performance
(fewer OpenPGP packets to parse).

> 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

Would you like to send a patch to add this suggestion to the manual?

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

Back in the day, Git itself supported nothing but OpenPGP.  But you’re
right, it’d be interesting to support SSH keys as well now.  It’s not
very useful for Guix itself, but it would be useful as a general-purpose
tool.

Speaking of which, as mentioned on Mastodon, Finn Landweber implemented
a tool called ‘git-verify’ around the same idea as a proof of concept,
this time using SSH keys:

  https://codeberg.org/flandweber/git-verify

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

Correct, it’s unused; I find it to be a useful hint but maybe that’s
confusing?

> 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

So this bit of info in .git/config already has this format.  But I guess
you’re talking about ‘.guix-authorizations’ itself, in which case: yes,
I agree that we should standardize on something that works for most, I
had something like JSON in mind.

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

Yes, but I’m open to suggestions as to what should be done in this case.

> The second invocation exit fine but running 'guix git authenticate'
> again failed.

How did it fail?

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

Hmm right, I think you have to mention the subkey ID instead of the
primary key ID, which is confusing.  That’s why we have these comments
with primary key IDs in Guix:

  https://git.savannah.gnu.org/cgit/guix.git/tree/.guix-authorizations

Clearly that’s suboptimal and should be fixed.

> +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)

s/integrity/authenticity/ :-)

Thanks a lot for trying it out and reporting back!  I see there are bugs
and issues to address, and documentation to improve.  It would be nice
if we could boil them down into bug reports so we can eventually fix
them one by one.

Ludo’.