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

Post by r1ch » Thu, Mar 08, 2018, 1:33 PM UTC

midnitewarrior wrote: post #232

r1ch wrote: post #23

This is not how Windows code signing is supposed to work. Normally you'd get a countersignature from a timestamp server so that the verification process can prove that the certificate was valid at the time of signing. It would appear that Oculus signed their binaries without using a timestamp server, so without a way to verify when signing happened they become invalid as soon as the cert expires.

Can you just change the clock on your PC to get it to work again?

Post by bakli » Thu, Mar 08, 2018, 1:36 PM UTC

crowbahr wrote: post #239

bakli wrote: post #234

Shameless plug: To avoid such embarrassing situations in future, I've made https://monitorcertificates.com/ . It's free to use right now, and sends your reminders on Slack and Email.

I mean you'd think with the resources available at Facebook they would've: 1. Automated the certificate process to auto-renew at least a year before expiry. 2. Have counter-signatures 3. Have anyone at all use any sort of calendar system to just check in on it to be sure. But I guess being one of the largest tech companies on earth doesn't mean you don't have massive oversights.

Post by josteink » Thu, Mar 08, 2018, 1:45 PM UTC

ryanlol wrote: post #224

josteink wrote: post #210

Earlier quoted context omitted.

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…

>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. Why are you signing your drivers during development? If not, how is the "unreliability" of timestamping…

Post by FLUX-YOU » Thu, Mar 08, 2018, 2:04 PM UTC

Piskvorrr wrote: post #188

konschubert wrote: post #187

Earlier quoted context omitted.

He said it's a surgical training startup so I think it would have been fairly okay.

Those things aren't cheap for simulators, either - not to mention knock-on costs. "What do you mean - I got the doctors in, which alone took a month of herding cats, and now it won't work, just because?" How low has the SW development bar gone, if "it's okay" now means "at least it's not directly killing people"?

Post by mattnewport » Thu, Mar 08, 2018, 2:09 PM UTC

DanAndersen wrote: post #246

mattnewport wrote: post #181

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

Wow! I'm glad you were able to get it figured out. Sounds like a nightmare scenario. By the way, do you have any links to your surgical training startup? I'm doing some research into VR/AR for surgical telementoring and training and would be interested in seeing how it's in use.