- cross-posted to:
- [email protected]
- [email protected]
- cross-posted to:
- [email protected]
- [email protected]
Software that controls your body should always respect your freedom. This article is a recap of scandals of medical devices, like hearing aids, insulin pumps, bionic eyes, and pacemakers, and what we can learn from them. It’s astonishing: you wouldn’t expect these devices to be run by software in such a way that they can leave you completely helpless.
I couldn’t disagree more with you. If you are running something REAL life critical the moment there is a patch you install it and deploy as fast as possible. And if it contains any severe patch it is even the vendor who recalls all the equipment with service bulletin and advisory letters.
With life critical you don’t wait the bug to appear because It maybe too late to avoid deadly consequences.
No. If you’re working with life-critical systems, you only apply patches that are relevant to you. For example, an implantable insulin pump with Bluetooth capability. If there’s a patch that changes the Bluetooth functionality, but you don’t use that functionality, there’s no point in applying the patch.
Oh yes, why would I apply a security patch for Bluetooth which I don’t even use, on my life-supporting device which someone else could connect to via Bluetooth without me knowing or noticing?
What you are saying is far from reality. Most patches only state vague stuff like “security” or “Bluetooth”.
How would you know, what those mean? Bluetooth could be “Hey, you can now monitor even more with your app” or “fixed some big holes in the chips security which made it hack able via Bluetooth”.
You say it’s far from reality, but I’m speaking from experience. I was responsible for maritime life safety systems. When those systems were implemented, they were tested and qualified for use. It didn’t matter how many updates came out, if they weren’t qualified, they didn’t get deployed. If I had deployed an update that hadn’t been qualified, it would have put lives at risk, such as by causing issues with ship detection or man overboard alerts not going off.
If you want to get really into it, like the systems that run aircraft and nuclear reactors, look up formal verification.
Okay,so you are talking professional equipment with software patches to be applied by professionals.
The article (and also the comments as I understood them) was about end users updating software themselves. Those are two very different things.
Yes, we also only update needed patches on systems we handle, but as an end user I do not check all updates that I apply on my private PC.
Why would I?
Yes you do,
Configuration control is a max in this world and you don’t have the control/ability/power to decide which patches go in or stay out. The vendor, the person who has all the power and knowledge, is the one who decides.
You can loose all your certifications or being held liable for any problem due to that policy.
Not even red hat (certainly not a life critical system) allows a different level of patches/state out of their approved ones
Then we disagree. Think about it, you’re patching the OS so what you now have is an untested configuration, and you’ve replaced a working system to get there, on the theory that you might be preventing an unknown bug in the future.
In one instance the vendor even explicitly recommends disabling OS updates until they have tested them.