"Fabian Stelzer via GitGitGadget" [off-list ref] writes:
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.
Has this follow-on work happened already?
The previous rounds saw enough reviews and responses, but this round
didn't. Usually no response means no interest from the community,
but let's see if somebody other than the author actually tried the
feature, and and want to tell us about their experience, either
positive or negative?
As the basic step of the topic, possibly to be built upon laster, I
am tempted to say that this v7 may want to be cooked in 'next' for
wider exposure.
I'll typofix the topmost commit before doing so, though.
Thanks.
1: 4ff5911494 ! 1: b88bcd013b ssh signing: test that gpg fails for unkown keys
@@ Metadata
Author: Fabian Stelzer [off-list ref]
## Commit message ##
- ssh signing: test that gpg fails for unkown keys
+ ssh signing: test that gpg fails for unknown keys
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
On 2021-08-29 15:15:15-0700, Junio C Hamano wrote:
The previous rounds saw enough reviews and responses, but this round
didn't. Usually no response means no interest from the community,
but let's see if somebody other than the author actually tried the
feature, and and want to tell us about their experience, either
positive or negative?
I've been using this feature (including this round) on and off and I've
been happy with it. I ran into a small bug in an earlier version which
has since been fixed, but other than that I haven't had any issues. The
setup and use is all pretty easy.
Admittedly, I haven't been daily-driving this feature, as I didn't want
to put SSH-signed commits in repositories in case the format changes in
the future.
On 30.08.21 00:15, Junio C Hamano wrote:
"Fabian Stelzer via GitGitGadget" [off-list ref] writes:
quoted
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.
Has this follow-on work happened already?
I have this prepared but not ready for submission. I wanted to wait
until openssh 8.7 is released (which happened recently) to make sure
their api for this newly added feature does not change.
I will be on vacation for the next 2 weeks but can submit it afterwards.
I have a few additional features in mind but wanted to wait for the
basic functionality to settle before piling stuff on top.
I'd like to add a "Trust on First Use" mode that will add keys to your
allowedSIgners File when encountered the first time (this could very
similar to how .ssh/known/hosts works).
The idea came from here: https://lwn.net/Articles/803619/
Also signing support for git format-patch/am would be nice (ssh
signatures are much smaller then gpg and shouldnt be too bad in emails.
Not as minimal as minisign but with easier/more established key handling)
The previous rounds saw enough reviews and responses, but this round
didn't. Usually no response means no interest from the community,
but let's see if somebody other than the author actually tried the
feature, and and want to tell us about their experience, either
positive or negative?
I will roll this out to our corporate env after my vacation but can
understand that people are hesitant to push commits with it since older
git versions will BUG() on verification of the new signatures.
But at least github handles it well ("GitHub supports GPG and S/MIME
signatures. We don’t know what type of signature this is."). I have not
tested with other Forges yet.
As the basic step of the topic, possibly to be built upon laster, I
am tempted to say that this v7 may want to be cooked in 'next' for
wider exposure.
I'll typofix the topmost commit before doing so, though.
Thanks