Closed ganesh-getweave closed 8 months ago
Yes, the files are signed at a different time, so the resulting signature is different even though the signature algorithm used by authenticode is deterministic.
Removing the signing time attribute would help here, it isn't required and harms the reproducibilty. The issue remains for the counter signature though.
Removing the signing time attribute would help here, it isn't required and harms the reproducibilty.
Reproducibility is not an expected feature of digital signatures.
The issue remains for the counter signature though.
Can you clarify, please?
Reproducibility is not an expected feature of digital signatures
Reproducible builds are important, even when digital signatures are involved. The solution is to store the signature in a file which is shipped along the source release (either a tarball or in a tagged git repository). When rebuilding the project the signing process imports the detached signature from the file instead of generating a new signature.
Reproducible builds are only useful for third parties (not for yourself), thus they require a production signature that does not expire. For the signature to remain valid beyond the expiration of its signing certificate, it needs to include a timestamp. By definition, this timestamp is not reproducible by third parties at a different point in time.
The idea is to export the signature with the counter signature, the full PKCS#7 structure basically. That way the signed+timestamped binary is reproducible.
If you copy the entire signature from a previous executable then you don't need signing with osslsigncode.
It's more of a doubt, I was comparing the signed files.
steps to re-produce..
Use the
osslsigncode
CLI Create two signed files with the same inputs( same exe file, certs, passkey, etc.,) Compare the two signed files usingdiff
CLIThe
diff
tool returns a message that they differ.Confirm for me, if the tool generates the same signed files when the inputs are same.