ssh signing: Add commit & tag signing/verification via SSH keys using ssh-keygen #1041
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Welcome to GitGitGadgetHi @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:
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 patchesBefore 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 Both the person who commented An alternative is the channel Once on the list of permitted usernames, you can contribute the patches to the Git mailing list by adding a PR comment If you want to see what email(s) would be sent for a 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 curl -g --user "<EMailAddress>:<Password>" \
--url "imaps://imap.gmail.com/INBOX" -T /path/to/raw.txtTo 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): To send a new iteration, just add another PR comment with the contents: Need help?New contributors who want advice are encouraged to join git-mentoring@googlegroups.com, 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, |
FStelzer
changed the title
|
@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? |
dscho
reviewed
Jul 5, 2021
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. |
|
/allow |
|
User FStelzer is now allowed to use GitGitGadget. WARNING: FStelzer has no public email address set on GitHub |
FStelzer
force-pushed
the
sshsign
branch
3 times, most recently
from
bb908de to
f238392
Compare
|
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. |
|
/submit |
|
Submitted as pull.1041.git.git.1625559593910.gitgitgadget@gmail.com To fetch this version into To fetch this version to local tag WARNING: FStelzer has no public email address set on GitHub |
|
On the Git mailing list, Han-Wen Nienhuys wrote (reply to this): |
|
User |
|
On the Git mailing list, Fabian Stelzer wrote (reply to this): |
|
User |
|
On the Git mailing list, "brian m. carlson" wrote (reply to this): |
|
User |
|
On the Git mailing list, Junio C Hamano wrote (reply to this): |
|
On the Git mailing list, Fabian Stelzer wrote (reply to this): |
|
On the Git mailing list, Fabian Stelzer wrote (reply to this): |
|
On the Git mailing list, Junio C Hamano wrote (reply to this): |
|
On the Git mailing list, "Randall S. Becker" wrote (reply to this): |
|
User |
|
On the Git mailing list, Bagas Sanjaya wrote (reply to this): |
|
This patch series was integrated into seen via 3b617a7. |
|
This patch series was integrated into seen via 2dc5b3e. |
|
There was a status update in the "Cooking" section about the branch Use ssh public crypto for object and push-cert signing. Will merge to 'master'. |
|
This patch series was integrated into seen via 0c42282. |
|
This patch series was integrated into seen via df380c9. |
|
This patch series was integrated into seen via 18c6653. |
|
This patch series was integrated into next via 18c6653. |
|
This patch series was integrated into master via 18c6653. |
|
Closed via 18c6653. |
|
@FStelzer thank you for this work! I tried it out today but it doesn't work for me. This is because it assumes that ssh keys always start with |
@philandstuff thanks for your report. You are correct that i did not consider this for literal keys and the defaultKeysCommand. I'll fix this with an upcoming release. For now you can simply work around it by specifying a file with your public key in it for user.signingkey instead of the literal public key. |
|
FYI "ssh -Q key" will list all the supported SSH key types if you want to
add the remaining ones. Note the sk-* types for FIDO keys too
…On Wed, 17 Nov 2021 at 21:07, Fabian Stelzer ***@***.***> wrote:
@FStelzer <https://github.com/FStelzer> thank you for this work! I tried
it out today but it doesn't work for me. This is because it assumes that
ssh keys always start with ssh- but mine has type ecdsa-sha2-nistp256
(specified in RFC 5656).
@philandstuff <https://github.com/philandstuff> thanks for your report.
You are correct that i did not consider this for literal keys and the
defaultKeysCommand. I'll fix this with an upcoming release. For now you can
simply work around it by specifying a file with your public key in it for
user.signingkey instead of the literal public key.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#1041 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABJSKM2DCW4ROKN4GH6LETUMN5GZANCNFSM472SIWSQ>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
|
Thanks :)
|
|
@FStelzer thanks for the workaround! I can confirm that works for me 👍 |
![gitgitgadget-git[bot]](https://avatars.githubusercontent.com/in/46807?s=60&v=4){kind=small}
| @@ -71,7 +71,25 @@ test_expect_success GPG 'create signed commits' ' | |||
| git tag eleventh-signed $(cat oid) && | |||
There was a problem hiding this comment.
On the Git mailing list, Ævar Arnfjörð Bjarmason wrote (reply to this):
On Fri, Sep 10 2021, Fabian Stelzer via GitGitGadget wrote:
> From: Fabian Stelzer <fs@gigacodes.de>
>
> Test that verify-commit/tag will fail when a gpg key is completely
> unknown. To do this we have to generate a key, use it for a signature
> and delete it from our keyring aferwards completely.
>
> Signed-off-by: Fabian Stelzer <fs@gigacodes.de>
> ---
> t/t7510-signed-commit.sh | 29 ++++++++++++++++++++++++++++-
> 1 file changed, 28 insertions(+), 1 deletion(-)
>
> diff --git a/t/t7510-signed-commit.sh b/t/t7510-signed-commit.sh
> index 8df5a74f1db..d65a0171f29 100755
> --- a/t/t7510-signed-commit.sh
> +++ b/t/t7510-signed-commit.sh
> @@ -71,7 +71,25 @@ test_expect_success GPG 'create signed commits' '
> git tag eleventh-signed $(cat oid) &&
> echo 12 | git commit-tree --gpg-sign=B7227189 HEAD^{tree} >oid &&
> test_line_count = 1 oid &&
> - git tag twelfth-signed-alt $(cat oid)
> + git tag twelfth-signed-alt $(cat oid) &&
> +
> + cat >keydetails <<-\EOF &&
> + Key-Type: RSA
> + Key-Length: 2048
> + Subkey-Type: RSA
> + Subkey-Length: 2048
> + Name-Real: Unknown User
> + Name-Email: unknown@git.com
> + Expire-Date: 0
> + %no-ask-passphrase
> + %no-protection
> + EOF
> + gpg --batch --gen-key keydetails &&
> + echo 13 >file && git commit -a -S"unknown@git.com" -m thirteenth &&
> + git tag thirteenth-signed &&
> + DELETE_FINGERPRINT=$(gpg -K --with-colons --fingerprint --batch unknown@git.com | grep "^fpr" | head -n 1 | awk -F ":" "{print \$10;}") &&
> + gpg --batch --yes --delete-secret-keys $DELETE_FINGERPRINT &&
> + gpg --batch --yes --delete-keys unknown@git.com
> '
>
> test_expect_success GPG 'verify and show signatures' '
> @@ -110,6 +128,13 @@ test_expect_success GPG 'verify and show signatures' '
> )
> '
>
> +test_expect_success GPG 'verify-commit exits failure on unknown signature' '
> + test_must_fail git verify-commit thirteenth-signed 2>actual &&
> + ! grep "Good signature from" actual &&
> + ! grep "BAD signature from" actual &&
> + grep -q -F -e "No public key" -e "public key not found" actual
> +'
> +
> test_expect_success GPG 'verify-commit exits success on untrusted signature' '
> git verify-commit eighth-signed-alt 2>actual &&
> grep "Good signature from" actual &&
> @@ -338,6 +363,8 @@ test_expect_success GPG 'show double signature with custom format' '
> '
>
>
> +# NEEDSWORK: This test relies on the test_tick commit/author dates from the first
> +# 'create signed commits' test even though it creates its own
> test_expect_success GPG 'verify-commit verifies multiply signed commits' '
> git init multiply-signed &&
> cd multiply-signed &&
The t7510-signed-commit.sh script hangs on startup with this change, and
with -vx we show:
[...]
++ git tag twelfth-signed-alt 17f06d503ee50df92746c17f6cced6feb5940cf5
++ cat
++ gpg --batch --gen-key keydetails
gpg: skipping control `%no-protection' ()
This is on a CentOS 7.9 box on the GCC Farm:
[avar@gcc135 t]$ uname -a ; gpg --version
Linux gcc135.osuosl.org 4.18.0-80.7.2.el7.ppc64le #1 SMP Thu Sep 12 15:45:05 UTC 2019 ppc64le ppc64le ppc64le GNU/Linux
gpg (GnuPG) 2.0.22
libgcrypt 1.5.3
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Home: ~/.gnupg
Supported algorithms:
Pubkey: RSA, ?, ?, ELG, DSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2
There was a problem hiding this comment.
On the Git mailing list, Fabian Stelzer wrote (reply to this):
On 22.12.2021 04:18, Ævar Arnfjörð Bjarmason wrote:
>
>On Fri, Sep 10 2021, Fabian Stelzer via GitGitGadget wrote:
>
>> From: Fabian Stelzer <fs@gigacodes.de>
>>
>> Test that verify-commit/tag will fail when a gpg key is completely
>> unknown. To do this we have to generate a key, use it for a signature
>> and delete it from our keyring aferwards completely.
>>
>> Signed-off-by: Fabian Stelzer <fs@gigacodes.de>
>> +
>> + cat >keydetails <<-\EOF &&
>> + Key-Type: RSA
>> + Key-Length: 2048
>> + Subkey-Type: RSA
>> + Subkey-Length: 2048
>> + Name-Real: Unknown User
>> + Name-Email: unknown@git.com
>> + Expire-Date: 0
>> + %no-ask-passphrase
>> + %no-protection
>> + EOF
>> + gpg --batch --gen-key keydetails &&
>>
>The t7510-signed-commit.sh script hangs on startup with this change, and
>with -vx we show:
>
> [...]
> ++ git tag twelfth-signed-alt 17f06d503ee50df92746c17f6cced6feb5940cf5
> ++ cat
> ++ gpg --batch --gen-key keydetails
> gpg: skipping control `%no-protection' ()
>
>This is on a CentOS 7.9 box on the GCC Farm:
>
> [avar@gcc135 t]$ uname -a ; gpg --version
> Linux gcc135.osuosl.org 4.18.0-80.7.2.el7.ppc64le #1 SMP Thu Sep 12 15:45:05 UTC 2019 ppc64le ppc64le ppc64le GNU/Linux
> gpg (GnuPG) 2.0.22
> libgcrypt 1.5.3
> Copyright (C) 2013 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
>
> Home: ~/.gnupg
> Supported algorithms:
> Pubkey: RSA, ?, ?, ELG, DSA
> Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
> CAMELLIA128, CAMELLIA192, CAMELLIA256
> Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
> Compression: Uncompressed, ZIP, ZLIB, BZIP2
Hm. I have an identical centos 7.9 installation (same versions/features) and
the key is generated without issues. Does the VM maybe have not enough
entropy for generating a gpg key?
Otherwise we could of course pre-generate the key and commit it. I'm usually
not a fan of this since over time it can become unclear how it was generated
or if the committed version still matches what would be generated today.
But of course I don't want to slow down CI with rsa key generation stuff :/
If missing entropy is the problem, then maybe CI could benefit from
something like haveged in general (other tests might want more entropy too).
There was a problem hiding this comment.
On the Git mailing list, "brian m. carlson" wrote (reply to this):
--kYlysQi8OJ63EbgD
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On 2021-12-22 at 10:13:26, Fabian Stelzer wrote:
> Hm. I have an identical centos 7.9 installation (same versions/features) =
and
> the key is generated without issues. Does the VM maybe have not enough
> entropy for generating a gpg key?
> Otherwise we could of course pre-generate the key and commit it. I'm usua=
lly
> not a fan of this since over time it can become unclear how it was genera=
ted
> or if the committed version still matches what would be generated today.
> But of course I don't want to slow down CI with rsa key generation stuff =
:/
> If missing entropy is the problem, then maybe CI could benefit from
> something like haveged in general (other tests might want more entropy to=
o).
GnuPG is notorious for using /dev/random for generating keys, so yes,
this is likely to block in a variety of situations. We don't see this
on newer systems because they've replaced the blocking /dev/random with
a non-blocking one except for when the CSPRNG hasn't been seeded at
least once.
The problem isn't lack of entropy, but the fact that there's no reason
to use /dev/random since /dev/urandom is suitable for all cryptographic
needs once initialized. On modern versions of Linux, one just uses
getrandom(2), which deals with the uninitialized case and otherwise
doesn't block. However, CentOS 7 is old.
--=20
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA
--kYlysQi8OJ63EbgD
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.3.1 (GNU/Linux)
iHUEABYKAB0WIQQILOaKnbxl+4PRw5F8DEliiIeigQUCYcNLOQAKCRB8DEliiIei
gYK+AP4vhD8AziOxs7MpvM5XjmmUKikkjmsmugfOZIUT3VLGXgEA9IezWgX1MCXm
medAEjKF4nqOtEmgXAhiTE9AVcedPQo=
=mNPo
-----END PGP SIGNATURE-----
--kYlysQi8OJ63EbgD--
There was a problem hiding this comment.
On the Git mailing list, Ævar Arnfjörð Bjarmason wrote (reply to this):
On Wed, Dec 22 2021, Fabian Stelzer wrote:
> On 22.12.2021 04:18, Ævar Arnfjörð Bjarmason wrote:
>>
>>On Fri, Sep 10 2021, Fabian Stelzer via GitGitGadget wrote:
>>
>>> From: Fabian Stelzer <fs@gigacodes.de>
>>>
>>> Test that verify-commit/tag will fail when a gpg key is completely
>>> unknown. To do this we have to generate a key, use it for a signature
>>> and delete it from our keyring aferwards completely.
>>>
>>> Signed-off-by: Fabian Stelzer <fs@gigacodes.de>
>>> +
>>> + cat >keydetails <<-\EOF &&
>>> + Key-Type: RSA
>>> + Key-Length: 2048
>>> + Subkey-Type: RSA
>>> + Subkey-Length: 2048
>>> + Name-Real: Unknown User
>>> + Name-Email: unknown@git.com
>>> + Expire-Date: 0
>>> + %no-ask-passphrase
>>> + %no-protection
>>> + EOF
>>> + gpg --batch --gen-key keydetails &&
>>>
>>The t7510-signed-commit.sh script hangs on startup with this change, and
>>with -vx we show:
>>
>> [...]
>> ++ git tag twelfth-signed-alt 17f06d503ee50df92746c17f6cced6feb5940cf5
>> ++ cat
>> ++ gpg --batch --gen-key keydetails
>> gpg: skipping control `%no-protection' ()
>>
>>This is on a CentOS 7.9 box on the GCC Farm:
>>
>> [avar@gcc135 t]$ uname -a ; gpg --version
>> Linux gcc135.osuosl.org 4.18.0-80.7.2.el7.ppc64le #1 SMP Thu Sep 12 15:45:05 UTC 2019 ppc64le ppc64le ppc64le GNU/Linux
>> gpg (GnuPG) 2.0.22
>> libgcrypt 1.5.3
>> Copyright (C) 2013 Free Software Foundation, Inc.
>> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law.
>>
>> Home: ~/.gnupg
>> Supported algorithms:
>> Pubkey: RSA, ?, ?, ELG, DSA
>> Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
>> CAMELLIA128, CAMELLIA192, CAMELLIA256
>> Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
>> Compression: Uncompressed, ZIP, ZLIB, BZIP2
>
> Hm. I have an identical centos 7.9 installation (same
> versions/features) and the key is generated without issues. Does the
> VM maybe have not enough entropy for generating a gpg key?
> Otherwise we could of course pre-generate the key and commit it. I'm
> usually not a fan of this since over time it can become unclear how it
> was generated or if the committed version still matches what would be
> generated today.
> But of course I don't want to slow down CI with rsa key generation stuff :/
> If missing entropy is the problem, then maybe CI could benefit from
> something like haveged in general (other tests might want more entropy
> too).
Late reply. It's not a VM, but yes. I've confirmed that it's due to
/dev/random hanging.
I don't understand why we need to generate a key at all.
It looks like your 1bfb57f642d (ssh signing: test that gpg fails for
unknown keys, 2021-09-10) is just trying to test the case where we sign
with a key, and then don't have that key anymore.
The below POC patch seems to work just as well, and will succeed with:
./t7510-signed-commit.sh --run=1,3
Of course a lot of other tests now fail, because they relied on the
discord@example.net key.
But that seems easily solved by just moving this test to its own file,
or deleting/re-importing the key for just that test or whatever. If we
truly need yet another key why are we making it on the fly instead of
adding it to t/lib-gpg/keyring.gpg like the others?
diff --git a/t/t7510-signed-commit.sh b/t/t7510-signed-commit.sh
index 9882b69ae29..eec2a045cbc 100755
--- a/t/t7510-signed-commit.sh
+++ b/t/t7510-signed-commit.sh
@@ -73,23 +73,11 @@ test_expect_success GPG 'create signed commits' '
test_line_count = 1 oid &&
git tag twelfth-signed-alt $(cat oid) &&
- cat >keydetails <<-\EOF &&
- Key-Type: RSA
- Key-Length: 2048
- Subkey-Type: RSA
- Subkey-Length: 2048
- Name-Real: Unknown User
- Name-Email: unknown@git.com
- Expire-Date: 0
- %no-ask-passphrase
- %no-protection
- EOF
- gpg --batch --gen-key keydetails &&
- echo 13 >file && git commit -a -S"unknown@git.com" -m thirteenth &&
+ echo 13 >file && git commit -a -S"discord@example.net" -m thirteenth &&
git tag thirteenth-signed &&
- DELETE_FINGERPRINT=$(gpg -K --with-colons --fingerprint --batch unknown@git.com | grep "^fpr" | head -n 1 | awk -F ":" "{print \$10;}") &&
+ DELETE_FINGERPRINT=$(gpg -K --with-colons --fingerprint --batch discord@example.net | grep "^fpr" | head -n 1 | awk -F ":" "{print \$10;}") &&
gpg --batch --yes --delete-secret-keys $DELETE_FINGERPRINT &&
- gpg --batch --yes --delete-keys unknown@git.com
+ gpg --batch --yes --delete-keys discord@example.net
'
test_expect_success GPG 'verify and show signatures' '
There was a problem hiding this comment.
On the Git mailing list, Fabian Stelzer wrote (reply to this):
On 26.12.2021 23:53, Ævar Arnfjörð Bjarmason wrote:
>>
>> Hm. I have an identical centos 7.9 installation (same
>> versions/features) and the key is generated without issues. Does the
>> VM maybe have not enough entropy for generating a gpg key?
>> Otherwise we could of course pre-generate the key and commit it. I'm
>> usually not a fan of this since over time it can become unclear how it
>> was generated or if the committed version still matches what would be
>> generated today.
>> But of course I don't want to slow down CI with rsa key generation stuff :/
>> If missing entropy is the problem, then maybe CI could benefit from
>> something like haveged in general (other tests might want more entropy
>> too).
>
>Late reply. It's not a VM, but yes. I've confirmed that it's due to
>/dev/random hanging.
>
>I don't understand why we need to generate a key at all.
You are right, we don't need to. I initially toyed with the GPG commands to
disable/export/reimport a key but without success (I'm not terribly familiar
with GPG though).
>
>It looks like your 1bfb57f642d (ssh signing: test that gpg fails for
>unknown keys, 2021-09-10) is just trying to test the case where we sign
>with a key, and then don't have that key anymore.
>
It tests verifying a commit for which the key is not in our keyring at all.
All the other tests only use present keys (with varying trust levels) or
completely unsigned commits for the failure check.
I think we could do the following though and simply point git to an empty
keyring to be able to verify this:
diff --git a/t/t7510-signed-commit.sh b/t/t7510-signed-commit.sh
index 9882b69ae2..2d38580847 100755
--- a/t/t7510-signed-commit.sh
+++ b/t/t7510-signed-commit.sh
@@ -71,25 +71,7 @@ test_expect_success GPG 'create signed commits' '
git tag eleventh-signed $(cat oid) &&
echo 12 | git commit-tree --gpg-sign=B7227189 HEAD^{tree} >oid &&
test_line_count = 1 oid &&
- git tag twelfth-signed-alt $(cat oid) &&
-
- cat >keydetails <<-\EOF &&
- Key-Type: RSA
- Key-Length: 2048
- Subkey-Type: RSA
- Subkey-Length: 2048
- Name-Real: Unknown User
- Name-Email: unknown@git.com
- Expire-Date: 0
- %no-ask-passphrase
- %no-protection
- EOF
- gpg --batch --gen-key keydetails &&
- echo 13 >file && git commit -a -S"unknown@git.com" -m thirteenth &&
- git tag thirteenth-signed &&
- DELETE_FINGERPRINT=$(gpg -K --with-colons --fingerprint --batch unknown@git.com | grep "^fpr" | head -n 1 | awk -F ":" "{print \$10;}") &&
- gpg --batch --yes --delete-secret-keys $DELETE_FINGERPRINT &&
- gpg --batch --yes --delete-keys unknown@git.com
+ git tag twelfth-signed-alt $(cat oid)
'
test_expect_success GPG 'verify and show signatures' '
@@ -129,7 +111,7 @@ test_expect_success GPG 'verify and show signatures' '
'
test_expect_success GPG 'verify-commit exits failure on unknown signature' '
- test_must_fail git verify-commit thirteenth-signed 2>actual &&
+ GNUPGHOME=./empty_home test_must_fail git verify-commit initial 2>actual &&
! grep "Good signature from" actual &&
! grep "BAD signature from" actual &&
grep -q -F -e "No public key" -e "public key not found" actual
|
User |
|
User |
alindeman
added a commit
to alindeman/git
that referenced
this pull request
May 30, 2022
Keys generated using `ssh-keygen -t ecdsa` or similar will be rejected as literal SSH keys because the prefix is `ecdsa-sha2-nistp256`, `ecdsa-sha2-nistp384` or `ecdsa-sha2-nistp521`. This was acknowledged as an issue [1] in the past, but hasn't yet been fixed. [1]: git#1041 (comment)
alindeman
added a commit
to alindeman/git
that referenced
this pull request
May 30, 2022
Keys generated using `ssh-keygen -t ecdsa` or similar will be rejected as literal SSH keys because the prefix is `ecdsa-sha2-nistp256`, `ecdsa-sha2-nistp384` or `ecdsa-sha2-nistp521`. This was acknowledged as an issue [1] in the past, but hasn't yet been fixed. [1]: git#1041 (comment) Signed-off-by: Andy Lindeman <andy@lindeman.io>
alindeman
added a commit
to alindeman/git
that referenced
this pull request
May 30, 2022
Keys generated using `ssh-keygen -t ecdsa` or similar are being rejected as literal SSH keys because the prefix is `ecdsa-sha2-nistp256`, `ecdsa-sha2-nistp384` or `ecdsa-sha2-nistp521`. This was acknowledged as an issue [1] in the past, but hasn't yet been fixed. [1]: git#1041 (comment) Signed-off-by: Andy Lindeman <andy@lindeman.io>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
v7:
v8:
cc: Han-Wen Nienhuys hanwen@google.com
cc: Fabian Stelzer fs@gigacodes.de
cc: "brian m. carlson" sandals@crustytoothpaste.net
cc: "Randall S. Becker" rsbecker@nexbridge.com
cc: Bagas Sanjaya bagasdotme@gmail.com
cc: Hans Jerry Illikainen hji@dyntopia.com
cc: Ævar Arnfjörð Bjarmason avarab@gmail.com
cc: Felipe Contreras felipe.contreras@gmail.com
cc: Eric Sunshine sunshine@sunshineco.com
cc: Gwyneth Morgan gwymor@tilde.club
cc: Jonathan Tan jonathantanmy@google.com
cc: Josh Steadmon steadmon@google.com
cc: Carlo Arenas carenas@gmail.com
cc: Fabian Stelzer fs@gigacodes.de
cc: Ævar Arnfjörð Bjarmason avarab@gmail.com
cc: "brian m. carlson" sandals@crustytoothpaste.net