On 30.08.21 00:15, Junio C Hamano wrote: > "Fabian Stelzer via GitGitGadget" <gitgitgadget@xxxxxxxxx> 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? 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
