This problem is deeper than forgetting to update it. It should never have caused a failure in the first place. Just the fact that the device apparently can't function at all without the internet is a problem too.
On the other hand, maybe this is really a lazy feature. It's probably a good idea for the system to disallow both incoming and outgoing network traffic to any program written in a non-memory-safe language that hasn't been signed in the past couple of years. The lazy version of this feature is just not to run any program not signed in the past couple of years.
Edit: Requiring a timestamped signature on the signature also makes it pretty easy to add auditing functionality to the timestamp server whereby the publisher can detect unauthorized signatures due to their private key being leaked/stolen by criminals or governments. If the timestamp server's logs show a signature by your key that you don't recognize, then something has gone wrong. On the attacker's side, they need to either steal the timestamp server's private key or publish their malicious signatures for scrutiny.
The "owner" is no longer in control, and has not been ever since the web became "app-ified".
Browsers could have bright red flashing lights telling users that they're currently being phished and users would still enter their credentials because doing nothing isn't seen as a meaningful alternative action.
Isn't Oculus owned by Facebook? Of course it has internet-based mandatory data collection, er uh excuse me, license something something.
Maybe I should have just given up the day Oculus dropped Linux support.
Except TLS certs. That's the whole point of those certs having an expiration date in the first place.
Cloud-based APIs aren't the only thing that's broken. Locally-installed code is being prevented from running.
It also won't let you refresh the page or close it since the certificate is expired.
That’s exactly how they are supposed to work. In the public sector we rely heavily on certificates for inter sector communication for instance, if certificates kept working despite being invalid it would put security at risk.
You’re supposed to build your software with an enterprise certificate store in mind though, meaning you can auto renew and distribute certicates when needed.
I really don’t see the point of adding a certificate to your television though, even if it is a tv that you wear on your head.
What's weird is sometimes they still link or require these docs to be downloaded and completed.
A bit worse, the constant password change requirements - thankfully the password helpdesks in public sector are so used to doing password resets that you can usually get a reset very easily just by giving a username if you are directly accessing a system (ie, internally so have access to helpdesk). The passwords can be crazy long though with 90 days expiration (senior folks write them down or give them to assistants). Some actually expire even without a login (they email you and say unless you login and change it will expire).
And for this to work at all, the signature needs a timestamp so that the OS can know that the certificate was valid at the time of signing.
But for some reason (signtool.exe, etc) makes it really hard to get this done properly.
This is especially true in a CI-setting, where this is one of those areas where signing and timestamping essentially makes a reliably and deterministic process (compiling code) into a unreliable and non-deterministic process, because builds can now fail randomly based on the state of a online timestamping service.
Getting this done properly is a lot more work than you at first would think.
I can see why lots of developers shy away from learning about this, even more so implementing it, when they can spend their time delivering value... And new builds which won't expire for another 2 years.
Why are you signing your drivers during development? If not, how is the "unreliability" of timestamping services an issue? You probably can't push your stuff to prod without timestamps anyway.
This kind of problem affects regular customer-facing applications too, and that's where I've worked hard to minimize the issues caused by the need for timestamping, while still doing things properly.
(That is, if timestamping fails, the build SHOULD fail)
You presumably don't need to sign your binaries during development, so you'll only be signing them when pushing updates to prod. I don't know how often and how urgently you usually do that, but it sounds like a small delay in pushing out prod builds caused by a timestamp server issue wouldn't be much of a problem to most orgs.
A website may depend on libraries, which depends on other libraries. They must all be signed. They are all interlinked against a known version during build, and signing them after linking may not be an option.
The website may offer a download, which is probably a setup file of sorts, which must be signed. It will of course contain binaries, which must be signed too.
The website itself may also be something packaged in another setup file, which too must be signed.
Now how do you “just” sign something like that before releasing to prod? You don’t.
Signing (and time stamping!) must be a intergrated part of every step of the build process.
It takes more work than you would expect to get this done properly, systematically and reliably for every part of your build process. It does take effort and expertise.
That said, for certain build-types (like pure CI) we disable things like timestamping. We’re not crazy :)
It doesn't take a lot more work than I think.
> But for some reason (signtool.exe, etc) makes it really hard to get this done properly.
In our experience, signtool doesn't make this "really hard to get this done properly". The CI for our primary product uses a remote server for timestamping at signing. While that server doesn't go down constantly, it does go down at least once a month. This is not an artifact of signtool but the vendor.
To have security it is far better to have something fail and not sign than to sign incorrectly. The opposite, get it done attitude at all costs, was the likely cause of this article having been written about Oculus. In this case the cost was signing something incorrectly, due to a misunderstanding of the very basics of certificates, and bricking the already working primary product of the company.
Microsoft has a mode for loading unsigned drivers. Every Windows developer should already know about this. If a junior developer without this knowledge is in control of a critical build process, that's the problem not signtool.
I've met far too many people who treat a lack of security knowledge as a positive or a badge of honor of some kind. It's not a positive, it's something undesirable and a loss-leader for employers.
Some might call this a feature.
https://msdn.microsoft.com/en-us/library/windows/desktop/bb9...
By default, this is currently enabled, as noted here: https://stackoverflow.com/questions/11712322/error-the-times...
You have to go out of your way when signing an app on macOS to disable timestamping in current OS versions.
I bet they use certificate pinning.
Process A launches process B and checks against a pinned certificate. This is even more secure than just using the windows code signing stuff.
Problem is, when their cert expired, they were supposed to renew the same cert. Instead, somebody got a new one and signed the build of process B.
The device automatically downloads process B, but then the certificate pin check fails when it tries to launch it.
All the security guides that tell you to do certificate pinning need flashing neon signs explaining this problem. You can't pin certs if you intend to ever change certs.