[Arm-netbook] Verifying firmware
Albert ARIBAUD
albert.aribaud at free.fr
Wed Aug 24 10:31:13 BST 2016
Bonjour,
Le Tue, 23 Aug 2016 19:50:30 +0200
Henrik Nordström <henrik at 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,
--
Albert.
More information about the arm-netbook
mailing list