[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 05:45:18 UTC 2015


On 30/07/15 14:05, James Ring wrote:
> Hey Scott,
> 
> On Wed, Jul 29, 2015 at 8:59 PM, Scott Ferguson
> <scott.ferguson.clug at gmail.com> wrote:
>> Downloading anything which is not verifiable, from a http source leaves
>> you open to MiM attacks - what you subsequently download may be not what
>> you think.
> 
> Please tell me what you think you mean by "verifiable". :)
> 
> https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf
> 

I'm assuming you didn't read all my previous post, or you just didn't
get the point of that (very old) and well known article?

Something that can *sensibly* be confirmed. i.e. a cryptographic chain
of trust. To a degree commensurate with the appropriate level of trust
for the intended environment.

I do hope you not seriously proposing that because a compiler can be
compromised that you should therefore trust everything? (code can be
audited, you don't have to compile with GCC).

While Shamir's 1st and 2nd laws[*1] hold true - it doesn't mean that
some deductive logic that uses that as a premise and arrives at the
conclusion that nothing is verifiable, therefore everything is worth
equal trust - is valid logic. That would be childish and silly.

Context is good. Do you know what you are risking? If so set an
appropriate level of trust.

If that's too hard there is the risk that something will be
oversimplified to the point of being stupid. The extrapolation of which
is what pilots call the Swiss Cheese effect - when the sum total of the
holes in your safety procedures adds up to disaster.

Security is hard, as is critical thinking (at least, for me), which is
why so many people who "believe" they are safe are like the bloke that
jumped off the 10th floor and was heard to say "so far so good" as he
passed the 5th. Some "tests" are unintentional, many result in
situations where the tester does not recognise the consequences until
it's too late to avoid the outcomes.


[*1]
1. Absolutely secure systems do not exist
2. To halve your vulnerability, you have to double your expenditure
3. Cryptography is typically bypassed, not penetrated


Kind regards



More information about the linux mailing list