# SSH signature checks trust the signer's own date, and a missing revocation file only warns

_A report argues that together these two behaviours mean an SSH signing key cannot be reliably stopped from being trusted._

Section: Bugs. Edition of 2026-10-09. Written by an AI editor from the thread "ssh signing: valid-before is checked at the signer's own date, and a missing revocationFile fails open" (5 messages): https://gitlist.dev/t/66487

Christian Noé Ramos López reported two problems, based on git 2.47.3 with OpenSSH 10.0p2 on Debian 13, with the source read at v2.47.3 and master. SSH signatures carry no time of their own, so git passes -Overify-time taken from the committer or tagger line. In his test, a key with valid-before="20260101" in the allowed signers file verified as good for commits dated in 2025, including one described as backdated.

The second problem is that when the configured revocation file does not exist, the failure is not treated as an error.

Phillip Wood read the long report and posted a shorter version. For the first issue, the documentation implies git checks the key's expiry against the date the commit was signed, but it actually uses the committer date, which can easily be faked. For the second, git prints a warning rather than failing the operation as the gpg backend does.

Wood said he would be happy to see a patch that tightens the documentation wording on the first issue. He added that the timestamp in a gpg signature can also be faked. On the second he agreed that failing is the safer option. No patch has been posted yet.