git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Fabian Stelzer <fs@gigacodes.de>
To: Matthias Maier <tamiko-GITVGER@43-1.org>
Cc: git@vger.kernel.org
Subject: Re: Using principal wildcards in gpg.ssh.allowedSignersFile
Date: Fri, 17 Dec 2021 10:42:35 +0100	[thread overview]
Message-ID: <20211217094235.i2fwildp7rcjcgtz@fs> (raw)
In-Reply-To: <87zgoziwfo.fsf@gentoo.org>

On 17.12.2021 00:20, Matthias Maier wrote:
>Dear all,
>
>I am experimenting with git version 2.34.1 (and OpenSSH 8.8_p1) a bit
>trying to set up a repository with SSH signatures for commits instead of
>pgp. I have also tested the current "git next" branch.
>
>The straight-forward setup (by having an "allowed_signers" file
>naming individual e-mails and pubkeys) works as anticipated.
>
>However, when trying to combine this with an SSH certificate authority
>(which would be the use case I have in mind) I am not able to use an
>e-mail wildcard in the "allowed_signers" file but have to specify full
>e-mails instead. This, unfortunately, defeats a bit the purpose of
>having an SSH certificate authority in the first place...
>

Thanks for your report. I tested the described behaviour and I think this is 
a bug in openssh. find-principals will never match on a CA cert with 
wildcard principals whereas wildcards for non-CA keys work just fine. I've 
emailed the openssh maintainer about it and will prepare a patch.

>Steps to reproduce:
>
>====================
>Set up a minimal CA:
>====================
>
>  $ mkdir /tmp/signing-test
>  $ cd /tmp/signing-test
>
>
>A)  Set up two test pubkeys:
>
>  $ ssh-keygen -t ed25519 -C "ca key" -f id_ca
>  [...]
>  $ ssh-keygen -t ed25519 -C "user key" -f id_user
>  [...]
>
>
>B)  Sign user key creating an SSH certificate:
>  [...]
>
>C)  Create allowed signers file:
>
>  $ (printf '*@43-1.org cert-authority,namespaces="file,git" '; cat id_ca.pub) > allowed_signers
>
>  ! Important: I used a wild card "*@43-1.org" for the principal!
>
>
>D) Test setup:
>
>  $ echo this is some random text > test.txt
>  $ ssh-keygen -Y sign -f id_user-cert.pub -n file test.txt
>  Signing file test.txt
>  Write signature to test.txt.sig
>
>  $ ssh-keygen -Y find-principals -f allowed_signers -n file -s test.txt.sig
>  tamiko@43-1.org

Are you sure the allowed_signers file was exactly what you generated before 
for this command? If I follow your steps this will not produce a principal 
for me with neither openssh-8.8.1, nor master. Can you run this with `-vvv` 
which will show a bit more ssh internal output?
In the openssh code for find-principals wildcard principals are filtered for 
CA certs. I'm not sure why and have asked them about it.

By the way, find-principals will not consider the namespace parameter.
This has another bug in the current master producing a segfault for which 
I've already sent a patch. But this should be unrelated to your issue.

>
>  $ ssh-keygen -Y verify -f allowed_signers -I "tamiko@43-1.org" -n file -s test.txt.sig < test.txt
>  Good "file" signature for tamiko@43-1.org with ED25519-CERT key SHA256:noSSfVeVlrYi6vGgK+jRPvyBnIV4ccVA0iW4IXYdXDQ
>
>
>=======================
>Set up a git repository
>=======================
>
>E) Set up an empty repository somewhere
>
>  $ cd /tmp
>  $ git init signing-test-repo
>  $ cd signing-test-repo
>
>  and modify .git/config to look like this:
>
>        [core]
>                repositoryformatversion = 0
>                filemode = true
>                bare = false
>                logallrefupdates = true
>        [commit]
>                gpgsign = true
>        [user]
>                signingkey = /tmp/signing-test/id_user-cert.pub
>        [gpg]
>                format = ssh
>        [gpg "ssh"]
>                allowedSignersFile = /tmp/signing-test/allowed_signers
>
>
>F) make a commit
>
>  $ git commit -a --allow-empty -m "my shiny new ssh key signed commit"
>
>  $ git log --show-signature
>  Good "git" signature with ED25519-CERT key SHA256:noSSfVeVlrYi6vGgK+jRPvyBnIV4ccVA0iW4IXYdXDQ
>  /tmp/signing-test/allowed_signers:1: no valid principals found
>  No principal matched.
>  Author: Matthias Maier <tamiko@43-1.org>
>  Date:   Mon Dec 13 23:51:03 2021 -0600

Just FYI: if you add GIT_TRACE=1 to the git commands you can see the 
executed ssh-keygen commands, which can help to see whats going on.

>
>
>G) modify allowd_signers entry to read "tamiko@43-1.org" instead of the wildcard "*@43-1.org":
>
>  $ git log --show-signature
>  Good "git" signature for tamiko@43-1.org with ED25519-CERT key SHA256:noSSfVeVlrYi6vGgK+jRPvyBnIV4ccVA0iW4IXYdXDQ
>  Author: Matthias Maier <tamiko@43-1.org>
>  Date:   Mon Dec 13 23:51:03 2021 -0600

  reply	other threads:[~2021-12-17  9:42 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-17  6:20 Using principal wildcards in gpg.ssh.allowedSignersFile Matthias Maier
2021-12-17  9:42 ` Fabian Stelzer [this message]
2021-12-17 16:41   ` Matthias Maier
2022-02-03 12:41   ` Fabian Stelzer
2022-02-03 18:43     ` Junio C Hamano

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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=20211217094235.i2fwildp7rcjcgtz@fs \
    --to=fs@gigacodes.de \
    --cc=git@vger.kernel.org \
    --cc=tamiko-GITVGER@43-1.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 public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).