But in any case, you how can you trust software and firmware? The programmer is only one amongst the earliest steps in chain of creation of the software or firmware. While in small shops, it's often the programmer who will produce the binaries for distribution, in bigger shops and notably when the software is enclosed in firmware, the original programmer is several steps removed from the actual production of the firmware or distribution media (eg. signing and uploading on AppStore), and at each of those steps, the software could be tampered with, if it wasn't defective at the origin. This is not to exonerate programmers (eg. in the case of the Toyota firmware, it was the programmers who produced the awful and fatal firmware), but to mention that a lot of parties, both inside and outside the corporation selling the software can introduce bugs or malware.
Therefore you need 4 things:
- you need to trust the hardware itself. If you've not built your microchips yourself from sand, can you trust Intel? Can you trust a Chinese chip? Can you trust a Russian chip? A couple of years ago, there was some scare from a paper describing some Chinese spying chip (it might have been a fake, but it's perfectly possible).
- you need to trust the OS (BIOS, system, tools), and the compiler. (cf. Ken Thomson's "Trusting Trust" and "Reflections on Trusting Trust", and Schneier's "Countering 'Trusting Trust'"). The point here, is that you have to have the sources to all those software components, and you have to compile them yourself, using a trusted compiler (and how do you get a trusted compiler? It's not entirely trivial, even if Scheneier gives a solution).
- now you need all the sources of the software and firmware of the concerned devices, so that you may audit them (otherwise, you might be using for decades software with obvious bugs, backdoors or other malware, cf. recent examples as the bash shell bug, the openssl bugs, the toyota firmware problems, and indeed, the VW hack, etc),
- and you need to compile and integrate/install it intot he device yourself, using the trusted OS and compiler obtained at step 2.
Now, of course, it's not the final user who can do all that. But as the countries have administrations to test and check the properties of drugs (eg. the FDA in the USA), and allow the drugs to be on the market only after strict checks and validations, countries could forbid the sale of any hardware containing software or firmware, and of any software, that:
1- is not provided in source form with all the required instructions and dependencies to compile and install it in the devices they want to sell, and
2- has not passed a full, precise and exhaustive "code review" mandated by a FSA (Federal Software Administration), and received thus an authorisation of sale, along with a FSA distribution of that software.
Now, for the state it would be ok to use that FSA distribution, but how a final customer (persons or corporations), could trust the FSA of their country. After all, their NSA could have introduced new backdoors, or the FSA could be corrupted by lobbies too! Therefore the alerted user or the concious corporation will want to have the sources and compile and install them themselves too, after an audit (which would be lighter, including eg. only a comparison of those sources with the one from the original company).
In conclusion, what you want is a law that forbid the sale of non-free(dom) software or firmware (because, if anybody introduced a backdoor in the sources, you want to be able to remove it for your own usage, or that of your friends or customers).
Forbid the sale of any non-free(dom) software or firmware!
