Delivery-Date: Sun, 07 Dec 2014 07:53:36 -0500
Return-Path: <tor-talk-bounces@lists.torproject.org>
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on moria.seul.org
X-Spam-Level: 
X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED,
	DKIM_SIGNED,FREEMAIL_FROM,RCVD_IN_DNSWL_MED,RP_MATCHES_RCVD,T_DKIM_INVALID,
	URIBL_BLOCKED autolearn=ham version=3.3.1
X-Original-To: archiver@seul.org
Delivered-To: archiver@seul.org
Received: from eugeni.torproject.org (eugeni.torproject.org [38.229.72.13])
	(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by khazad-dum.seul.org (Postfix) with ESMTPS id 4B5381E01B3;
	Sun,  7 Dec 2014 07:53:34 -0500 (EST)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id D05C331E4E;
	Sun,  7 Dec 2014 12:53:28 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 0320031E44
 for <tor-talk@lists.torproject.org>; Sun,  7 Dec 2014 12:53:25 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at 
Received: from eugeni.torproject.org ([127.0.0.1])
 by localhost (eugeni.torproject.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id X9MFgL8wmAQr for <tor-talk@lists.torproject.org>;
 Sun,  7 Dec 2014 12:53:24 +0000 (UTC)
Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com
 [IPv6:2a00:1450:4010:c04::22c])
 (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
 (Client CN "smtp.gmail.com",
 Issuer "Google Internet Authority G2" (not verified))
 by eugeni.torproject.org (Postfix) with ESMTPS id 98BC631E23
 for <tor-talk@lists.torproject.org>; Sun,  7 Dec 2014 12:53:24 +0000 (UTC)
Received: by mail-lb0-f172.google.com with SMTP id u10so2591451lbd.17
 for <tor-talk@lists.torproject.org>; Sun, 07 Dec 2014 04:53:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=mime-version:in-reply-to:references:date:message-id:subject:from:to
 :content-type; bh=1byHMh+ZBy0VeU6MHrHo7YhA+/hpoj61ta/lHxKMLQU=;
 b=a6bdLPvxbO3NpjT6uaSWmxm4CUUSaX3MWEKOLo264jMfJt46ySiIogtGvfqNCTjplu
 gpdyAepNlE6+8htoDXbXeVCf5YrKjyjAijtK1mVq4fz2tQ0ivD4JDVJFO2028reaUgAa
 1ZVWd6U/WzNZL+q7MNlpPYxnHf7k+Yz08PxCML3204p+MX6wdITtFMPaA26rvo8qZZp7
 EDantwYWoUY6b7qDzHKmnpB5gMwjRQckvazqOajkde3H3oDQCf66l6N3Czx8MKJZGEnw
 Sr2OZpl2vCTOhEQ3DOGc+TYFAp7uGGbDR9EZDMkjI2IiU1zXZfF+SoYwEJRKP0u4NCnH
 dIOw==
MIME-Version: 1.0
X-Received: by 10.152.19.71 with SMTP id c7mr11574101lae.79.1417956801228;
 Sun, 07 Dec 2014 04:53:21 -0800 (PST)
Received: by 10.112.156.225 with HTTP; Sun, 7 Dec 2014 04:53:20 -0800 (PST)
In-Reply-To: <20141207120351.GA30113@lo.psyced.org>
References: <20141207023823.15123l26w3vbay2o@www.vfemail.net>
 <CAJVRA1RaBkxNGLmTSSDOLSNijeTYX0EohOOeCw+LLMfeDJJ-kg@mail.gmail.com>
 <20141207105039.GA28271@lo.psyced.org>
 <CAJVRA1RHjoKTFsELdm7pnpHEmPO-vZiio9AzhtbX4n=B8UoMcg@mail.gmail.com>
 <20141207120351.GA30113@lo.psyced.org>
Date: Sun, 7 Dec 2014 04:53:20 -0800
Message-ID: <CAJVRA1QGafpLRHAQZhEpFKK1R1wQFhfHv4mDwJe9tQM50abKrQ@mail.gmail.com>
From: coderman <coderman@gmail.com>
To: tor-talk@lists.torproject.org
Subject: Re: [tor-talk] Qubes? debian? binary? reproducible? (was:
	EGOTISTICAL something)
X-BeenThere: tor-talk@lists.torproject.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tor-talk@lists.torproject.org
List-Id: "all discussion about theory, design,
 and development of Onion Routing" <tor-talk.lists.torproject.org>
List-Unsubscribe: <https://lists.torproject.org/cgi-bin/mailman/options/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=unsubscribe>
List-Archive: <http://lists.torproject.org/pipermail/tor-talk/>
List-Post: <mailto:tor-talk@lists.torproject.org>
List-Help: <mailto:tor-talk-request@lists.torproject.org?subject=help>
List-Subscribe: <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: tor-talk-bounces@lists.torproject.org
Sender: "tor-talk" <tor-talk-bounces@lists.torproject.org>

On 12/7/14, carlo von lynX <lynX@time.to.get.psyced.org> wrote:
> ...
> If it took ages to find heartbleed in the source, how likely is it
> that a backdoored binary is found?

if the source is available, how likely is it to be reviewed?

(to play devil's advocate, if heartbleed was found via protocol
fuzzing, then a rogue binary just as likely to be identified - the key
variable is "scrutiny", whether as source code review or protocol
testing of built application)

finding backdoors or vulnerabilities a problem for every
implementation, open source or not.  source based or not. reproducible
builds or not.

it's hard to not get depressed at the current state of technology and
software. we must do everything better!



>> this is two concerns:
>>
>> 1) if built packages can be verified independently. (reproducible builds)
>> 2) if packages are distributed to users securely. (signatures on pkgs,
>> etc.)
>
> Not really, (2) has to happen in any case - but if you distribute binaries
> that comply to (1) then you get both advantages.

"Not really" - do you mean they are not separate? or that everyone
should do #1 correctly, and get #2 for free?

(i agree that #1 is better)



> So why talk of the harder class of vulnerabilities if we haven't fixed
> the easier to fix class of vulnerabilities yet? Insecure binaries.
> I am talking of getting rid of the easier to introduce vulnerabilities.

this comes up in many circles, "why fix Y when we can't even do X well?"

as stated again, we should be doing everything better. but if you fix
the easy vulns, the hard ones all of the sudden become focus.

as an example, it used to be you could ignore active
monkey-in-the-middle threats in most situations, because they were
difficult and rare.  with the advent of wireless networks,
sophisticated tools, and easy access MitM became not-uncommon.

why talk about it?  so we can fix what is broken. (easily broken, or not)

(assuming we haven't drowned in sorrowed muted by string drunk first ;)



>> how do you securely distribute sources to be built?  a source based
>> distribution has different trade-offs, rather than being immune to
>> tampering.
>
> Gentoo provides cryptographic hashes for all tars and zips it uses
> for over ten years now. It's really no black magic.

i was speaking more to signatures and key distribution that validating
digests. where did you get the list of hashes? who was it signed by?
would you know if private keys were stolen and your list was a
forgery? etc.



> Gentoo has other
> issues and I don't understand why there is so little interest in
> OS built from source. If techies were admitting what a crazy risk
> it is to trust binary distributions, maybe source-code based ones
> would be much more advanced usability-wise by now.

i like gentoo, yet i see why others have a preference for pre-built as well.

the most usable source based distribution still needs to be built, and
that is both time consuming and resource intensive, comparatively.

again, different set of trade-offs. (we should do everything better!)



> But you need to bootstrap from binaries that somebody else made
> and that cannot immediately be rebuilt reproducibly. I hope
> this will soon change, but as long as this isn't the case, I don't
> understand why debian derivates are treated as being secure.

you emerge from a stage1 boostrap as well, don't you?  per Ken
Thompson, and "On trusting trust", this rabbit hole goes quite deep.

as for treating any distribution as "being secure" who is saying that?
certainly not me.

they are all vulnerable, to varying degrees.  we need to do everything better!



>> if there's one thing we've learned the last few years, it is that all
>> avenues are pursued. backdoors and exploits both, and at all levels,
>> from operating system to end user applications.
>
> Yes, that's why I question all non-reproducible binary distributions.

question everything!  (the sources, the default configurations, the
distribution, ...)

because, as i like to say in this thread, we need to do everything better.


best regards,

P.S. this topic is getting pretty off-topic. perhaps general
discussion on software insecurity could continue in depth elsewhere if
you wish.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

