From: Phillip Wood Date: Fri, 09 Oct 2026 13:30:03 GMT Subject: Re: ssh signing: valid-before is checked at the signer's own date, and a missing revocationFile fails open Message-ID: <0a63a10d-aa9d-4997-888e-2fda82802f59@gmail.com> In-Reply-To: Hi Patrick On 09/10/2026 13:19, Patrick Steinhardt wrote: > On Thu, Oct 08, 2026 at 02:42:42PM +0100, Phillip Wood wrote: >> >> Having waded through this here is a human readable summary: > > thanks a lot for the summary, I really appreciate it as I already lost > interest after having read the first sentence. > >> (1) Our documentation implies that we check the expiry date of the key >> (which is recorded in the allowed signers file) against the date the commit >> was signed, but we actually use the committer date which can easily be >> faked. > > Right. I think there isn't even a proper fix for this as we have no way > to establish the actual time the data was signed. I think this is a > simple fact in a distributed system, as without coordination there is > basically nothing that the contributor can give us that would make us > trust the claimed signature time. Indeed > You may be able to create upper bounds if there are subsequent signed > commits that you trust and that have the untrusted commit as child. But > that is not going to be always useful. Yes, on its own checking the signature just tells you that the commit was signed by that key, it does not tell you when it was signed. >> (2) If the revocation file does not exist we print a warning rather than >> failing the operation like the gpg backend does. >> >> For (1) I'd be happy to see a patch that tightens the wording, but we should >> also note that the timestamp in the gpg signature can also be faked. > > Yeah, agreed. This mode is only safe if the signing key has never > leaked, but once it has leaked you can basically not guarantee anything > via "valid-before" and "valid-after". And documenting that would be a > good idea to not give a sense of false trustworthiness. > >> For (2) I agree failing seems like the safer option. > > Maybe this is another usecase where we can use the ":(optional)" prefix > that we introduced recently for some of the other pathname options? So > we'd fail by default, but give the user an escape hatch if they really > want one. Oh, I'd not though of that - that's a good idea Thanks Phillip