Search Mailing List Archives

Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[liberationtech] TrueCrypt Alternatives?

Rich Kulawiec rsk at
Sat Oct 4 03:30:21 PDT 2014

On Fri, Oct 03, 2014 at 10:23:09PM +0000, Jonathan Wilkes wrote:
> Hi Rich,  Your footnote #1 is dubious at best. The cost of
> aiming peoples eyes at bugs is _not_ $0. Until it is, the free software
> community has a problem with too few resources chasing too many bugs.

I'm not sure why you're bringing up by the cost, but I'll certainly
agree with the second sentence: yes, there are too many bugs and
too few people working on them.  We seem to have backed into triage
mode partly because of the aggregate size of the code in play,
partly because of the increasing sophistication of attacks, and
partly because we've all developed a lot of bad habits (including
complacency).  I think the past year and probably the next couple
of years are going to see some major changes: I think a number
of projects need to adopt an approach similar to that of OpenBSD's, [1]
which is fanatical, intolerant, pedantic, demanding...and effective.

But all that said, peer review remains the very best tool we have,
even when it sucks, even when it isn't fast enough, even when it
isn't thorough enough, even when *anything*.  That's why science,
law, engineering, medicine, use it: there isn't anything better.

Should bash have undergone this years ago?  Oh, sure.  But it didn't.
So the best we can do is to do it now, do it thoroughly, sweat the
details, argue, test, patch and try not to repeat the error(s).
And then we need to tackle all the other critical pieces of software
infrastructure: postfix and freeradius, nagios and subversion,
nginx and mariadb, top and stunnel -- everyone's laundry list will
vary, but there are a lot of semi-visible moving parts that make
up the 'net's infrastructure and no doubt many of them are languishing
in vulnerable states.

So: we need to get better at auditing code.  We need to do more code
auditing.  We need to get better at writing code so that the previous
two items aren't so onerous.  We need to [do a bunch of other things too].

We also need to insist, without exception, that everyone put all
of their work on the table for inspection.  Some will choose not to
acquiesce to that, and that's fine: but if/when that happens, we
shouldn't expend another minute on it: dismiss and move on.  As I
snarkily said back when I wrote that long piece: source or GTFO.
Anything that is not 100% open source can be, should be, and must be
discarded immediately, with prejudice.


[1] Speaking of which, given this week's Xen vulnerability disclosure
and the resulting disruption of numerous services/sites, I think
it's worth citing this quote:

	"You are absolutely deluded, if not stupid, if you think that
	a worldwide collection of software engineers who can't write
	operating systems or applications without security holes,
	can then turn around and suddenly write virtualization layers
	without security holes."
		--- Theo De Raadt

Seems rather prescient now, doesn't it?

More information about the liberationtech mailing list