Re: [tor-talk] Qubes? debian? binary? reproducible? (was: EGOTISTICAL something)

[coderman <coderman@xxxxxxxxx>]

On 12/7/14, carlo von lynX <lynX@xxxxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk