Re: ssh signing: valid-before is checked at the signer's own date, and a missing revocationFile fails open

[Patrick Steinhardt <ps@pks.im>]

On Thu, Oct 08, 2026 at 02:42:42PM +0100, Phillip Wood wrote:
> Hi Christian
> 
> 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.

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.

> (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.

Patrick