All of Oculus’s Rift headsets have stopped working due to an expired certificate
techcrunch.com
techcrunch.com
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
How low has the SW development bar gone, if "it's okay" now means "at least it's not directly killing people"?
I though that was the way ever since OS/2 failed. Getting stuff out to customers has priority over quality control.
It gets that low every time a hospital underfunds IT staff and makes horrible project management decisions and product buying decisions.
I've seen that first hand. There's a bunch of corpses at the IT entrance of people who've tried to turn that around.
The bug is now patched, so the downtime appears to be less than 24 hours from discovery to fix. The original error is clearly a major blunder, but Oculus have responded properly.
In other words, comparing to the worst possible outcome is, by definition, not a very high bar.
Something like this probably will happen with computer assisted surgery or medical procedures, or an aircraft in flight. Just a matter of time.
It seems ridiculous in this modern age, but there are a huge number of people who will never bother to look into their problems on their own before asking someone else. Then this other person does a simple Google search and becomes the hero expert.
This all too often results in further dependence, with no real reward for the guy who took this basic step except more requests in the future. If this one guy can get a day off in this instance, it'll be a victory for every person who has ever said "Oh, if you google that, you'll see one of the first results with instructions to do x, y, z." to a time-draining coworker.
Also, a lot of problems have their search engine results "poisoned" by solutions for lesser, but superficially similar problems that are worked to death by SEO content farms competing for attention.
I even seem to recall one that when I set the clock back much more than 30 days gave me as many more days beyond the 30 as as much as I had set it back.
Then there were a couple pieces of software that would detect such trickery and which would punish you by taking away the time you had left also if you set back the date before the 30 days were up.
Anyway, with this in mind, the first thing I thought when I read the headlines was, “I wonder if one can get around this by setting the clock back”, and I doubt I was alone in that, so to say that it “probably wasn’t his idea”... I dunno man.
I would like to see more companies write a Thank You letter from the CEO, signed by his managers. Something that he could use during his performance evaluations at the company, or attach to his resume for any other jobs.
It's hard to get concrete evidence like that, which shows your value to the company. It would great to have documentation that could never be forgotten.
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.
We've had a fair amount of press coverage in specialist press recently so a search for Osso VR should turn up some recent articles too.
Wow. That guy sounds interesting...
I say this not to either criticize you or excuse the mistake by Oculus (they really needed to countersign their cert with a timestamp server), but to educate. These are non-obvious issues to people that don't follow the VR sector.
Monitors work without low-level drivers because their maturity (and lack of innovation) allows the hard stuff to be embedded in the operating system. VR is not at that state; it is emergent, and the capability stacks require additional integration into the OS. Vendors frequently add unique features, and will continue to do so for some time, making standardization difficult.
Even at its simplest level, a VR headset with 6 degrees of freedom is two monitors that must remain in absolute synchronization while also returning positional information to the CPU. This alone is enough to go beyond "standard monitor driver" functionality.
But there's much more. Here is a paste of a comment I made elsewhere:
Oculus (and Steam, via SteamVR) engineers a plethora of low-level code to reduce latency and add features. It's not just a monitor, but a whole set of SDKs, APIs, devices, and drivers.
For the Rift, the hand controllers are wireless input devices refreshing at 1,000Hz; the sensors (to know where you are in the room) are USB devices with tight 60 fps synchronization to LEDs on the headset; there is a custom audio stack with spacialized audio and ambisonic sound; video needs specialized warping to correct lens distortion, interpolate frames, and maintain a 90 fps image, etc.
Not to mention, the system creates a virtual monitor so you can see your 2D desktop while in VR. You can reach out and "grab" a window, rip it from the desktop and position it in your VR world. Pin it, and when you enter a game that window remains and is fully interactive with the Touch controllers emulating a mouse. Maybe you want to play Spotify in the background of a table tennis game, or be able to check a Discord screen while working through a puzzler, or watch YouTube videos while flying your ship in Elite:Dangerous. One guy set up a video feed from his baby monitor so he could watch his kid napping while in VR. This is obviously not a standard feature of the Windows compositor.
All this needs to work across AMD and Nvidia, in Unity, Unreal, or any custom game engine. It's not off-the-shelf driver stuff.
Not to mention, the premise that monitors don't have drivers is also mistaken. They may not be necessary, but they are available[1]. And, the decision to sign kernel drivers is not a poor choice by Oculus, but a mandate from Microsoft for Windows 10 build 1607 and above.[2] A cert is, indeed, necessary to function.
Hope that was informative.
[1] http://www.aocmonitorap.com/my/download_driver.php [2] "Starting with new installations of Windows 10, version 1607, Windows will not load any new kernel mode drivers which are not signed by the Dev Portal." - https://docs.microsoft.com/en-us/windows-hardware/drivers/in...
An enterprising user can turn off these driver signing enforcement settings but it's quite a song and dance and first you have to even be aware of it.
Besides, this is a false dichotomy - On your own comp you can self-sign the driver cert! The CA just has to be in a driver trust store.
The only people who lose out are those trying to distribute drivers to computers they have no control over and who cannot convince the user to install a certificate.
Most (I won't say all) certificates expire. However, there's a huge difference between an expired certificate and one which is renders a driver invalid - and this is one of the two places Oculus erred.
When you sign a driver, you want it countersigned by a timeserver. This cryptographically assures that the cert used was valid at the time of signing, so the signature on the driver remains valid even if the signing cert expires (the crypto ensures a hacker can't just change the metadata with a hex editor). It allows the OS to confirm that the code was signed by a cert that was valid at the time of signature (even though now expired). Without it, the OS can only assume that the code was signed the same day as the validity check. Two days ago that was fine, but yesterday the signing cert expired and everything broke.
This was screw-up number one. Apparently, during the build process from Oculus's v.1.22 to 1.23 release, the timeserver countersignature was removed. This is obviously a mistake, because that took place about 30 days ago. No sane person would assume that they intentionally did something that would bring down their user base in a month.[1]
Obviously the second mistake was letting their certificate lapse. This was compounded by the fact that their update app was signed by the same cert, so they couldn't just push a quick fix (because the updater didn't work).
So in short, signatures don't expire, but the certificate used to do the signature does. With a timeserver countersignature the code would have kept running but no new code could be signed from the old (expired) cert.
Oculus missed some pretty big devops gaps, and suffered a big black eye for it.
But it had nothing to do with DRM, planned obsolescence, needing to connect to the internet, or Facebook data capture.
[1] Other commenters have mentioned that if a timeserver is down at the time of a build, it can fail to add the countersignature. Maybe that's what happened?
I've not looked at the MS requirements, it seems good to expect signed drivers, but a signature shows that the company made that driver at that time - that should never expire.
Sure, also have a mechanism of certification that shows if a company vouches for a piece of software currently, but using that mechanism to override a [admin level] user and forcibly disable software, that's got to be always wrong.
The short answer is:
- a "certificate" contains a number of things: a portion of an asymmetric key (either public or private), and a ton of metadata[1] to give information about that key: validity period, algorithms used, version, etc.
- a "signature" is the result of a crypto operation on data that proves the data (a) has not changed since the operation, and (b) the person doing the signing owns the private portion of that asymmetric key.
As I said in my other message, a signature doesn't expire, but it's related directly (and generated by) the certificate used to create it. So if that creation certificate expires (or is revoked) it calls into question the validity of the signature(s) created from that certificate.
Let me know if you're interested in more background on asymmetric cryptography and the relationship between public keys and crypto, private keys and signatures, and the role of certificate authorities vs. a PGP-oriented 'web of trust'.
[1] https://en.wikipedia.org/wiki/X.509#Sample_X.509_certificate...
Are you arguing that already-installed drivers should no longer be trusted? I can't tell.
If a cert expires at time T, the usual assumption is that forging signatures before T is not feasible (otherwise the expiration was poorly chosen), while forging signatures after T might be feasible.
If it's after T and we see a new update, we don't know whether the signature was crafted before or after T, so we should assume the latter and reject it.
But if we've already installed a driver, then we must have received its signature before T, otherwise we wouldn't have installed it at the time. So we should still continue to trust it after T.
I won't argue it's right or wrong, actually. It's a choice, with different threat models driving different conclusions. Defining the failure modes with respect to security risks is a fraught business, and I hope Microsoft put a great deal of thought into it and has far more visibility into the risks than I. But it's what they appear to do, and we live in their world.
I argued elsewhere (in a late, top-level comment somewhere) that - if this is Windows's failure mode - MS should provide tools for devs to integrate into their build process that flags risky or mis-configured signature scenarios. This is too complicated, and used by too many non-security experts, with extreme failure modes, for it to be half-ass-able or easily done wrong.
And now you leave open an attack surface of "forge a signature off an old, expired cert and then fool the OS into thinking it's been installed all along."
Face it, today's VR headsets simply are monitors that you wear on your face (Head Mounted Displays). Anyone thinking otherwise is simply lying to himself to make it sound more complicated than it is. Those include a few input peripherals as well, none of them which is particularly complex (valve's lighthouse system is probably as complex as it gets).
And lastly, none of these points should require a certificate. Every computation can be done locally, without the need of an internet connection.
To be a bit more specific, let's break down the arguments (I have nothing against you, I am just interested in those):
> Monitors work without low-level drivers because their maturity (and lack of innovation) allows the hard stuff to be embedded in the operating system. VR is not at that state; it is emergent, and the capability stacks require additional integration into the OS. Vendors frequently add unique features, and will continue to do so for some time, making standardization difficult.
This is true... Somewhat. For now, the only integration that has been done in the Linux kernel is DRM (direct rendering manager) leasing [1], which allows an application to borrow full control of the peripheral, to bypass compositing. That, and making sure that compositors don't detect HMDs as normal displays (so that they don't try to display your desktop on them). Please note that none of these are actually needed if the compositor is designed to support HMDs from the ground up. Those are just niceties, and the HMD is just considered like a regular device.
> Even at its simplest level, a VR headset with 6 degrees of freedom is two monitors that must remain in absolute synchronization while also returning positional information to the CPU. This alone is enough to go beyond "standard monitor driver" functionality.
Even if those monitors are physically separate, this is likely something handled by the HMD board itself. The monitors DON'T return positional information, they just display stuff (accelerometer, gyro, compass, etc. are just other peripherals that happen to sit on the same board).
> Oculus (and Steam, via SteamVR) engineers a plethora of low-level code to reduce latency and add features. It's not just a monitor, but a whole set of SDKs, APIs, devices, and drivers.
Just like every peripheral under the sun, isn't it?
> For the Rift, the hand controllers are wireless input devices refreshing at 1,000Hz; the sensors (to know where you are in the room) are USB devices with tight 60 fps synchronization to LEDs on the headset
Believe it or not, frequency and latency are probably not the most complicated thing with the lighthouse system; these specs are actually not uncommon for USB devices (I admit that I don't have a good example in mind, though).
> there is a custom audio stack with spacialized audio and ambisonic sound; video needs specialized warping to correct lens distortion, interpolate frames, and maintain a 90 fps image, etc.
We are NOT talking about HMDs anymore at this point, and these feats have been accomplished countless times already, in various systems. The first one already exists in multiple forms of HRTF a bit everywhere, including openAL, and would probably be a lot more common if Creative didn't try to sue everyone into the ground as soon as they try to do something interesting. The second thing (distortion correction) is not really complicated, and was done in Palmer Luckey's first proof of concept (or was it John Carmack who implemented it). Interpolation sounds a bit more complicated, I'll grant you that, but still pretty doable.
> Not to mention, the system creates a virtual monitor so you can see your 2D desktop while in VR. You can reach out and "grab" a window, rip it from the desktop and position it in your VR world. Pin it, and when you enter a game that window remains and is fully interactive with the Touch controllers emulating a mouse. Maybe you want to play Spotify in the background of a table tennis game, or be able to check a Discord screen while working through a puzzler, or watch YouTube videos while flying your ship in Elite:Dangerous. One guy set up a video feed from his baby monitor so he could watch his kid napping while in VR. This is obviously not a standard feature of the Windows compositor.
Again, this has nothing to do with HMDs. But, congratulation, you just wrote another compositor, and reinvented multitasking. This has been done countless times, and VR compositors have been made by multiple teams. Here is a nice open source one: [2].
> All this needs to work across AMD and Nvidia, in Unity, Unreal, or any custom game engine. It's not off-the-shelf driver stuff.
Well, so has: controller support, graphics API support (woops, actually the two only thing needed), but also language support, processor architecture support, sound system support, operating system support, etc. Everyone needs a bit of code to support new architectures. Supporting the display portion of a HMD is relatively straightforward, and actually uses off-the-shelf APIs. Well, you have to correct for distortion, but I would be surprised if some APIs didn't come out [3] to support small variations between devices.
--
To conclude, yes, it's an impressive technology stack, but you could literally pick any other device in your computer, and you would get comparable the same complexity. I am not trying to undermine the amount of work that went into HMDs and their stack, just pointing out that it's relatively common and straightforward.
And a HMD is by definition a monitor on your face :)
--
On the other hand, I just read the explanation (after writing this), and I agree that having your own kernel module makes sense for some of this (especially on Windows, on Linux you would just mainline support), if you want to make it happen faster. Yet, most of the above arguments do not serve the discussion ;)
I can get kernel drivers needing to be signed, but requiring the cert to remain valid after installation is a bit of a reach, isn't it?
Edit: thank you for the detailed explanation below.
[1] https://keithp.com/blogs/DRM-lease/
Counterargument: The 16 things that happen other than just displaying images on the screen aren't relevant, have been done before, or has equivalent complexity to other systems.
Well OK. I just can't argue with that.
"A modern CPU SOC is no more than a souped up 6502."
That's true, if you ignore the integrated video, complex cache management, integration of networking/sound/northbridge/southbridge, secure enclaves, and significantly higher performance characteristics that result in subtle changes driving unexpected complexity. All of those things have been done elsewhere.
So if that's your perspective then we'll just have to agree to disagree.
Though I will point out the fact that all of those non-monitor components that you described also require custom drivers, which require their code to be signed, which was ultimately the item the OP took issue with. I'm frankly surprised that after acknowledging the amount of re-implementation VR requires, across numerous non-monitor disciplines, fusing the data in 11ms, for total motion-to-photon latency of 20ms or less, you still feel this is "common and straightforward."
But OK. I don't know your coding skill level, so this may be true.
And per this point:
> interpolation sounds a bit more complicated, I'll grant you that, but still pretty doable.
Valve has still not released an equivalent to Oculus's asynchronous spacewarp. If you feel it is "pretty doable" you would do a huge service to the SteamVR community if you could implement it and provide the code to Valve.
See https://developer.oculus.com/blog/asynchronous-spacewarp/ for details.
Let me be clear: I pretty much agree with everything you said. Only your original statement was what I felt a bit of a stretch:
> The "monitor you wear on your face" trope is simply inaccurate, and essentially a misunderstanding of the state of VR today
After reading a bit more into it, I feel that Oculus took the correct software approach to bring up its hardware on Windows. What happened appears to have been more of an oversight, one that most people probably could have felt for.
Custom (in-kernel) drivers are indeed probably a necessity to achieve the best possible experience, with the lowest attainable latency. However, they are not actually needed for basic support [1], which is where I think our misunderstanding comes form.
I realize that a tremendous amount of work has gone into making VR as realistic as it could get, and I am not trying to lessen it at all, which is what I think you wanted to point out with your original remark.
As much as I would like to have a go at implementing that kind of feature (and experiment with VR headsets in general), I don't really have the hardware nor the time to do so, unfortunately :)
--
[1] I don't know the latency involved with userspace-based USB libraries, but it seems to be low enough that Valve is using it to support the vive, at least on Linux (and for now).
As an aside, Valve's tracking solution is much less USB-intensive than Oculus's.
In Valve's Lighthouse system, sensors on the HMD and controllers use the angle of a laser sweep to calculate their absolute position in a room and provide the dead reckoning needed to correct IMU drift. As a result, the only data being sent over USB is the stream of sensor data and position (I believe sensor fusion still occurs in the SDK, not on device).
Oculus's Constellation system uses IR cameras, synchronized to an IR LED array on the HMD and controllers. The entire 1080p (or 720p, if used over USB2) video images (from 2 through 4 cameras, depending on configuration) are sent via USB to the PC. This is in addition to the IMU data coming from the controllers. The SDK performs image processing to recognize the position of the LEDs in the images, triangulate their position, perform sensor fusion, and produce an absolute position.
The net result is roughly equivalent tracking between the two systems, but the USB and CPU overhead for Rift is greater (it's estimated that 1%-2% of CPU is used for image processing per sensor, but the Oculus SDK appears to have some performance advantages that allow equivalent performance on apps despite this overhead).
There is great debate over which is the more "advanced" solution. Lighthouse is wickedly clever, allowing a performant solution over larger tracking volumes with fewer cables and sensors.
Constellation is pretty brute-force, but requires highly accurate image recognition algorithms that (some say) give Oculus a leg-up in next generation tracking with no external sensors (see the Santa Cruz prototype[1] which is a PC-free device that uses 4 cameras on the HMD and on-board image processing to determine absolute position using only real-world cues). It also opens the door to full-body tracking using similar outside-in sensors.
But overall, the Valve solution definitely lends itself to a Linux implementation better than Oculus's, simply due to the lower I/O requirements. It also helps that Valve has published the Lighthouse calculations (which is just basic math), while Oculus has kept its image recognition algorithms as trade secrets.
[1] https://arstechnica.com/gaming/2017/10/wireless-oculus-vr-gr...
Internet connection is required for updates, for instance, in case you forgot to countersign your drivers against a timeserver.
Whoops.
About a $5m whoops, considering Oculus just gave everyone a $15 store credit due to the problem.
Sometimes education is expensive.
Could you share more info on this? Is it actually possible to poll the devices at that resolution from code?
So, the SDK takes all the information in directly, does its calculations, and exposes only the resulting positions and orientations for hands and head. This resulting info is what developers typically use.
Here's an excerpt from a blog post[1] regarding the IMU and sensor fusion:
> With the new Oculus VR™ sensor, we support sampling rates up to 1000hz, which minimizes the time between the player’s head movement and the game engine receiving the sensor data to roughly 2 milliseconds.
> <snip interesting info about sensor fusion>
> In addition to raw data, the Oculus SDK provides a SensorFusion class that takes care of the details, returning orientation data as either rotation matrices, quaternions, or Euler angles.
Note that this blog is from back in dev kit 2 days. It's possible that Oculus removed the ability to retrieve raw data; in my hobbyist efforts I only use Unity's integration and don't work directly against the SDK.
[1] https://www.oculus.com/blog/building-a-sensor-for-low-latenc...
Wait, is this new. I haven't used my Oculus in over 6 months because of how hard it was to interact with the desktop and a few other things while in-game. Is this standard feature now for Oculus' Framework?
But I use it and it's amazing.
Edit: Here's the "sizzle reel": https://www.youtube.com/watch?v=SvP_RI_S-bw
Here's just someone using Home: https://www.youtube.com/watch?v=sMjlM5vFSA0
And here's a blog post about it: https://www.oculus.com/blog/rift-core-20-updates-beta-coming...
> "Each year, the FDA receives several hundred thousand medical device reports of suspected device-associated deaths, serious injuries and malfunctions."
It is also specious to argue that a consumer product is being used for live surgeries without FDA approval.
This does not excuse the mistake, nor does it change the fact that the error will make people question the reliability of the product - as they should.
However, mistakes do happen, even big ones. Rockets blow up. Airbags have defects that make them not work. McAfee pushed out an antivirus update that deleted a Windows system file, crashing hundreds of thousands of PCs.
The important questions are: how does the vendor respond, what procedures do they put into place to prevent it from happening again, and are those procedures enough to give future buyers confidence that the issues are addressed?
Saying "that shouldn't have happened," while perhaps true, is simply not constructive.
It doesn't help that vendors are generally nervous about liability in medical equipment (this fear is often unfounded, but persistent). As a result, vendors of commercial and industrial equipment generally don't want to engage medical device OEMs with engineering and customization support. If there had been that sort of support in this case, Oculus might have made a custom build without the cert check, just as a de-risking measure.
This vendor reluctance is especially present at the FDA Class III (high risk device) level - most vendors outright prohibit use of their devices in these products. It's an open secret that this still happens anyway in a wink-wink nudge-nudge fashion, just without vendor support - which is arguably worse, but it keeps the lawyers happy.
The real MVP of this story. Sometimes a dirty hack is good enough.
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.
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.
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.
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.
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).
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.
A lot of applications and environments seem to be built with the assumption that they can add arbitrary complexity to their interface, since they're only going to be used by "experts" who can be expected to know everything of relevance and work through a thick documentation to understand the system. In truth, the "experts" who use your programs are going to also be using a dozen other applications, each with their own piles of documentation (or equal amounts of lack-of-documentation,) and have little brain-space left for the intricacies of your framework. So, they're going to use your system while knowing the minimum possible amount about it; if that system contains traps that cause problems for this kind of user, that's bad design.
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 and two of them are not recommended OOTB. Or is primarily documented by third parties.
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 write "the system" have to write software that does specific things in specific situations and there will be endless cases which cannot be dealt with efficiently. And the more the interface hides the implementation, the less likely it is that those cases will be obvious.
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 expectations about the “make it so” API into our architecture.
Getting to a good, explicit, imperative API requires a whole nother step, and often a major refactor. You have to step back and ask “what is really happening now and can I conduct it more directly?”
... but by that time your code works and it hardly seems worth the effort.
But it is worth the effort. The declarative API will just get uglier as you add to it, and provide no real guidance about where future additions should go. Just throw another key in the config. Add another conditional. An imperative one will constrain your future choices about how additions can work, and therefore helps you clarify your domain model as you add to it.
You can have high level imperative APIs... they just need to be explicit.
Many declarative interfaces are the culmination of decades of work on re-inventing the wheel at the imperative level. The relational model and SQL databases are a great example of this - “we’ve solved these problems below this line mostly, please move on and focus up the stack closer to the customer/user”. It became a multi billion dollar industry as it nailed the 80/20 rule for data management.
And for a large class of problems this remains solid, despite a perpetual subset of engineers that think they can do better than the declarative interface and engine and build an alternative. Sometimes it makes sense to be adventurous and drop back to the imperative level - SQL databases fell over in recent years was the scalability of the underlying engine for the largest uses. But a Postgres or MySQL endures as a great declarative abstraction over a very complicated set of issues.
SQL is a great example. But it’s also an example of how difficult it is to make a great declarative API. Look how much effort went into designing and then refining and then adapting SQL to changing needs. It’s been an enormous effort across a huge community.
Same with CSS. Those aren’t things some developer just wrote and they got refined in an application over time. There are entire conferences about the regular redefinition of those interfaces.
My point is that concept doesn’t scale to some large number of abstractions. SQL and CSS are big manifolds that operate on the boundary of your application, and often separate you from an entire other group of developers working to maintain the other side of that contract.
If you try to apply that same setup to every problem, with thousands of declarative manifolds all intersecting within your application, you get chaos. Which is what many modern frameworks try to do. Declarative APIs only work when they are rare and standard and everyone knows them.
That's just an excuse to stop mediocre engineers who would fiddle endlessly with pointless micro optimizations.
You very much need to understand the performance of your code if the product has performance requirements that fail unless you do.
I presume most coding is just crudding small strings from UI to database, where performance issues don't kick in, and hence it would be wastefull to care about them.
I've watched production builds to crawl to a halt and become sluggish as molasses because someone in the dev team was indoctrinated in this creed. (Many reasons, including a cartresian explosion in complexity due to some innocuous LINQ calls).
and efficiency of computation is the least of my worries. i would like things to just work.
Who is saying that? I've worked in video games for 18 years and never heard that. In fact, anyone who said that would get puzzled and suspicious looks. We generally use a very C-like variant of C++.
I was responding to a comment about Cairo graphics, which I assume is not much used in games. The kind of graphics I was thinking about is things like Cairo, Windows WPF, the Web.
That said: once upon a long time, OpenGL was supposed to be achieve efficiency by being high level so that the rendering stack could optimise your drawing better than you could. That idea didn't work so well and modern OpenGL seems to take the opposite approach.
I think we're waaaay past the "wondering" part.
The problem lays in the IP. It's considered to be a vital asset so that when a company goes belly up it will survive kept years or decades in a safe by law firms in the hope someone will buy it, or just to make profits through litigation against infringers. Unfortunately this has a deleterious effect on products derived from that IP, the people who bought them and the people living where the unusable products will be trashed.
Just recently picked up a Rift. I love the hardware and their exclusives are top notch, but this confirms my suspicions that their backend is super goofy.
They sell Rifts at Best Buy and want to pretend that it's a consumer-ready product, but here's why I am recommending people stay away for now:
- Non-existant repair or service out of Warranty.
- Basic things in the platform like changing your name or photo don't exist.
- Lots of non-response over other basic features requested by the community.
- Questionable future investment in the platform or hardware. It sounds like they are moving their efforts towards "lighter" experiences.
In short, it feels like being a legacy customer for a new product.
This also suggests that if the decide they stop supporting it, eventually the software will stop working due to these certificate errors for which will then there be no fix.
It's not bricked, bricking means it's as useful as a brick as in the actual firmware is corrupted beyond repair.
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
"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
Would anyone with a straight face say the same about Nintendo's exclusives?
I don't see anyone else in the market funding great things like Medium, Quil, Lone Echo, Robo Recall. Feels it's just cutting off your nose to spite your face to complain about this.
An Oculus is not a standalone product; it is a peripheral that relies on an open PC platform for its processing. If software the Oculus uses can run on any PC and the Oculus does not have a unique hardware capacity to operate the software, then the exclusivity is an arbitrary constraint.
Oculus wants all the perks of being its own platform without the responsibility or technical merit.
But meanwhile my 10 year old nephew is having life shaping experiences with the Rift I set up for him.
I've been surprised how many investors / technologists view VR as a niche market for enterprise / porn / limited gaming appeal.
There are other education experiences like BBC Home which is one of my favourites. Another, Mission:ISS allows you to explore the ISS and control the Canadarm to dock a module. Highly recommend them.
https://www.oculus.com/experiences/rift/1246744618768922/
https://www.oculus.com/experiences/rift/1178419975552187/
edit: I almost forgot, Go For Launch:Mercury is also very worth it. You can choose manual mode which puts you in charge of setting the launch procedures. The graphics aren't as good as I'd like, but the experience is good.
https://www.oculus.com/experiences/rift/752373261529153/
---
As a platform I really think it's capable of more than it's really doing right now.
I wish there was a way to open it right up for the more adventurous instead of relying on sometimes-working-sometimes-not tools like VorpX.
google earth VR and the opportunity to show it to my friends was worth $350 on its own.
I trust the developers aren't using license fee money but instead are paying for using the BBC name ...?
But if you get a chance to try it, do! I will warn you though—the first time through is a bit intense. I was new to the platform and had to take the headset off for a few minutes mid-game. After trying it again I found my legs.
Also, it might seem counter-intuitive, but I've found alcohol helps desensitize oneself to the experience.
But when it comes to kids/education, etc. Just be careful. I've invited others to try out some of the more intense experiences and I've even had people get mad at me for it.
http://downloads.bbc.co.uk/bbctrust/assets/files/pdf/about/h...
Still need the sensors, but those aren't that large.
https://www.theverge.com/2017/10/12/16463844/oculus-santa-cr...
- Owned by Facebook, who will use it to gather as much data about you as they can.
That.
My Rift is scratched since first use (I swear it came scratched) and I've never been able to have them acknowledge that the device can be scratched into a blurry mess. "Oh, that's only regular use wear and tear" ...
Lens cannot be replaced or repaired (and they could during rift dk1 era).
Can you explain what this means in practice? I'm not super familiar with Rift but I'm curious.
Because Mark Zuckerberg said so, that’s why.
More relevant by the day: http://locusmag.com/2018/03/cory-doctorow-lets-get-better-at...
[Edit: It may not be this simple. See the top-level comment by r1ch about timestamp servers.]
CRL in the driver install flow implies being online (at some point) to install drivers too. As we move into the future it’s hard to imagine not having Internet access, but we also don’t design Windows. It’s definitely a case they’ve considered, though I did see mention of a timestamp server in this thread (I don’t know much about Windows signing, just X.509 PKI in general).
With a timestamp, as long as the signing date was within the signing cert's validity period, the signed driver continues to be trusted beyond the signing certificate expiration.
If the driver was valid when it was signed, then revoking it will break the system. Not installing it is another story.
how so? it merely limits which dates you can sign code, after which the code you signed remain valid, but you can't sign any more code.
The whole problem here is that the code that was signed is not being treated as valid code beyond the expiration date.
Ideally it's not used except by the timestamp service, but it seems like a fairly reasonable fallback.
The fact that the driver was installed locally before the expiration should be taken as proof that the driver was signed before expiration.
You could look at the system clock but that was not designed to be secure for this purpose.
If you think I'm proposing any changes to how drivers are installed, then you have misread me. I'm proposing a change to how already-installed drivers are handled: absent any new information, the code that was trusted yesterday should be trusted today, and be allowed to keep running.
You could say that any damage has already been done which is most likely true. But I can't fault them from mitigating it as much as possible.
I suppose you could modify the system to get external attestation of the time while the driver is installed and use that as a sticky bit - but its a big complication and its much better if the driver is securely timestamped in the first place.
The only way that the system "knows better" is by acquiring something like a certificate revocation list. The system does not know whether it was powered down for five minutes while the network outage was fixed, or for five years. When the system is powered back on with a working internet connection, it does not have any reliable way to tell whether the offline installation of the network driver occurred prior to the expiration, or after the expiration with a properly backdated driver and backdated system clock. There is no way to justify suddenly de-trusting a driver that's already been running simply by observing that you're in the future.
I guess I don’t know the time when Microsoft has their code and heir contact information and is doing some kind of preflight check, or if that ever actually happens, and there are already so many ways to be very dumb with drivers...
The fact that if a rootkit is in a position to performing that spoofing, it doesn't need to, because it already has the power to make arbitrary modifications to the system image.
Putting expiration dates on non-malicious drivers is not a particularly effective way to protect against malicious drivers.
I was replying to this part of your comment. It does seem worthwhile to validate the signature of the driver every time the driver is used if that check would reveal when a certificate has been revoked for having been compromised.
Agreed that the expiration time is not particularly useful for this purpose.
It would be much more efficient to scan the list of installed drivers every time a certificate revocation list is updated, because certificates are revoked much less often than operating systems are booted.
And there's nothing gained by just checking timestamps if you don't have a new certificate revocation list. If the driver is already installed and was trusted and running yesterday, you gain no security by deciding to not load and run that driver today, unless overnight you acquired new information that the driver is insecure or malicious. The ticking of a clock does not convey any such information.
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 ;)
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...
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)
In those cases, "we" (as a "community", in general) often blame the people responsible for running those services instead of the developers (or Amazon) being blamed for choosing convenience/ease-of-use over security. That is, we're often quick to say that the people running those wide open memcached servers are at fault for not properly configuring and/or securing them -- and not blaming the developers for creating "a giant footgun".
"You shouldn't be running servers on the Internet if you don't know how to properly configure them" (paraphrasing) is often stated. Yet, in this case, we're not blaming Oculus for their screwup and instead blaming Microsoft -- even though there's zero evidence (AFAIK) that Oculus even used any Microsoft tools to sign their application. (N.B.: I don't know the first thing about code signing on Windows so it may well be that using a Microsoft utility is required and, thus, just assumed by those of you who are familiar with the process. If that's the case, sorry.)
I'm having trouble trying to reconcile these two seemingly opposing viewpoints. Why is Microsoft's utility "a giant footgun" but a (OOTB) completely insecure by default, wide open by default memcached server (for example) isn't?
I mean this with all respect... but why? You're talking about different opinions expressed by completely different people. HN isn't a monolith.
My point was: in most threads, there's a common opinion or viewpoint shared by most, along with a few "detractors". In general, though, the overwhelming "predominant" opinions (within/on a particular subject) are pretty consistent from one thread to the next.
For example, the "it's the end user's fault, not the developers" thing I mentioned earlier. That seems to be, pretty consistently, the "belief of the majority". Here, though, it's the complete opposite. Instead of saying "the end user (Oculus) screwed up" (which, IMO, they certainly did, FWIW), it's "Microsoft made a footgun which caused this".
That said, I have now made it through the rest of the comments in this thread and it seems that this viewpoint isn't as widespread as it first appeared. Perhaps I just jumped to a conclusion much too quickly; there's obviously plenty of fingers pointing at Oculus as well.
There's no reason for drivers to have an expiration date. There's no scenario where it makes sense for the configuration that Oculus stumbled into to be possible.
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 particular configuration (code signing w/o an included timestamp from a TTP), though. I certainly understand why a timestamp can be valuable (as it would in this case) but what isn't clear is that there is "no scenario" whatsoever where the lack of a timestamp might be acceptable or perhaps even desired.
As I said, though, I don't know enough about code signing specifically to know what these scenarios might be but I can't imagine there isn't even one of them.
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.
If you can license software with a definite expiration date, why can't you license hardware with a definite expiration date? And have your license enforced by the operating system? Imagine that I'm a company with a hardware product, and instead of selling that hardware at large expense, I rent it out, and provide drivers with an expiration date to enforce the terms of the hardware lease. If the lease is renewed, I'll provide new drivers with a new lease expiration.
Not that I'm arguing for hardware licensing, or arguing that it was what Oculus was trying to achieve and screwed up somehow. But there's a difference between "Microsoft built a feature some of their customers didn't know how to use" and "Microsoft built an anti-feature".
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?
However, I'd argue that disregarding the Validity section would be an unusually big departure from the spec, not comparable to the typical silliness surrounding x.509.
Alternatively you could propose no user configurable functionalities whatsoever and rarely and carefully upgrade any dependencies (including the os) and you will create a very robust program.
But then don’t expect to end up with a wireless VR headset with an online game catalog and multiplayer capability. No but you can up with a very nice banking application developed in COBOL for sure.
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.
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.
Besides, literally every codesigning blogpost/tutorial/guide/etc I found tells you to use a timestamping server so the guys and girls and Oculus must have skipped the critical parts of whatever they used.
Security Solutions could benefit from this, the customer will have to update or disable the signature check if their version of the solution becomes too old. Old versions could open them up to vulnerabilities.
Another might be when you distribute beta or testing versions of your software. The customers can safely test the version and the lack of timestamp prevents them from running it in production permanently. They have to update to the release version.
It could also be useful when you sell a software to a business and want them to test it first. So you send them the program without a timestamp signature and limit the validity of the certificate. That way they can't just run the test version forever.
Really anywhere where all parties involved, user and producer, do not want to run a binary forever but the producer might not fully trust the user to do that.
I politely ask authors or publishers to release non-DRM ebooks when I can. Apart from best-sellers (or time sensitive books), I believe most books are stuck in the long tail of obscurity and releasing them as non-DRM won't affect their sales.
This also means I don't visit pirate websites that claim to have ebooks. It takes two to tango. :-)
Generally this attitude doesn't backfire, because individual users loosing access to their data, their accounts or their software can be simply dismissed. But in this case it happened to everyone at once, so it's suddenly a big deal.
If one doesn't, well, she isn't much of a "security expert" after all, is she? Firewalling off TCP port 80/443 at your perimeter firewalls isn't a very good solution if you're an e-commerce company selling your product on your web site -- and the "security experts" know this.
That's not the future. That's the present! Which is even more worrying.
* data is not tampered
* signing certificate was time valid at signing time: signing time is within signing cert's validity
* Neither certificate was revoked before signature generation
* both, signing and timestamp certificates chain up to trusted root CAs (regardless of their time validity, just must be in trust store).
That doesn't make sense to me: If the certificates are compromised, an attacker could backdate the timestamp to whatever he wanted and sign anything.
What's the thinking here?
That's not how I read it. The "lifecycle table" doesn't mention the case of both signing and timestamping certificates going bad at the same time, only what happens if one of them expires or is revoked. The only mention about both certificates going bad is in the text below the table:
> But timestamped signature remains considered as a valid even if all certificates in the signing and timestamping chains are expired.
Note that it doesn't say anything about certificates being revoked.
Of course this sorta falls apart if you consider large bad actors could have legit timestamp certs over a period of time and then use those historic certs on backdated servers to counter-sign a stolen signing cert. It would appear as a legit signed and counter-signed cert done when the signing certs were valid.
Nate Mitchell of Oculus posted on Reddit saying "We're working on resolving this issue right now. We'll keep everyone posted on progress here." https://www.reddit.com/r/oculus/comments/82nuzi/cant_reach_o... . Top-level of that thread has a workaround involving setting the clock back or using a utility called RunAsDate to fake the clock for a single application.
https://docs.microsoft.com/en-us/windows-hardware/drivers/da...
EDIT: Looks like the standard TTL for these code signing certificates is none, 1, 2, or 3 years.
https://www.entrustdatacard.com/products/categories/digital-...
https://www.globalsign.com/en/code-signing-certificate/
https://www.instantssl.com/ssl-certificate-products/code-sig...
Fortunately it was a problem with the tests, rather than the code itself, but these things do happen.
At my old job, we had a bunch of tests fail when daylight saving ticked over. For some reason, some things were using local time, rather than UTC. We also had a test that would fail if the minute was the same as the hour.
Time is hard
We furry 'self-reproducing' (YMMV) mammals are simply not ready for all of this.
This was all years ago, so my recollection may be fuzzy, but I spent entirely too much time futzing with SIP traces and certs. Weird, weird things can result from time inconsistencies is my takeaway, however.
Presumably this is what Oculus thought and so how they got in this mess.
BTW, most commercial installer progtams will apply a valid timestamp if codesigning is enabled. So to save ~$1000 someone decided the tools built into Visual Studio were good enough. Anyone that ships commercial software that does more than a basic install into C:\program files will know to spend the money, it’s worth it.
> If your antivirus software restricts the file from opening, temporarily disable your AV and continue.
Good Patch Procedure, 2018.
Please, please don't say: "Our teams apologize for any inconvenience this may be causing you"
instead opt for "Our teams apologize for any inconvenience this caused you"
They soft bricked every single headset worldwide.
"Oopsie we may have caused you inconvenience"
vs
"We're sorry for the damage"
Get rid of the may entirely. I don't know what I was thinking.
Including the word 'may' shifts the sentence from apologising for causing actual inconvenience, to apologising for causing a minor risk of possible inconvenience, which is not what you are trying to convey after selling someone something for a lot of money and then remotely breaking it at no notice.
In many customers, it is likely to elicit a response something along the lines of:
"Any inconvenience this may be causing? I'll give them may be causing. The fucking thing won't boot. May be fucking causing. I wasn't using the damn thing as a doorstop."
EDIT: presumably you need your client apps/libraries in the field write back when they use a cert that is <X months away from expiry.
(disclaimer: work for Azure, but not on Key Vault)
Case in point: Even Azure had a huge outage due to cert issues (abeit quite a bit more complicated than a simple expiration, but my point here is that certificates are hard.)
I use simple Nagios checks for keeping an eye on certificate expiration. It's simple to set up checks for new hosts/services and I have them set to trigger an e-mail alert 30 days before expiration (20 days for certificates from Let's Encrypt). It does the job; I have yet to wake up one day to an expired certificate.
Apparently, this ("send me an e-mail before my certificate expires") is also the sole reason some companies even exist (i.e., it is their only product/service). It amazes me that this is something folks will pay for.
Obviously it should be part of a handoff process when you leave, but companies aren't always good at smoothly handling transitions like this.
What happens if I leave, though? I don't know and, TBH, I won't really care; it won't be my problem at that point. How -- if -- things are handed off or transferred off to someone else when I leave will be up to my boss, I suppose.
If it’s a much longer time scale, people start to forget that it’s even possible for stuff to expire.
If my fridge filter can display a little reminder light on a timer every few months, cryptography-dependent devices might need something similar. That way, your customers could know in advance and be asking you for an update.
Plot twist: the world will still be on IPV4
So many comments agree that (a) security is hard, (b) countersigning with a timestamp server is easy to miss, (c) countersigning makes build processes difficult, and (d) they've done or seen similar things in other apps/companies.
This sounds like a classic UI/UX issue for developers around a literally mandated and mission-critical requirement of the OS.
At the least, MS should provide a validation tool to surface errors or risks before production. Better, signtool.exe should make omissions (like a timeserver) very difficult and make them an override, not a default. Best, they would do both.
I don't agree that the OS should reject non-timestamped signatures as faulty per se (and throw an error), as that puts the burden on the user to understand a developer's mistake. Sometimes running without a timestamp may be desirable - ultimately that's the dev's choice.
It should just be a choice made explicitly.
[0] https://msdn.microsoft.com/en-us/library/windows/desktop/bb9...
However, this affected only one single customer of ours and we had a fix within a couple of hours. -- I certainly learn from this mistake.
I thinks IT is used to managing HTTPS certificates, domain name auto-renewals but app level certs are more of a new thing.
Edit: I don't follow Windows, I'm really curious what the consequences for stuff like this can be generally.
I don't see credit on my Oculus account? Am I supposed to have received it already? Or is this maybe because I don't have payment method added to my account?
It looks like their auto-updater used the same cert though, so they can't distribute it as a normal update. They're probably figuring out the least sketchy/most automated way to distribute it right now.
When this is all said and done, there will be a handful of people who will never, ever forget to use the /t flag in signtool.
[1] http://www.brucebnews.com/2017/11/look-at-the-red-flowers-wi...
It's not just people shrugging it off, many are defending this as being a perfectly fine state of affairs.
https://en.wikipedia.org/wiki/Transport_Layer_Security#Digit...
This includes phones, cars, self-driving cars, watches, farm equipment, computing devices and anything marketed as an IoT appliance.
One glitch, as minor as an improper system time, and you’re dead in the water.
The big question is why on earth can drivers that have been verified and are already installed in your system can suddenly stop working? If this mechanism is intended to protect against malware disguised as drivers then it's already too late. The malware had several years to exploit your system.
Expiration after installation simply doesn't make sense for code signing. The signed executable won't change unlike a website. The driver is always going to have the same file hash, forever.
It makes absolutely no sense to the end user, acting as possessor or potentially a reseller of an object, since the very premise implies that an owner should not be provided total control over their device, that it's never really "theirs", and that a vendor should retain the capacity to take a "sold good" away from the owner, under the guise of expected behavior, built as designed, effectively converting a sale into a rental, in time, perhaps after statutes expire.
It's effectively a back door for manufacturers, so that they can count on well-made products not lasting forever, not in museums, not for resale, not for nostalgia.