Fortunately one of our engineers figured out we could get our demo rigs working by setting the clock back a few days. This could have been a huge disaster for our company if we hadn't found that workaround though. Pretty annoyed with Oculus about this
All of Oculus’s Rift headsets have stopped working due to an expired certificate
181–190 of 390 posts
Re: All of Oculus’s Rift headsets have stopped working due to an expired certificate
#182Earlier quoted context omitted.
TLS certificate expiration tells your browser to stop downloading new pages from that site. It doesn't tell your browser to close the page that's already been rendered and is still on-screen.
But you are making new requests to the Oculus api and that part is failing. You wouldn't expect the ajax requests to continue to work just because you left your browser open for years.
It also won't let you refresh the page or close it since the certificate is expired.
Re: All of Oculus’s Rift headsets have stopped working due to an expired certificate
#183Earlier quoted context omitted.
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.
you can't guard against every imaginable stupidity. you try but users will inevitably find a hole.
Re: All of Oculus’s Rift headsets have stopped working due to an expired certificate
#184Earlier quoted context omitted.
It needs to exist in an untrusted environment.. it verifies that the driver which has low level access to the computer hasn't been modified by a third party.. MS signed system binaries are the same way; it's a safeguard against malicious entities.
I'm not arguing against the entire concept of driver signing, just one specific nuance of Microsoft's driver trust model. There is a place for driver signing and signature checking, but de-trusting a driver that you were perfectly happy to give kernel-level access yesterday doesn't make sense.
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.
Re: All of Oculus’s Rift headsets have stopped working due to an expired certificate
#185Our VR surgical training startup has been working for the last few months towards a big medical conference this week where we're showing multiple training procedures for multiple customers on Oculus Rift, as well as having our own booth. The headsets all stopped working the morning of the conference. Fortunately one of our engineers figured out we could get our demo rigs working by setting the clock back a few days.…
Re: All of Oculus’s Rift headsets have stopped working due to an expired certificate
#186One wonders if we've made technology unnecessarily complicated. In order to build something like the Oculus Rift, they obviously needed expertise in hardware design, optics, display technology, manufacturing, user interface design, etc etc. Also, they apparently needed expertise in managing the ins-and-outs of the Windows driver security system. Adding one more subject to their already crowded curriculum wasn't very…
I was just reading something here about Cairo and how it's easy to fall into slow code paths with it, and if you happened across falling into a slow code path, somewhere along the line, "you fucked up." When I read the comment I was immediately flabbergasted: no, someone else fucked up. It's not my fault someone wrote software that sets up undocumented traps for me to fall into. Or provided three ways to do something…
Re: All of Oculus’s Rift headsets have stopped working due to an expired certificate
#187Our VR surgical training startup has been working for the last few months towards a big medical conference this week where we're showing multiple training procedures for multiple customers on Oculus Rift, as well as having our own booth. The headsets all stopped working the morning of the conference. Fortunately one of our engineers figured out we could get our demo rigs working by setting the clock back a few days.…
Imagine how terrible it would be for your customers once that happened in the production....
Re: All of Oculus’s Rift headsets have stopped working due to an expired certificate
#188Earlier quoted context omitted.
Imagine how terrible it would be for your customers once that happened in the production....
He said it's a surgical training startup so I think it would have been fairly okay.
How low has the SW development bar gone, if "it's okay" now means "at least it's not directly killing people"?
Re: All of Oculus’s Rift headsets have stopped working due to an expired certificate
#189Earlier quoted context omitted.
I'm not arguing against the entire concept of driver signing, just one specific nuance of Microsoft's driver trust model. There is a place for driver signing and signature checking, but de-trusting a driver that you were perfectly happy to give kernel-level access yesterday doesn't make sense.
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.
Re: All of Oculus’s Rift headsets have stopped working due to an expired certificate
#190Earlier quoted context omitted.
There's a use case for redis and memcached being open to the network, and a failure mode if you don't properly separate your internal network from the public Internet. There's a use case for S3 buckets that are publicly readable, if they don't contain sensitive/private information. Those features have reason to exist, even though there's potential for misuse. Secure defaults would be nice, but can't eliminate these r…
Really? No reason whatsoever? I'm not being facetious, FWIW. I know a fair amount about PKI, in general (probably in more depth and intricate detail than the average HN'er, actually), but I'm not a developer and I know very little about code signing in particular (and even less when it comes to the Microsoft world of code signing). I do find it kinda hard to believe that there's no use case whatsoever for this partic…
I can readily imagine a scenario where a driver with a signature but no separately attested timestamp should be acceptable. What I cannot imagine is a scenario where it is useful to treat a driver signed in such manner the way Windows currently treats the driver.