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

From: Patrick Steinhardt <ps@pks.im>
Date: Oct 9, 2026, 12:19 UTC
Message-ID: <asjbyBvnFuYuE0CH@pks.im>
In-Reply-To: <ec4de165-c7d1-43d9-979b-08c1cb67022d@gmail.com>

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.

Show 5 quoted lines

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