undefined | Better HN

0 pointsCookieMon8y ago0 comments

I imagine someone went to a site like this:

https://msdn.microsoft.com/en-us/library/windows/desktop/aa3...

read the command for signing their code, and signed their code as instructed.

Today, the certificate they signed a driver with expired, and because the signature wasn't timestamped it means Windows can't know if the driver was signed with the certificate after it expired, so the signature is now treated as expired as well, so Windows doesn't trust the driver.

Why wasn't it timestamped? Probably because instructions like the link above treat that as a separate subject to signing your code, and when you sign your code it looks and works like it's fully correctly signed.

or, as wtallis puts it (https://news.ycombinator.com/item?id=16542204), someone left a foot-gun lying around that didn't have much value except to cause incidents like this.

...and if your own company makes Windows apps, go check they are timestamped ;)

0 comments

tallanvor8y ago

Your same link also explains how to sign a file with a timestamp as well, and contains a link on how to add a timestamp after the fact. It doesn't pretend to know what the best practice is for your specific use case of the signing tool is.

But you can also find places where Microsoft does talk about when you should be timestamping: https://blogs.msdn.microsoft.com/ieinternals/2011/03/22/ever...

CookieMonOP8y ago

> Your same link also explains how to sign a file with a timestamp as well

Sure, further down it explains how to use signtool to timestamp something, but why would someone trying to get an app signed care about using the tool for timestamping?

> where Microsoft does talk about when you should be timestamping

If someone finds that article first, and reads to the bottom of it, it explains that timestamping is related and important and says the times you should be timestamping are "you should definitely do this", so perhaps a design that isn't a foot-gun would have "do this" as the default, with a --force option and alarmist warnings for anybody who has a reason to have their signed executables expire one day.

Design oversights and user mistakes like these will happen, but it doesn't mean influences and causes can't be identified and improved.

(most of the builds at the company I work for had not been timestamped either)

j / k navigate · click thread line to collapse