laigualdad at riseup.net wrote:
As to what Julian Assange said, he mentioned that Debian's package system
design (where things depend on each other) is somehow an insecure design
because all it takes is compromising one or a few packages. Does he know what
he is talking about, or is there an apparently more secure design approach to
operating systems?
Let's review what he said. I watched the video and typed in this
transcript from what I heard him say.
===========================================
Questioner: Now, one of the big topics here is open source and I'm
wondering whether the fact that you have an open system where everyone
knows how it works would make encryption more secure than a closed system?
Assange: We know from experience that it does seem to be the case; that
there's a vast number of closed source snake oil encryption systems
being spread around. Now we know that open source is not entirely a
solution. For example, there was an encryption bug in Debian's version
of SSH in the random number generator which existed for years and that
was all open source. Now it was eventually found and revealed also
because it is open source. But the way things are done now is bug doors:
these are back doors designed to look like bugs. And what is the
security of the programmers who are involved in some of these open
source systems? Can you, when they update their code, can you implant
what looks like a bug, even a typo that carries through? Or, say, look
at a system like Debian, the various kinds of Unix systems. Look at all
the packages they include. Look at the upstream binaries -- dependencies
upon dependencies upon dependencies. All you need to do is compromise
one of these dependencies and then there's a flow through and these all
get embedded. I mean, these modern systems now, are assemblages of
incredible intellectual content which is being developed all over the
world over the past 10 years by many different players. It is the nature
of our CPUs that there is only a few, you know, maybe 3, different
security layers in our systems. But when you pull together thousands of
packages all together it's pretty hard to resist the security
compromises that are engineered by nation-states. It doesn't mean that
it's not worth trying and increasing the cost of owning the world.
===========================================
I don't immediately see how interdependency is inherently insecure nor
do I see how interdependency is avoidable. I would like to know more
about a design that avoids interdependency. I figure this is basically
impossible because every OS I know of runs programs atop system
libraries. So if there's a vulnerability in a system library, every
application inherits that vulnerability unless it takes steps to work
around the issue. In the Free Software world I doubt developers do this
because developers can patch the system code and use the system code as
intended.
The only approach I can see to solving this issue is the hard work
developers and distributors should be doing anyhow: greatly reduce the
number of packages in the distribution to those packages one can vet,
and then keep up with vetting source code and updates for those
packages. This is certainly work worth paying people to do (in other
words, a commercial opportunity unique to Free Software). Any OS
distribution aiming to do this would be wise to start with a 100% Free
Software system like Trisquel. By the way, I do not mean to say "open
source" or "FLOSS" here instead of "Free Software". The open source
movement is ready to accept non-free software out of convenience and
adherence to its developmental methodology which was designed to ignore
software freedom. Such goals directly contradict the purpose of the work
I just described.
Also: author seems to think Red Hat rules the GNU/Linux universe. What?
The blog author doesn't defend some of the points made in the article on
http://igurublog.wordpress.com/2014/04/08/julian-assange-debian-is-owned-by-the-nsa/
therefore I can't take that article too seriously.
A lot of that article is guilt by association -- Red Hat has US
government contracts, therefore Red Hat is a suspect in getting
insecurities into software they distribute (software that could be
distributed further by others, such as the Linux kernel). There's little
point in distinguishing between proprietors and the US Government, but
that doesn't make the Heartbleed bug an NSA plant nor does it mean
"Finland outed the NSA here". There's no clear evidence of Heartbleed
being anything but a mistake.
I don't buy guilt-by-association reasoning in this context precisely
because of the freedoms of Free Software -- so long as people have these
freedoms we have the tools we need to look out for our interests if
we're willing to apply the rigorous inspection and questioning that we
also require. Eliminating non-free software is a major step down that
road (thanks to Linux-libre and every OS distribution that distributes a
100% free system!).
If Red Hat were contracting for a non-free software distributor (such as
Apple, Microsoft, or Google) I'd certainly wonder about Red Hat's
involvement. Users of proprietary software aren't allowed to inspect,
alter, or distribute derivative programs. Those users have plenty of
reason to believe they're running malware
(https://gnu.org/philosophy/proprietary.html) and thus ample reason to
reject that software outright if they care about ethics, insecurity, or
software freedom.
Another example of an unexplained assertion in that blog post is "So it
comes as no surprise to me that they jumped on board systemd when told
to, despite the mock choice publicized to users – there was never any
option.". I don't understand how picking systemd over some other
mechanism to do the same job has a connection to letting in sabotaged
code leading to security exploits.
