Bonjour,
Le Tue, 23 Aug 2016 19:50:30 +0200 Henrik Nordström henrik@henriknordstrom.net a écrit:
sön 2016-08-21 klockan 21:55 +0100 skrev Luke Kenneth Casson Leighton:
From a security point of view, open source code
I am feeling that there was some early cut here wrt the point discussed: what Raphaël was say is "From a security point of view, open source code is the best option since it allows to check if the code being run isn't malware".
With that in mind:
no it isn't... *libre* source code is...
I would love to hear your elaboration on how libre source code is more secure than open source. I don't see how libre have any relevance there.
Having access to the complete readable sourcecode and being developed in a trustworthy environment is very relevant. But that is by no means unique to libre or even proven to be an natural effect of libre. Those aspects come from other properties of the software projects than what makes the distinction between open/libre.
There is a slight difference though, at least if our understanding of "libre vs open" is similar enough, and bearing in mind Raphaël's statement above.
FTR, a TL;DR description of my own viewpoint would be "libre source is open source plus the ability, both legally and physically, to replace binaries built from said source with one's own possibly modified version" -- IOW, a 'thing' for which I can have source code but cannot rebuild and replace all of the binary code is not libre even though it may be said 'open source' without causing me to die gasping.
With this definition in mind, I see a difference between open and libre, in that with both, I can analyze the code, possibly discover risks, and potentially modify the source code so as to remove the risk, but only with libre can I actually eliminate the risk where it might arise.
This is where, considering Raphaël's statement, libre beats open: true, open source may allow checking whether some binary is a tampered build, but it does not necessarily allows fixing that; libre does.
(again, that's assuming the distinction above between open and libre.)
What the A20 is missing from a security perspective is secure boot procedure. There is some primitive support but not really functioning. Some of you may think I am crazy speaking about secure boot, but properly used it is a very strong tool for ensuring that the installed software is not tampered with by untrusted parties. But this requires that you are in control of the security keys and not some untrusted proprietary vendor.
Agreed that secure boot is a tool which can be used for good as well as bad. My personal opinion is that I'm fine with secure boot as long as there is a way back -- i.e. a way to revert the whole thing to a "blank" state where, yes, whatever keys were inside are erased so encrypted data that was on the device may be lost (except possibly to sufficient crypto-analysis resources), but the device can always be "refitted" with new keys for new data.
Regards Henrik
Amicalement,