New issue

ssh signing: Add commit & tag signing/verification via SSH keys using ssh-keygen #1041

Conversation

Copy link

Contributor

FStelzer commented on Jul 5 •

edited by gitgitgadget-git bot

openssh 8.7 will add valid-after, valid-before options to the allowed keys keyring. This allows us to pass the commit timestamp to the verification call and make key rollover possible and still be able to verify older commits.
Set valid-after to the current date when adding your key to the keyring and set valid-before to make it fail if used after a certain date.
Software like gitolite/github or corporate automation can do this automatically when ssh push keys are addded / removed
I will add this feature in a follow up patch afterwards since the released 8.7 version has a broken ssh-keygen implementation which will break ssh signing completely.

change unknown signing key behavior to fail verify-commit/tag just like gpg does
add test for unknown signing keys for ssh & gpg
made default signing key retrieval configurable (gpg.ssh.defaultKeyCommand). We could default this to "ssh-add -L" but would risk some users signing with a wrong key
die() instead of error in case of incompatible signatures to match current BUG() behaviour more
various review fixes (early return for config parse, missing free, comments)
got rid of strcmp("ssh") branches and used format configurable callbacks everywhere
moved documentation changes into the commits adding the specific functionality

fixes a bug around find-principals buffer i was releasing while still iterating over it. Uses separate strbufs now.
rename a wrong variable in the tests
use git_config_pathname instead of string where applicable

cc: Han-Wen Nienhuys [email protected]
cc: Fabian Stelzer [email protected]
cc: "brian m. carlson" [email protected]
cc: "Randall S. Becker" [email protected]
cc: Bagas Sanjaya [email protected]
cc: Hans Jerry Illikainen [email protected]
cc: Ævar Arnfjörð Bjarmason [email protected]
cc: Felipe Contreras [email protected]
cc: Eric Sunshine [email protected]
cc: Gwyneth Morgan [email protected]
cc: Jonathan Tan [email protected]
cc: Josh Steadmon [email protected]

cc: Carlo Arenas [email protected]
cc: Fabian Stelzer [email protected]

Welcome to GitGitGadget

Hi @FStelzer, and welcome to GitGitGadget, the GitHub App to send patch series to the Git mailing list from GitHub Pull Requests.

Please make sure that your Pull Request has a good description, as it will be used as cover letter.

Also, it is a good idea to review the commit messages one last time, as the Git project expects them in a quite specific form:

the lines should not exceed 76 columns,
the first line should be like a header and typically start with a prefix like "tests:" or "revisions:" to state which subsystem the change is about, and
the commit messages' body should be describing the "why?" of the change.
Finally, the commit messages should end in a Signed-off-by: line matching the commits' author.

It is in general a good idea to await the automated test ("Checks") in this Pull Request before contributing the patches, e.g. to avoid trivial issues such as unportable code.

Contributing the patches

Before you can contribute the patches, your GitHub username needs to be added to the list of permitted users. Any already-permitted user can do that, by adding a comment to your PR of the form /allow. A good way to find other contributors is to locate recent pull requests where someone has been /allowed:

Search: is:pr is:open "/allow"

Both the person who commented /allow and the PR author are able to /allow you.

An alternative is the channel #git-devel on the Libera Chat IRC network:

<newcontributor> I've just created my first PR, could someone please /allow me? https://github.com/gitgitgadget/git/pull/12345
<veteran> newcontributor: it is done
<newcontributor> thanks!

Once on the list of permitted usernames, you can contribute the patches to the Git mailing list by adding a PR comment /submit.

If you want to see what email(s) would be sent for a /submit request, add a PR comment /preview to have the email(s) sent to you. You must have a public GitHub email address for this.

After you submit, GitGitGadget will respond with another comment that contains the link to the cover letter mail in the Git mailing list archive. Please make sure to monitor the discussion in that thread and to address comments and suggestions (while the comments and suggestions will be mirrored into the PR by GitGitGadget, you will still want to reply via mail).

If you do not want to subscribe to the Git mailing list just to be able to respond to a mail, you can download the mbox from the Git mailing list archive (click the (raw) link), then import it into your mail program. If you use GMail, you can do this via:

curl -g --user "<EMailAddress>:<Password>" \
    --url "imaps://imap.gmail.com/INBOX" -T /path/to/raw.txt

To iterate on your change, i.e. send a revised patch or patch series, you will first want to (force-)push to the same branch. You probably also want to modify your Pull Request description (or title). It is a good idea to summarize the revision by adding something like this to the cover letter (read: by editing the first comment on the PR, i.e. the PR description):

Changes since v1:
- Fixed a typo in the commit message (found by ...)
- Added a code comment to ... as suggested by ...
...

To send a new iteration, just add another PR comment with the contents: /submit.

Need help?

New contributors who want advice are encouraged to join [email protected], where volunteers who regularly contribute to Git are willing to answer newbie questions, give advice, or otherwise provide mentoring to interested contributors. You must join in order to post or view messages, but anyone can join.

You may also be able to find help in real time in the developer IRC channel, #git-devel on Libera Chat. Remember that IRC does not support offline messaging, so if you send someone a private message and log out, they cannot respond to you. The scrollback of #git-devel is archived, though.

FStelzer

changed the title RFC: Add commit & tag signing/verification via SSH keys using ssh-keysign

RFC: Add commit & tag signing/verification via SSH keys using ssh-keygen

on Jul 5

Copy link

Member

dscho commented on Jul 5

@FStelzer would you mind editing the initial comment on this PR? It will be used as "cover letter", but it repeats the commit message. If in doubt, just edit the comment and empty it out.

Copy link

Contributor

Author

FStelzer commented on Jul 5

@FStelzer would you mind editing the initial comment on this PR? It will be used as "cover letter", but it repeats the commit message. If in doubt, just edit the comment and empty it out.

Hi @dscho not sure if i understand correctly. My commit message is just a single line. I thought the cover letter was supposed to explain the change / reasoning behind it? Or would you like me to put this info into the commit message instead?

Copy link

Member

dscho left a comment

I see a lot of code changes, but no documentation updates. Could you please add them?

Also, since this requires a fairly new OpenSSH version, what is the story when the user has too old a version installed? Do they get an informative error message?

gpg-interface.c

Outdated Show resolved

gpg-interface.c

Outdated Show resolved

Copy link

Member

dscho commented on Jul 5

I thought the cover letter was supposed to explain the change / reasoning behind it? Or would you like me to put this info into the commit message instead?

Oh, I'm sorry, I misunderstood. Yes, in the Git project the information needs to go into the commit message. Information in the cover letter should be restricted to things that might be interesting in the context of the code submission, but that won't be interesting any longer when looking at the commit in six months.

Copy link

Member

dscho commented on Jul 5

/allow

User FStelzer is now allowed to use GitGitGadget.

WARNING: FStelzer has no public email address set on GitHub

Copy link

Contributor

Author

FStelzer commented on Jul 5

added some docs and sane errors in case an older openssh is used.

Copy link

Member

dscho commented on Jul 5

added some docs and sane errors in case an older openssh is used.

Unfortunately, I had to kick off the build manually again. But it is running now.

Copy link

Contributor

Author

FStelzer commented on Jul 6

/submit

Submitted as [email protected]

To fetch this version into FETCH_HEAD:

git fetch https://github.com/gitgitgadget/git pr-git-1041/FStelzer/sshsign-v1

To fetch this version to local tag pr-git-1041/FStelzer/sshsign-v1:

git fetch --no-tags https://github.com/gitgitgadget/git tag pr-git-1041/FStelzer/sshsign-v1

WARNING: FStelzer has no public email address set on GitHub

On the Git mailing list, Han-Wen Nienhuys wrote (reply to this):

On Tue, Jul 6, 2021 at 10:20 AM Fabian Stelzer via GitGitGadget
<[email protected]> wrote:
>
> From: Fabian Stelzer <[email protected]>
>
> set gpg.format = ssh and user.signingkey to a ssh public key string (like from an
> authorized_keys file) and commits/tags can be signed using the private
> key from your ssh-agent.
>
> Verification uses a allowed_signers_file (see ssh-keygen(1)) which
> defaults to .gitsigners but can be set via gpg.ssh.allowedsigners
> A possible gpg.ssh.revocationfile is also passed to ssh-keygen on
> verification.
>
...
>     In our corporate environemnt we use PIV x509 Certs on Yubikeys for email
>     signing/encryption and ssh keys which i think is quite common (at least
>     for the email part). This way we can establish the correct trust for the
>     SSH Keys without setting up a separate GPG Infrastructure (which is
>     still quite painful for users) or implementing x509 signing support for
>     git (which lacks good forwarding mechanisms). Using ssh agent forwarding
>     makes this feature easily usable in todays development environments
>     where code is often checked out in remote VMs / containers.

Thanks for working on this, and I support this initiative. I
coincidentally have started proselytizing something similar just weeks
ago.

My interest is in signing pushes rather than commits/tags, as that (in
combination with SSH U2F support) provides a simple mechanism to
require (forwardable!) 2-factor authentication on pushes over HTTP. I
haven't looked at the signing code in detail, but I had the impression
that adding SSH signatures would automatically also add support for
signed pushes? (aka. push-certs) Do you know?

-- 
Han-Wen Nienhuys - Google Munich
I work 80%. Don't expect answers from me on Fridays.
--

Google Germany GmbH, Erika-Mann-Strasse 33, 80636 Munich

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg

Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

User Han-Wen Nienhuys <[email protected]> has been added to the cc: list.

On the Git mailing list, Fabian Stelzer wrote (reply to this):

--------------ms020402090403070300090509
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US

>> From: Fabian Stelzer <[email protected]>
>>
>> set gpg.format =3D ssh and user.signingkey to a ssh public key string =
(like from an
>> authorized_keys file) and commits/tags can be signed using the private=

>> key from your ssh-agent.
>>
>> Verification uses a allowed_signers_file (see ssh-keygen(1)) which
>> defaults to .gitsigners but can be set via gpg.ssh.allowedsigners
>> A possible gpg.ssh.revocationfile is also passed to ssh-keygen on
>> verification.
>>
> ...
>>      In our corporate environemnt we use PIV x509 Certs on Yubikeys fo=
r email
>>      signing/encryption and ssh keys which i think is quite common (at=
 least
>>      for the email part). This way we can establish the correct trust =
for the
>>      SSH Keys without setting up a separate GPG Infrastructure (which =
is
>>      still quite painful for users) or implementing x509 signing suppo=
rt for
>>      git (which lacks good forwarding mechanisms). Using ssh agent for=
warding
>>      makes this feature easily usable in todays development environmen=
ts
>>      where code is often checked out in remote VMs / containers.
> Thanks for working on this, and I support this initiative. I
> coincidentally have started proselytizing something similar just weeks
> ago.
>
> My interest is in signing pushes rather than commits/tags, as that (in
> combination with SSH U2F support) provides a simple mechanism to
> require (forwardable!) 2-factor authentication on pushes over HTTP. I
> haven't looked at the signing code in detail, but I had the impression
> that adding SSH signatures would automatically also add support for
> signed pushes? (aka. push-certs) Do you know?
>
Up until now i was not actually aware of the "push signing"=20
functionality in git.
I can see that the send/receive-pack use the same api function calls as=20
commit/tag signing.
So this should work just as well. Especially if using an ssh agent the wh=
ole
process is identical to git. I still need to try private key files=20
directly to see
how user interaction (like entering a passphrase or touching the U2F=20
Token) would work.



--------------ms020402090403070300090509
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
FAowggVwMIIEWKADAgECAgZIjQJd1vQwDQYJKoZIhvcNAQELBQAwgYIxCzAJBgNVBAYTAkRF
MSswKQYDVQQKDCJULVN5c3RlbXMgRW50ZXJwcmlzZSBTZXJ2aWNlcyBHbWJIMR8wHQYDVQQL
DBZULVN5c3RlbXMgVHJ1c3QgQ2VudGVyMSUwIwYDVQQDDBxULVRlbGVTZWMgR2xvYmFsUm9v
dCBDbGFzcyAyMB4XDTEyMTEyOTExMjM1NVoXDTI0MTEyOTIzNTk1OVowdTELMAkGA1UEBhMC
REUxJTAjBgNVBAoTHFQtU3lzdGVtcyBJbnRlcm5hdGlvbmFsIEdtYkgxHzAdBgNVBAsTFlQt
U3lzdGVtcyBUcnVzdCBDZW50ZXIxHjAcBgNVBAMTFVRlbGVTZWMgQnVzaW5lc3MgQ0EgMTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANEw1E1Ew+RLWrQYng5RJ7WpYkl6GgbA
cywRiVWSrA7L/kgvu13j9KmIuoFr5Ps3HSxX60WYVUFGicfnpzFke554CJ/AGD/pSmKxhPzg
0MytlS67gGr1p2TFN/vePeegzbGidDWjz+/tTXRtuo0kGrSf/FpVRjv/98LxeXp2d89P68oi
jXbYBZn3BPE8n3zbqGnwVd+jQahJS25dIHENuosJbmsi8KSd81aJwNbAWDAIV+Zi3Y4/0L3j
ujhXX63SNVK7q67Gtp8hEpOvRYtWNtXMpEw2LzPhtILmZEVd7urX3KBNQX/eZpmK/V1u7EXr
dOIJE/aK6qhnKGpOn/gSrLUCAwEAAaOCAfYwggHyMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4E
FgQUhoiTH4vrVZZl1UcBvTeMfM2ox6MwHwYDVR0jBBgwFoAUv1kgNgB5oKAia4zV8mHSuCzL
gkowEgYDVR0TAQH/BAgwBgEB/wIBADBTBgNVHSAETDBKMD4GCSsGAQQBvUcNGTAxMC8GCCsG
AQUFBwIBFiNodHRwOi8vc2JjYS50ZWxlc2VjLmRlL2Nwcy9jcHMyLnBkZjAIBgZngQwBAgIw
gfoGA1UdHwSB8jCB7zA6oDigNoY0aHR0cDovL2NybC5zYmNhLnRlbGVzZWMuZGUvcmwvR2xv
YmFsUm9vdF9DbGFzc18yLmNybDCBsKCBraCBqoaBp2xkYXA6Ly9sZGFwLnNiY2EudGVsZXNl
Yy5kZS9DTj1ULVRlbGVTZWMlMjBHbG9iYWxSb290JTIwQ2xhc3MlMjAyLE9VPVQtU3lzdGVt
cyUyMFRydXN0JTIwQ2VudGVyLE89VC1TeXN0ZW1zJTIwRW50ZXJwcmlzZSUyMFNlcnZpY2Vz
JTIwR21iSCxDPURFP0F1dGhvcml0eVJldm9jYXRpb25MaXN0MDoGCCsGAQUFBwEBBC4wLDAq
BggrBgEFBQcwAYYeaHR0cDovL29jc3AwNC50ZWxlc2VjLmRlL29jc3ByMA0GCSqGSIb3DQEB
CwUAA4IBAQCThdHrhHoZWcglgDokpbmWcQab/tYOdOBA3dXNXR0ggBlDSQ94dt4j3lzMN+2j
ynxKIQTZJZGZsT8HsmRC3BTnpY/T7a0gbXkdUiwXspLQs18wL0Q+Vu80V7aHkKm8R3WIMpM+
72lLGkowDbHnDUMBZYd8N4+bStWrUcn29ZfDHj9eFJSutg1yWfzl1xdfxOJmTtpmjSjRCtc7
tixaok7W2O+SlS1lmSRoMIqCDWLO34f//Dj1hHrOx4xxRnojKX2s9lYoAqyAi69XoEgdiGGf
Sj7/37yhZp0aAYbzHBFVy1rS/DC5FNYrCQfsauP2jVEaRClHbpeOwTHWNQj4HiRPMIIHRzCC
Bi+gAwIBAgIQGcQYOJIYjQ3VtN/uupEfjDANBgkqhkiG9w0BAQsFADB1MQswCQYDVQQGEwJE
RTElMCMGA1UEChMcVC1TeXN0ZW1zIEludGVybmF0aW9uYWwgR21iSDEfMB0GA1UECxMWVC1T
eXN0ZW1zIFRydXN0IENlbnRlcjEeMBwGA1UEAxMVVGVsZVNlYyBCdXNpbmVzcyBDQSAxMB4X
DTIwMDIxODEwNDg0NFoXDTIzMDIxODIzNTk1OVowgbgxCzAJBgNVBAYTAkRFMRQwEgYDVQQK
EwtjYW1Qb2ludCBBRzEVMBMGA1UECxMMY2FtcG9pbnQubmV0MRQwEgYDVQQLEwtFbmdpbmVl
cmluZzEXMBUGA1UEAxMORmFiaWFuIFN0ZWx6ZXIxDzANBgNVBCoTBkZhYmlhbjEQMA4GA1UE
BBMHU3RlbHplcjEeMBwGCSqGSIb3DQEJARYPZnNAZ2lnYWNvZGVzLmRlMQowCAYDVQQFEwEx
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzbHjTTbD/7OTER1JcFv2dsDtVRxg
fkbZlLqcd1u0t5W2rVt1a31rXY7smiTfy7dSbdj0mCHu0ud8WgjU/+i1NveWsmX1pKZ6hNEa
2yvTRC8DRe+U6+ba/uTbhQmEngvAU8EPHZPcGfilaGoSMot5bwh43XTe6hiPaZknZPa/6BqY
RXNaEvlJpVHC2GISNXWsARHpwXQRhd3rcqI0Y2sljnfpWbc3Aq5tydC6No0ftLGJK9Mqyqpy
B0LZQfkUeKlFMBmfPRuqQY3USQHbmte+ubSTASbOt2kmz34KzHF9Tpc659M5LMea13RKy5GT
L9gB3caeGbYHOIM6hysy+DSPLwIDAQABo4IDjTCCA4kwHwYDVR0jBBgwFoAUhoiTH4vrVZZl
1UcBvTeMfM2ox6MwHQYDVR0OBBYEFG5COl6QaEu+ziQIm+nfntcMBPfFMA4GA1UdDwEB/wQE
AwIFIDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwWAYDVR0gBFEwTzBDBgkrBgEE
Ab1HDRkwNjA0BggrBgEFBQcCARYoaHR0cDovL3NiY2EudGVsZXNlYy5kZS9kb3dubG9hZC9j
cHMyLnBkZjAIBgYEAI96AQEwCQYDVR0TBAIwADCB8AYDVR0fBIHoMIHlMD2gO6A5hjdodHRw
Oi8vY3JsLnNiY2EudGVsZXNlYy5kZS9ybC9UZWxlU2VjX0J1c2luZXNzX0NBXzEuY3JsMIGj
oIGgoIGdhoGabGRhcDovL2xkYXAuc2JjYS50ZWxlc2VjLmRlL0NOPVRlbGVTZWMlMjBCdXNp
bmVzcyUyMENBJTIwMSxPVT1ULVN5c3RlbXMlMjBUcnVzdCUyMENlbnRlcixPPVQtU3lzdGVt
cyUyMEludGVybmF0aW9uYWwlMjBHbWJILEM9REU/Q2VydGlmaWNhdGVSZXZvY2F0aW9uTGlz
dDCCAScGCCsGAQUFBwEBBIIBGTCCARUwLwYIKwYBBQUHMAGGI2h0dHA6Ly9vY3NwMDMuc2Jj
YS50ZWxlc2VjLmRlL29jc3ByMEQGCCsGAQUFBzAChjhodHRwOi8vY3J0LnNiY2EudGVsZXNl
Yy5kZS9jcnQvVGVsZVNlY19CdXNpbmVzc19DQV8xLmNydDCBmwYIKwYBBQUHMAKGgY5sZGFw
Oi8vbGRhcC5zYmNhLnRlbGVzZWMuZGUvY249VGVsZVNlYyUyMEJ1c2luZXNzJTIwQ0ElMjAx
LG91PVQtU3lzdGVtcyUyMFRydXN0JTIwQ2VudGVyLG89VC1TeXN0ZW1zJTIwSW50ZXJuYXRp
b25hbCUyMEdtYkgsYz1kZT9jQUNlcnRpZmljYXRlMIGUBgNVHREEgYwwgYmBD2ZzQGdpZ2Fj
b2Rlcy5kZYEbZmFiaWFuLnN0ZWx6ZXJAZ2lnYWNvZGVzLmRlgQ9mc0BjYW1wb2ludC5uZXSB
G2ZhYmlhbi5zdGVsemVyQGNhbXBvaW50Lm5ldKArBgorBgEEAYI3FAIDoB0MG2ZhYmlhbi5z
dGVsemVyQGNhbXBvaW50Lm5ldDANBgkqhkiG9w0BAQsFAAOCAQEAA/gvcSSSg+3Fv/zQ5W8Q
NqZ7e+o2gvAAK9/m13ZZsffXma0MlVxnszHSecBWNWIGaMsnorfs3UOBtvNKi071OSZHIRdt
01R/BeIs1THloF5i93LxJht8L9YhUPLVFpLyXSJpAeZeBgmgxETjZ6NxMPvDGTowJbXuoghl
Enffv2OZ/eqyQfloJhs0GedD+ywRcHRtgdebhmdAIND+0wvEwb4orZYpVMC1Iif5YQoRoppy
KhFBXM7umYzm3a3o9F1xsdCZtH8pcsQbxk6++rFdwATjRXPdqx1nrJc/7KTPFpPiAXNLn8AE
FxntRDmy+kAHAqGOvPr7p6ZoCuLjJxc8mDCCB0cwggYvoAMCAQICECqns9Gy7hp/JP/uYPRZ
JCcwDQYJKoZIhvcNAQELBQAwdTELMAkGA1UEBhMCREUxJTAjBgNVBAoTHFQtU3lzdGVtcyBJ
bnRlcm5hdGlvbmFsIEdtYkgxHzAdBgNVBAsTFlQtU3lzdGVtcyBUcnVzdCBDZW50ZXIxHjAc
BgNVBAMTFVRlbGVTZWMgQnVzaW5lc3MgQ0EgMTAeFw0yMDAyMTgxMDQ4NDRaFw0yMzAyMTgy
MzU5NTlaMIG4MQswCQYDVQQGEwJERTEUMBIGA1UEChMLY2FtUG9pbnQgQUcxFTATBgNVBAsT
DGNhbXBvaW50Lm5ldDEUMBIGA1UECxMLRW5naW5lZXJpbmcxFzAVBgNVBAMTDkZhYmlhbiBT
dGVsemVyMQ8wDQYDVQQqEwZGYWJpYW4xEDAOBgNVBAQTB1N0ZWx6ZXIxHjAcBgkqhkiG9w0B
CQEWD2ZzQGdpZ2Fjb2Rlcy5kZTEKMAgGA1UEBRMBMTCCASIwDQYJKoZIhvcNAQEBBQADggEP
ADCCAQoCggEBALzoNe796N6LfGhYkcCF7XtOjZiCfLDwx1L9QhDv0DwGp+dLo+5n/iI+/rlA
wwBgqhtLvaaWNE2vJuXYMVZXVyUgz4Wq1FvX9lXd7J4IiHhiHqcY1r0GB8IrY6kpiRaH5iyt
fOexvsVW9ddo3FzUGjjGMDYsyd9ppzqWXE9Q3Nbc7U9orhnGGp3xh20HTdP+iIDEaUhHkJIl
Rpni14oY+kSWq1WSw2m+qKsWux6KcQS3wKuoO3AAi5DX6vDtp5xztnffqI+SmCeT44CyCwrK
uZk5JBMsOaeaWYr8UiTNzS26Y46f2KeXnss2qc85i4p0hxp/qj7q28UwV5gE1w2La7cCAwEA
AaOCA40wggOJMB8GA1UdIwQYMBaAFIaIkx+L61WWZdVHAb03jHzNqMejMB0GA1UdDgQWBBR/
VPCB1rrm9xWvIhb2q8u5gSXriDAOBgNVHQ8BAf8EBAMCB4AwHQYDVR0lBBYwFAYIKwYBBQUH
AwIGCCsGAQUFBwMEMFgGA1UdIARRME8wQwYJKwYBBAG9Rw0ZMDYwNAYIKwYBBQUHAgEWKGh0
dHA6Ly9zYmNhLnRlbGVzZWMuZGUvZG93bmxvYWQvY3BzMi5wZGYwCAYGBACPegEBMAkGA1Ud
EwQCMAAwgfAGA1UdHwSB6DCB5TA9oDugOYY3aHR0cDovL2NybC5zYmNhLnRlbGVzZWMuZGUv
cmwvVGVsZVNlY19CdXNpbmVzc19DQV8xLmNybDCBo6CBoKCBnYaBmmxkYXA6Ly9sZGFwLnNi
Y2EudGVsZXNlYy5kZS9DTj1UZWxlU2VjJTIwQnVzaW5lc3MlMjBDQSUyMDEsT1U9VC1TeXN0
ZW1zJTIwVHJ1c3QlMjBDZW50ZXIsTz1ULVN5c3RlbXMlMjBJbnRlcm5hdGlvbmFsJTIwR21i
SCxDPURFP0NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3QwggEnBggrBgEFBQcBAQSCARkwggEV
MC8GCCsGAQUFBzABhiNodHRwOi8vb2NzcDAzLnNiY2EudGVsZXNlYy5kZS9vY3NwcjBEBggr
BgEFBQcwAoY4aHR0cDovL2NydC5zYmNhLnRlbGVzZWMuZGUvY3J0L1RlbGVTZWNfQnVzaW5l
c3NfQ0FfMS5jcnQwgZsGCCsGAQUFBzAChoGObGRhcDovL2xkYXAuc2JjYS50ZWxlc2VjLmRl
L2NuPVRlbGVTZWMlMjBCdXNpbmVzcyUyMENBJTIwMSxvdT1ULVN5c3RlbXMlMjBUcnVzdCUy
MENlbnRlcixvPVQtU3lzdGVtcyUyMEludGVybmF0aW9uYWwlMjBHbWJILGM9ZGU/Y0FDZXJ0
aWZpY2F0ZTCBlAYDVR0RBIGMMIGJgQ9mc0BnaWdhY29kZXMuZGWBG2ZhYmlhbi5zdGVsemVy
QGdpZ2Fjb2Rlcy5kZYEPZnNAY2FtcG9pbnQubmV0gRtmYWJpYW4uc3RlbHplckBjYW1wb2lu
dC5uZXSgKwYKKwYBBAGCNxQCA6AdDBtmYWJpYW4uc3RlbHplckBjYW1wb2ludC5uZXQwDQYJ
KoZIhvcNAQELBQADggEBAKhFKqWHnQ+41OcsXr/96UBOGPo5B8NT4FZy1o6QY5NVicS+y2Kz
8pOoeJbhg4nCc9FdSfYvPp6z1KboYSGusM5NNto4qdWqWDZ/+25lWrlMYsCtxKyD9Smtsu/7
uwikJ5NO8rOP08JoznvwWZ2INq+sRyJ57zwNoNVs/65v3xyYyrC+BFOAGIg3B3J1Jw2wmoM8
lDsnoGUjh7R9FstuY2CK29RaVCO2w35Vvd9cwqQzOVURq0t+2MGh0RItXH7450gfR7RZVoYG
vNTXsR6/3RzcM+YbYZMBCQuAH4ibFmIw3TjdShpjQiAfc+cCPNSbnrenvzhgKcEH4ZiOz4cS
RdQxggPMMIIDyAIBATCBiTB1MQswCQYDVQQGEwJERTElMCMGA1UEChMcVC1TeXN0ZW1zIElu
dGVybmF0aW9uYWwgR21iSDEfMB0GA1UECxMWVC1TeXN0ZW1zIFRydXN0IENlbnRlcjEeMBwG
A1UEAxMVVGVsZVNlYyBCdXNpbmVzcyBDQSAxAhAqp7PRsu4afyT/7mD0WSQnMA0GCWCGSAFl
AwQCAQUAoIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0y
MTA3MDYxMTIzMzNaMC8GCSqGSIb3DQEJBDEiBCC8OiMdsH4nALjEA9weCbU1E4N5zsh53rSE
3vhbSJ88EjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYI
KoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqG
SIb3DQMCAgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCREUxJTAjBgNVBAoT
HFQtU3lzdGVtcyBJbnRlcm5hdGlvbmFsIEdtYkgxHzAdBgNVBAsTFlQtU3lzdGVtcyBUcnVz
dCBDZW50ZXIxHjAcBgNVBAMTFVRlbGVTZWMgQnVzaW5lc3MgQ0EgMQIQGcQYOJIYjQ3VtN/u
upEfjDCBnAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCREUxJTAjBgNVBAoTHFQt
U3lzdGVtcyBJbnRlcm5hdGlvbmFsIEdtYkgxHzAdBgNVBAsTFlQtU3lzdGVtcyBUcnVzdCBD
ZW50ZXIxHjAcBgNVBAMTFVRlbGVTZWMgQnVzaW5lc3MgQ0EgMQIQGcQYOJIYjQ3VtN/uupEf
jDANBgkqhkiG9w0BAQEFAASCAQAoMEysuBnpK6Z6VcqJeSLewtsSmsw7I4NFnvEF3x6qLcfo
PU9FFYEalE/3J7r7DTdGcnySTnSqzdmEfwsnsXkFazbyrEesQ6TID8wIM3sMnADF4Wch4KS2
pL4r/JZEYHJWaJ6wTbvZShR35xI7U1aceAViywxvurWaeRsnfdsCRuwRnz/KszhcWbBaFm8M
oMLIlnZtke+ugKfXPPW0FX/byGaVNdQQZOvpWo4KIDo94WLnNKBt++TN0RpgZ9cVu24lHy7Y
DvQsWy20ib5bdMoNlA2ylB2STNek4YeCQr7CfLJaORo0AR6/da4V/jZNJ37irNp1j38WL5Nu
MyNVL5qBAAAAAAAA

--------------ms020402090403070300090509--

User Fabian Stelzer <[email protected]> has been added to the cc: list.

On the Git mailing list, "brian m. carlson" wrote (reply to this):


--+In90pUEPRIdb/1l
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2021-07-06 at 08:19:53, Fabian Stelzer via GitGitGadget wrote:
> From: Fabian Stelzer <[email protected]>
>=20
> set gpg.format =3D ssh and user.signingkey to a ssh public key string (li=
ke from an
> authorized_keys file) and commits/tags can be signed using the private
> key from your ssh-agent.
>=20
> Verification uses a allowed_signers_file (see ssh-keygen(1)) which
> defaults to .gitsigners but can be set via gpg.ssh.allowedsigners
> A possible gpg.ssh.revocationfile is also passed to ssh-keygen on
> verification.
>=20
> needs openssh>8.2p1

Usually we'll want to write the explanation here in full sentences with
typical capitalization.

> Signed-off-by: Fabian Stelzer <[email protected]>
> ---
>     RFC: Add commit & tag signing/verification via SSH keys using ssh-key=
gen
>    =20
>     Support for using private keyfiles directly is still missing and i'm
>     unsure on how to configure it or if the pubkey in the signingkey field
>     is such a good idea. A SSH Fingerprint as signingkey would be nicer, =
but
>     key lookup would be quite cumbersome. Maybe storing the fingerprint in
>     signingkey and then have a gpg.ssh.$FINGERPRINT.publickey/privatekeyf=
ile
>     setting? As a default we could get the first ssh key from ssh-add and
>     store it in the config to avoid unintentional changes of the used
>     signing key. I've started with some tests for SSH Signing but having
>     static private keyfiles would make this a lot easier. So still on my
>     TODO.

I think user.signingKey could be helpful for signing here.  That could
be a file name, not just a fingerprint, although we'd probably want to
have support for tilde expansion.  You could add an additional option,
gpg.ssh.keyring, that specifies the signatures to verify.  That would be
named the same thing as a potential option of gpg.openpgp.keyring,
which would be convenient.  Also, gpg.ssh.revokedKeyring could maybe be
the name for revoked keys?

>     This feature makes git signing much more accessible to the average us=
er.
>     Usually they have a SSH Key for pushing code already. Using it for
>     signing commits allows us to verify not only the transport but the
>     pushed code as well. The allowed_signers file could be kept in the
>     repository if all receives are verified (allowing only useris with va=
lid
>     signatures to add/change them) or outside if generated/managed
>     differently. Tools like gitolite could optionally generate and enforce
>     them from the already existing user ssh keys for example.
>    =20
>     In our corporate environemnt we use PIV x509 Certs on Yubikeys for em=
ail
>     signing/encryption and ssh keys which i think is quite common (at lea=
st
>     for the email part). This way we can establish the correct trust for =
the
>     SSH Keys without setting up a separate GPG Infrastructure (which is
>     still quite painful for users) or implementing x509 signing support f=
or
>     git (which lacks good forwarding mechanisms). Using ssh agent forward=
ing
>     makes this feature easily usable in todays development environments
>     where code is often checked out in remote VMs / containers.

I think some of this rationale would work well in the commit message,
especially the part about the fact that using an SSH key may be easier
for users and the fact that it can be well supported by smart cards.
Those are compelling arguments about why this is a desirable change, and
should be in the commit message.

I haven't looked too deeply at the intricacies of the change, but I'm in
favor of it.  I would, however, like to see some tests here, including
for commits, tags, and push certificates.  Note that you'll probably
need to run the testsuite both with and without
GIT_TEST_DEFAULT_HASH=3Dsha256 to verify everything works.

> diff --git a/Documentation/config/gpg.txt b/Documentation/config/gpg.txt
> index d94025cb368..fd71bd782ec 100644
> --- a/Documentation/config/gpg.txt
> +++ b/Documentation/config/gpg.txt
> @@ -11,13 +11,13 @@ gpg.program::
> =20
>  gpg.format::
>  	Specifies which key format to use when signing with `--gpg-sign`.
> -	Default is "openpgp" and another possible value is "x509".
> +	Default is "openpgp". Other possible values are "x509", "ssh".
> =20
>  gpg.<format>.program::
>  	Use this to customize the program used for the signing format you
>  	chose. (see `gpg.program` and `gpg.format`) `gpg.program` can still
>  	be used as a legacy synonym for `gpg.openpgp.program`. The default
> -	value for `gpg.x509.program` is "gpgsm".
> +	value for `gpg.x509.program` is "gpgsm" and `gpg.ssh.program` is "ssh-k=
eygen".
> =20
>  gpg.minTrustLevel::
>  	Specifies a minimum trust level for signature verification.  If
> @@ -27,6 +27,15 @@ gpg.minTrustLevel::
>  	with at least `undefined` trust.  Setting this option overrides
>  	the required trust-level for all operations.  Supported values,
>  	in increasing order of significance:
> +
> +gpg.ssh.allowedSigners::
> +	A file containing all valid SSH signing principals.=20
> +	Similar to an .ssh/authorized_keys file. See ssh-keygen(1) for details.
> +	Defaults to .gitsigners

We probably don't want to store this in the repository.  If OpenSSH has
a standard location for this, then we can default to that; otherwise, we
should pick something in .ssh or in $XDG_CONFIG_HOME/git.
--=20
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA

--+In90pUEPRIdb/1l
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.3.1 (GNU/Linux)

iHUEABYKAB0WIQQILOaKnbxl+4PRw5F8DEliiIeigQUCYORsUwAKCRB8DEliiIei
gaadAQDsdRNZtyumNOE586t+MMEdAieJiqIRlHDEUXA0wDGYWQD/R1wTFTQj5amV
4RfeY7EdMrtb7PXBNQEYGV85Ngt6zQw=
=/w5r
-----END PGP SIGNATURE-----

--+In90pUEPRIdb/1l--

User "brian m. carlson" <[email protected]> has been added to the cc: list.

On the Git mailing list, Junio C Hamano wrote (reply to this):

"Fabian Stelzer via GitGitGadget" <[email protected]> writes:

> From: Fabian Stelzer <[email protected]>
>
> set gpg.format = ssh and user.signingkey to a ssh public key string (like from an
> authorized_keys file) and commits/tags can be signed using the private
> key from your ssh-agent.
>
> Verification uses a allowed_signers_file (see ssh-keygen(1)) which
> defaults to .gitsigners but can be set via gpg.ssh.allowedsigners
> A possible gpg.ssh.revocationfile is also passed to ssh-keygen on
> verification.

There are probably style and coding-guideline nit people will pick
in the patch, but first of all I have to say that I am uncomfortably
excited to see this addition.

One thing that is unclear is how the 'allowed-signers' is expected
to be maintained in the larger picture.  Who decides which keys
(belong to whom) are trustworthy?  Does a contributor has to agree
with the decision that certain keys are trustworthy made by somebody
else in the project and use the same 'allowed-signers' collection of
keys to effectively participate in the project?  How do revoking and
rotating keys work?

It was a deliberate design decision to let PGP infrastructure that
is used to sign and verify signatures when we use PGP for signing
without tying any of these decisions to the tracked contents, as
that would reduce the attack surface for a malicious tree contents
to affect the signing and verification (in other words, "we punted"
;-).  Even though I am not sure exactly what you meant by "defaults
to .gitsigners", I am assuming that you meant a file with the name
at the top-level of the working tree, which makes me worried, as it
opens us to the risk of reading from and blindly trusting whatever
somebody else placed in the tree contents immediately after we "git
pull" (or "git clone").

Thanks for working on it.

On the Git mailing list, Fabian Stelzer wrote (reply to this):

From: Fabian Stelzer <[email protected]>
>> set gpg.format = ssh and user.signingkey to a ssh public key string (like from an
>> authorized_keys file) and commits/tags can be signed using the private
>> key from your ssh-agent.
>>
>> Verification uses a allowed_signers_file (see ssh-keygen(1)) which
>> defaults to .gitsigners but can be set via gpg.ssh.allowedsigners
>> A possible gpg.ssh.revocationfile is also passed to ssh-keygen on
>> verification.
>>
>> needs openssh>8.2p1
> Usually we'll want to write the explanation here in full sentences with
> typical capitalization.
Thanks, i was unsure about what to put in the commit and what into the 
cover letter.
I'll fix this with the next patch update and move some of it into the 
commit message.
In our env the commit messages are usually kept quite short.
>
>> Signed-off-by: Fabian Stelzer <[email protected]>
>> ---
>>      RFC: Add commit & tag signing/verification via SSH keys using ssh-keygen
>>      
>>      Support for using private keyfiles directly is still missing and i'm
>>      unsure on how to configure it or if the pubkey in the signingkey field
>>      is such a good idea. A SSH Fingerprint as signingkey would be nicer, but
>>      key lookup would be quite cumbersome. Maybe storing the fingerprint in
>>      signingkey and then have a gpg.ssh.$FINGERPRINT.publickey/privatekeyfile
>>      setting? As a default we could get the first ssh key from ssh-add and
>>      store it in the config to avoid unintentional changes of the used
>>      signing key. I've started with some tests for SSH Signing but having
>>      static private keyfiles would make this a lot easier. So still on my
>>      TODO.
> I think user.signingKey could be helpful for signing here.  That could
> be a file name, not just a fingerprint, although we'd probably want to
> have support for tilde expansion.  You could add an additional option,
> gpg.ssh.keyring, that specifies the signatures to verify.  That would be
> named the same thing as a potential option of gpg.openpgp.keyring,
> which would be convenient.  Also, gpg.ssh.revokedKeyring could maybe be
> the name for revoked keys?
The problem ist that looking up a key by fingerprint alone is not really 
possible with ssh :/
A referenced file (which could contain a public or private key) would be 
fine and i could return the fingerprint in the get_signing_key api which 
the pushcerts code uses as "pusher" info in the cert.
I'll change the keyring naming to what you suggested. Makes sense to 
have this option for gpg as well.

>
>>      This feature makes git signing much more accessible to the average user.
>>      Usually they have a SSH Key for pushing code already. Using it for
>>      signing commits allows us to verify not only the transport but the
>>      pushed code as well. The allowed_signers file could be kept in the
>>      repository if all receives are verified (allowing only useris with valid
>>      signatures to add/change them) or outside if generated/managed
>>      differently. Tools like gitolite could optionally generate and enforce
>>      them from the already existing user ssh keys for example.
>>      
>>      In our corporate environemnt we use PIV x509 Certs on Yubikeys for email
>>      signing/encryption and ssh keys which i think is quite common (at least
>>      for the email part). This way we can establish the correct trust for the
>>      SSH Keys without setting up a separate GPG Infrastructure (which is
>>      still quite painful for users) or implementing x509 signing support for
>>      git (which lacks good forwarding mechanisms). Using ssh agent forwarding
>>      makes this feature easily usable in todays development environments
>>      where code is often checked out in remote VMs / containers.
> I think some of this rationale would work well in the commit message,
> especially the part about the fact that using an SSH key may be easier
> for users and the fact that it can be well supported by smart cards.
> Those are compelling arguments about why this is a desirable change, and
> should be in the commit message.
>
> I haven't looked too deeply at the intricacies of the change, but I'm in
> favor of it.  I would, however, like to see some tests here, including
> for commits, tags, and push certificates.  Note that you'll probably
> need to run the testsuite both with and without
> GIT_TEST_DEFAULT_HASH=sha256 to verify everything works.
I'm working on some tests but there are lots of GPG / GPGSM tests in the 
suite and i'm unsure of how many i should duplicate.
Thanks for the info with the hash setting.
>
>> diff --git a/Documentation/config/gpg.txt b/Documentation/config/gpg.txt
>> index d94025cb368..fd71bd782ec 100644
>> --- a/Documentation/config/gpg.txt
>> +++ b/Documentation/config/gpg.txt
>> @@ -11,13 +11,13 @@ gpg.program::
>>   
>>   gpg.format::
>>   	Specifies which key format to use when signing with `--gpg-sign`.
>> -	Default is "openpgp" and another possible value is "x509".
>> +	Default is "openpgp". Other possible values are "x509", "ssh".
>>   
>>   gpg.<format>.program::
>>   	Use this to customize the program used for the signing format you
>>   	chose. (see `gpg.program` and `gpg.format`) `gpg.program` can still
>>   	be used as a legacy synonym for `gpg.openpgp.program`. The default
>> -	value for `gpg.x509.program` is "gpgsm".
>> +	value for `gpg.x509.program` is "gpgsm" and `gpg.ssh.program` is "ssh-keygen".
>>   
>>   gpg.minTrustLevel::
>>   	Specifies a minimum trust level for signature verification.  If
>> @@ -27,6 +27,15 @@ gpg.minTrustLevel::
>>   	with at least `undefined` trust.  Setting this option overrides
>>   	the required trust-level for all operations.  Supported values,
>>   	in increasing order of significance:
>> +
>> +gpg.ssh.allowedSigners::
>> +	A file containing all valid SSH signing principals.
>> +	Similar to an .ssh/authorized_keys file. See ssh-keygen(1) for details.
>> +	Defaults to .gitsigners
> We probably don't want to store this in the repository.  If OpenSSH has
> a standard location for this, then we can default to that; otherwise, we
> should pick something in .ssh or in $XDG_CONFIG_HOME/git.
I'm not aware of a standard location. I think there are use cases to 
store this in the repo, but i'm of course fine not defaulting to it.

On the Git mailing list, Fabian Stelzer wrote (reply to this):

> "Fabian Stelzer via GitGitGadget" <[email protected]> writes:
>
>> From: Fabian Stelzer <[email protected]>
>>
>> set gpg.format = ssh and user.signingkey to a ssh public key string (like from an
>> authorized_keys file) and commits/tags can be signed using the private
>> key from your ssh-agent.
>>
>> Verification uses a allowed_signers_file (see ssh-keygen(1)) which
>> defaults to .gitsigners but can be set via gpg.ssh.allowedsigners
>> A possible gpg.ssh.revocationfile is also passed to ssh-keygen on
>> verification.
> There are probably style and coding-guideline nit people will pick
> in the patch, but first of all I have to say that I am uncomfortably
> excited to see this addition.
>
> One thing that is unclear is how the 'allowed-signers' is expected
> to be maintained in the larger picture.  Who decides which keys
> (belong to whom) are trustworthy?  Does a contributor has to agree
> with the decision that certain keys are trustworthy made by somebody
> else in the project and use the same 'allowed-signers' collection of
> keys to effectively participate in the project?  How do revoking and
> rotating keys work?
>
> It was a deliberate design decision to let PGP infrastructure that
> is used to sign and verify signatures when we use PGP for signing
> without tying any of these decisions to the tracked contents, as
> that would reduce the attack surface for a malicious tree contents
> to affect the signing and verification (in other words, "we punted"
> ;-).  Even though I am not sure exactly what you meant by "defaults
> to .gitsigners", I am assuming that you meant a file with the name
> at the top-level of the working tree, which makes me worried, as it
> opens us to the risk of reading from and blindly trusting whatever
> somebody else placed in the tree contents immediately after we "git
> pull" (or "git clone").
>
> Thanks for working on it.
Glad to hear that :)
I tried to keep the style with the existing code but the IDE sometimes 
has its own idea.

I think there are two basic options for maintaining the allowed signers 
file:
1. Every developer has their own stored outside of the repo and 
adds/revokes trust manually like with gpg.
     A central repo would probably verify against a list managed by the 
tool (e.g. gitolite)
2. Store it in a .gitsigners file in the repo. This would only work if 
you only allow signed commits/pushes from this point onwards. But this 
way a shared understading of trusted users can be maintained easily.
     Only already trusted committers can add new users or change their 
own keys. The signers file is basically a ssh_authorized_keys file with 
an additional principal identifier added at the front like:
     [email protected] ssh-rsa XXXKEYXXX Comment
     [email protected] ssh-ed25519 XXXKEYXXX Comment

Where are commits usually verified at the moment? On every devs checkout 
or only centrally on pushes?

The signers file also supports SSH CA keys and wildcard identifiers. At 
the moment i look up the principal dynamically via the public key so 
it's just a text info of who's key is it at the moment.
The SSH CA Stuff is probably a niche use case but could be cool in a 
corporate setting. Thats also what the revocation file is used for. The 
SSH CA can generate a KRL (like crl) which you put into it or you can 
specify explicit public keys in it to deny them.

On the Git mailing list, Junio C Hamano wrote (reply to this):

Fabian Stelzer <[email protected]> writes:

>> One thing that is unclear is how the 'allowed-signers' is expected
>> to be maintained in the larger picture.  Who decides which keys
>> ...
>> Thanks for working on it.
> Glad to hear that :)

Thanks for explaining your thoughts (omitted).  When I say "this is
unclear" in my response to a patch, I expect that unclear-ness will
be shared by other readers of the code, the doc and/or the log
message, so please make sure an updated patch will reduce the need
to ask the same question by future readers.

> I tried to keep the style with the existing code but the IDE sometimes
> has its own idea.

Documentation/CodingGuidelines and Documentation/SubmittingPatches
would hopefully help (if not, please ask and/or suggest clarification
on these documents).

Thanks.

On the Git mailing list, "Randall S. Becker" wrote (reply to this):

On July 6, 2021 11:46 AM, Fabian Stelzer wrote:
>> "Fabian Stelzer via GitGitGadget" <[email protected]> writes:
>>
>>> From: Fabian Stelzer <[email protected]>
>>>
>>> set gpg.format = ssh and user.signingkey to a ssh public key string
>>> (like from an authorized_keys file) and commits/tags can be signed
>>> using the private key from your ssh-agent.
>>>
>>> Verification uses a allowed_signers_file (see ssh-keygen(1)) which
>>> defaults to .gitsigners but can be set via gpg.ssh.allowedsigners A
>>> possible gpg.ssh.revocationfile is also passed to ssh-keygen on
>>> verification.
>> There are probably style and coding-guideline nit people will pick in
>> the patch, but first of all I have to say that I am uncomfortably
>> excited to see this addition.
>>
>> One thing that is unclear is how the 'allowed-signers' is expected to
>> be maintained in the larger picture.  Who decides which keys (belong
>> to whom) are trustworthy?  Does a contributor has to agree with the
>> decision that certain keys are trustworthy made by somebody else in
>> the project and use the same 'allowed-signers' collection of keys to
>> effectively participate in the project?  How do revoking and rotating
>> keys work?
>>
>> It was a deliberate design decision to let PGP infrastructure that is
>> used to sign and verify signatures when we use PGP for signing without
>> tying any of these decisions to the tracked contents, as that would
>> reduce the attack surface for a malicious tree contents to affect the
>> signing and verification (in other words, "we punted"
>> ;-).  Even though I am not sure exactly what you meant by "defaults to
>> .gitsigners", I am assuming that you meant a file with the name at the
>> top-level of the working tree, which makes me worried, as it opens us
>> to the risk of reading from and blindly trusting whatever somebody
>> else placed in the tree contents immediately after we "git pull" (or
>> "git clone").
>>
>> Thanks for working on it.
>Glad to hear that :)
>I tried to keep the style with the existing code but the IDE sometimes has its own idea.
>
>I think there are two basic options for maintaining the allowed signers
>file:
>1. Every developer has their own stored outside of the repo and adds/revokes trust manually like with gpg.
>     A central repo would probably verify against a list managed by the tool (e.g. gitolite) 2. Store it in a .gitsigners file in the repo. This
>would only work if you only allow signed commits/pushes from this point onwards. But this way a shared understading of trusted users can
>be maintained easily.
>     Only already trusted committers can add new users or change their own keys. The signers file is basically a ssh_authorized_keys file
>with an additional principal identifier added at the front like:
>     [email protected] ssh-rsa XXXKEYXXX Comment
>     [email protected] ssh-ed25519 XXXKEYXXX Comment
>
>Where are commits usually verified at the moment? On every devs checkout or only centrally on pushes?
>
>The signers file also supports SSH CA keys and wildcard identifiers. At the moment i look up the principal dynamically via the public key so
>it's just a text info of who's key is it at the moment.
>The SSH CA Stuff is probably a niche use case but could be cool in a corporate setting. Thats also what the revocation file is used for. The
>SSH CA can generate a KRL (like crl) which you put into it or you can specify explicit public keys in it to deny them.

Just musing here... If adding SSH CA, would not adding support for a self-signed SSL CA make sense? In such a situation, a self-signed certificate can be created at an organizational level, or even from an official root CA. Per-user self-signed certificates, or organizationally defined CAs and certificates, could be created that are more stable than SSH CAs. Then something like OpenSSL (via libcurl) could handle the signature and validation management. Signed content could propagate to Cloud-based git servers and retain their ability to be property verified. Although I can see a drawback here, which relates to expiring certificates - although the concept of an expired signed content is somewhat compelling. Imaging the use case where a company has an employee who signs a tag/commit. The employee departs/retires/terminated/etc., and with it the published certificate is also revoked - an extreme case perhaps, but if the code can no longer be trusted by virtue of the termination, maybe t
 his is semantically interesting. This could be a core git function with no additional dependencies.

Regards,
Randall

User "Randall S. Becker" <[email protected]> has been added to the cc: list.

On the Git mailing list, Bagas Sanjaya wrote (reply to this):

On 06/07/21 15.19, Fabian Stelzer via GitGitGadget wrote:
> From: Fabian Stelzer <[email protected]>
> 
> set gpg.format = ssh and user.signingkey to a ssh public key string (like from an
> authorized_keys file) and commits/tags can be signed using the private
> key from your ssh-agent.
> 
> Verification uses a allowed_signers_file (see ssh-keygen(1)) which
> defaults to .gitsigners but can be set via gpg.ssh.allowedsigners
> A possible gpg.ssh.revocationfile is also passed to ssh-keygen on
> verification.
> 
> needs openssh>8.2p1
> 

Why did you choose to implement SSH-based signing as GPG interface? Why 
not create similar one?

If at later times we need to implement other signing methods (besides 
GPG and SSH), we can refactor gpg-interface into generic signing 
interface (say `signing.h`) and let each signing methods implement from it.

-- 
An old man doll... just what I always wanted! - Clara

This patch series was integrated into seen via 6644bfa.

This patch series was integrated into seen via b4cdaff.

This patch series was integrated into seen via d223894.

This patch series was integrated into seen via d68e1db.

This patch series was integrated into seen via eea5288.

This patch series was integrated into seen via 84830d9.