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

James Ring sjr at jdns.org
Thu Jul 30 06:05:39 UTC 2015

Hey Scott,

On Wed, Jul 29, 2015 at 10:45 PM, Scott Ferguson
<scott.ferguson.clug at gmail.com> wrote:
> 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?

Those are my choices?

> 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.

Agreed, of course.

> 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).

No, I guess I was just reacting to the idea that curl | sh is
automatically a deal breaker for an open source project. For example,
I would trust a tutorial published by Google on a HTTPS-secured
google.com site that asked me to run something through the shell.
Maybe I'd give the script a quick glance, but I'm basically just going
to do it. The possibility that somebody out there is going to somehow
modify the encrypted shell script response in-flight is just not a
concern to me. Also I'd think Google has more to lose by publishing
bad scripts than I do running them.

FWIW I work on a project at Google right now whose tutorials are going
to ask people to run small shell scripts via wget | sh and of course
whether people will want to do this has been a topic of much debate...


More information about the linux mailing list