There was an incomplete issue report that our binaries code signing certificate has expired.
That is perfectly valid point. The Microsoft Azure code signing service is using short-lived certificates (3 days). It is the timestamp that asserts "this binary was signed at that time" and Windows honors the timestamp time when evaluating binary trust.
However, since the code signing and timestamping modifies existing binary, the Makefile build system might overlook when previous build created the binary, but signing and timestamping failed. On second run the build system sees the binary is already built, its timestamp is newer than dependencies, hence no building or code signing is required.
Rework the build process to depend on explicit code-signing and timestamping artifact that is not generated until after the code-signing and timestamping succeeds.
There was an incomplete issue report that our binaries code signing certificate has expired.
That is perfectly valid point. The Microsoft Azure code signing service is using short-lived certificates (3 days). It is the timestamp that asserts "this binary was signed at that time" and Windows honors the timestamp time when evaluating binary trust.
However, since the code signing and timestamping modifies existing binary, the Makefile build system might overlook when previous build created the binary, but signing and timestamping failed. On second run the build system sees the binary is already built, its timestamp is newer than dependencies, hence no building or code signing is required.
Rework the build process to depend on explicit code-signing and timestamping artifact that is not generated until after the code-signing and timestamping succeeds.