All of Oculus’s Rift headsets have stopped working due to an expired certificate • Hacker News Board

Re: All of Oculus’s Rift headsets have stopped working due to an expired certificate

#201

Post by Lewton » Thu, Mar 08, 2018, 9:48 AM UTC

moloch wrote: post #75

rock_hard wrote: post #54

Earlier quoted context omitted.

You realize that this is the only way to fund triple AAA content for the time being though, right? Oculus is producing these at a loss given the current size of the market hoping it will pay out in the long term by growing a healthy ecosystem...it’s the only way

Steam VR/Vive has "AAA" non-exclusive titles.

As a vive fanatic

"Built ground up for VR AAA titles" != "Adapted VR AAA titles"

I refuse to use revive to play any of these games because I don't want to support the exclusives, but I gotta admit that something like robo recall looks better than anything that's available on steam

Re: All of Oculus’s Rift headsets have stopped working due to an expired certificate

#202

Post by andreareina » Thu, Mar 08, 2018, 9:58 AM UTC

erikpukinskis wrote: post #144

adrianratnapala wrote: post #137

Earlier quoted context omitted.

The problem in this case is much deeper than their fault / your fault. The problem is that in this industry we do (have to?) lean too much on the power of abstraction. Whether you are writing SQL or graphics code you are constantly told "just express what you want to express directly, and the system is smart enough to do things as efficiently as possible". But that might not be very efficient at all. The people who w…

Yes, you’re talking about the proliferation of declarative APIs over explicit, imperative ones. My pet theory is that because we typically understand our needs before we understand the code paths required to fulfill them, our V1 APIs are usually a declarative “this is what should be” interface. Then we spend days or months making it happen and by the time we understand the required code paths, we’ve totally baked our…

I lean towards providing both -- high-level abstractions sufficient for the 90% built on lower-level abstractions that are available if needed.

Re: All of Oculus’s Rift headsets have stopped working due to an expired certificate

#203

Post by nbsd4lyfe » Thu, Mar 08, 2018, 9:58 AM UTC

ksrm wrote: post #196

nbsd4lyfe wrote: post #186

Earlier quoted context omitted.

Cairo is currently desperately asking for development help, so uhh... https://people.gnome.org/~federico/blog/helping-cairo.html

"so uhh..."?

it's not bad because of misguided intentions, it's bad because it lacks resources. really badly, even.

Re: All of Oculus’s Rift headsets have stopped working due to an expired certificate

#204

Post by unmole » Thu, Mar 08, 2018, 10:16 AM UTC

peterwwillis wrote: post #77

I've pointed out this consequence of "put TLS on everything" before, but people shrugged it off.

This has absolutely nothing to do with TLS.

Re: All of Oculus’s Rift headsets have stopped working due to an expired certificate

#205

Post by tallanvor » Thu, Mar 08, 2018, 10:32 AM UTC

gmueckl wrote: post #189

zaarn wrote: post #184

Earlier quoted context omitted.

It's still Oculus fault because they didn't use a timestamped signature. A timestamped signature on the binary would have it kept working and that's how MS intents it to work. You can leave it out if you have the desperate longing for having your software break suddenly without reason like Oculus just did.

And that's where MS is at fault: drivers without timestamped signatures should be treated as faulty. This would prevent these errors in the first place.

I guess I can see reasons why some companies may want to be able to produce time-limited drivers:

Maybe they want beta versions to stop working, forcing users to upgrade.

For offline computers, it might be that some companies would see this as a way to enforce contract periods (customers would have to install an update to continue using the product when their contract is renewed).

Of course, disabling driver signature verification is still a way to bypass that, but often times the companies that do things like this probably aren't thinking about that.

Re: All of Oculus’s Rift headsets have stopped working due to an expired certificate

#206

Post by ryanlol » Thu, Mar 08, 2018, 10:37 AM UTC

gambler wrote: post #146

ryanlol wrote: post #116

Earlier quoted context omitted.

Does that really not sound ridiculous to you? Microsoft needs to be blamed for their certificate validation implementation because people might use it to make their software expire? Instead of just writing code that does so?

How about we stop blaming people who accidentally pressed figurative "system self-destruct" button and start asking why there are so many of those buttons everywhere? Nowadays this is a recurring theme. Simple mistakes leading to catastrophic failures at grand scale. "Just be more careful" doesn't cut it anymore, because in the software world there are just too many things to be careful about.

You cant possibly make this argument in the context of driver development. Everything is a self destruct button.

Re: All of Oculus’s Rift headsets have stopped working due to an expired certificate

#207

Post by tallanvor » Thu, Mar 08, 2018, 10:41 AM UTC

CookieMon wrote: post #156

tomcam wrote: post #72

Earlier quoted context omitted.

Why should the Rift fail when a certificate expires?

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 expi…

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...

Re: All of Oculus’s Rift headsets have stopped working due to an expired certificate

#208

Post by privateSFacct » Thu, Mar 08, 2018, 10:51 AM UTC

eksemplar wrote: post #159

lopmotr wrote: post #81

Earlier quoted context omitted.

Something like that. Certificates aren't supposed to stop working just because they've expired! That would destroy all abandoned or poorly maintained software within a couple of years. 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.

> Certificates aren't supposed to stop working just because they've 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 rene…

I've actually run into this issue with public sector documents such as PDF's. They don't timestamp (what a PDF calls long term validation). I had not idea this was by intent!

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).

Re: All of Oculus’s Rift headsets have stopped working due to an expired certificate

#209

Post by ryanlol » Thu, Mar 08, 2018, 10:52 AM UTC

wtallis wrote: post #127

ryanlol wrote: post #116

Earlier quoted context omitted.

Does that really not sound ridiculous to you? Microsoft needs to be blamed for their certificate validation implementation because people might use it to make their software expire? Instead of just writing code that does so?

Microsoft's driver signing model has a mode that is a giant footgun with no redeeming value. Oculus is a victim of Microsoft's bad design. They weren't trying to build in a self-destruct timer for their whole product stack, and if they were, they wouldn't have used the driver signing certificate as the lynchpin.

So instead of trying to conform to the x.509 spec MS should have just developed their own certificate validation scheme, because that would totally be less of a "footgun" than conforming to the spec.

Am I getting this right?

Why aren't we blaming the people behind RFC5280, after all it was them who came up with this awful idea that certificates should expire.

>giant footgun

oh dear god how are you generating your certificates? This is not a footgun unless you are doing something immeasurably stupid before even involving MS products.

Besides, if you insist on going ahead and setting the Not After field, wouldn't it be a bigger footgun to ignore that?

Re: All of Oculus’s Rift headsets have stopped working due to an expired certificate

#210

Post by josteink » Thu, Mar 08, 2018, 11:09 AM UTC

IncRnd wrote: post #119

makmanalp wrote: post #99

Earlier quoted context omitted.

For the ignorant among us, what would expiration do then?

It's not an expiration on the signed executable but an expiration on the ability of the certificate to sign an executable.

This is the exact right answer.

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.