[clug] How you know your Free or Open Source Software Project is doomed to FAIL

Scott Ferguson scott.ferguson.clug at gmail.com
Thu Jul 30 17:12:26 UTC 2015

On 31/07/15 01:45, Michael Cohen wrote:
> On 30 July 2015 at 14:51, Scott Ferguson <scott.ferguson.clug at gmail.com> wrote:
>> 'If' you value the integrity of a given machine highly you 'could'
>> hard-code the DNS (put it in /etc/hosts).
>> DNS (cache) poisoning is not something new or occult. DNSSEC is another
>> alternative worth considering. (again) set your standards to suit your
>> requirements (providing you know your requirements). VM is not hard.
>> If, as is likely an opponent like the NSA, can control routing - but you
>> combine DNSSEC (which Google uses) with SSL, then NSA has to step up
>> their game. Their resources are not infinite.
> DNSSEC is irrelevant - DNS poisoning is already defended against by SSL.


Could you expand on how when the DNS cache has been poisoned and a CA
compromised (or the site being masqueraded has had it's cert and private
key/chain stolen) the visiting machine detects this?

>> Alternative DNS verification schemes won't solve all problems (nothing
>> does). You can't control routing outside of your local network (and
>> maybe not even there).
>> Regardless of which method you use to authenticate the relationship
>> between the (alleged) owner of an SSL certificate, and the host, or what
>> containment you use to execute the code - it's not over if you can
>> verify *what* you are receiving.
> The use of PGP package signatures might make you feel more secure but
> it is exactly the same as serving those packages from an SSL protected
> server. Consider the threat model:
> - If your server keys are compromised, attacker can MITM the package
> (This is the same as if your PGP key is compromised).
> - If your server itself is compromised attacker can plant a modified
> package - the same as if your PGP keys are compromised.
> - SSL does not automatically mean the code is secure - a malicious
> distributor can distribute anything from an SSL protected site - also
> anyone can sign anything package with their PGP key - just because it
> is signed it does not mean its secure.

I'm not sure what your point is - you present that like I've argued a

SSL is a security improvement
Having SSL is an indicator a project is more likely to succeed in the

I don't believe I've said that SSL improve the verification of a signed
package. It is part of the verification process. A process that involves
more than just the package (it involves the developers and all the

And analogy:-
you make a splendid widget, it conforms to all the ISO standards for
widgets, it is highly praised in the press, it's renowned for it's
consumer protection seals and the high-tech holograms that proves it is
the real widget, you sell if from an unmarked building with no signage
out of an office that doesn't display a street sign.

> I think in any conceivable situation you consider a failure with an
> SSL hosted package, PGP is also the same. 

They are separate issues - I've pointed 'that' out before. See the lotto
analogy - the combination don't measurably increase trust or indicate a
higher probability of security.

> Except SSL is transparent
> and much easier to use. With certificate pinning SSL is less
> susceptible to CA attacks.
> BTW the example you gave before of DNS poisoning (modifying the hosts
> file) or adding root CA already require root access. If you have root
> access to the machine why would you even care about backdooring a
> download?


My concern, and I believe so was Alex's, was that sudo curl | bash *is*
the backdoor. If you read the example I posted "echo "some IP
somedomain">>/etc/hosts I didn't say anything later coming back for a
backdoor - it was implict that the script could do more than just add an
entry to hosts.

You've completely lost me here - I'll read through all the emails again

> Michael.

More information about the linux mailing list