[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 10:52:44 UTC 2015


On 30/07/15 16:05, James Ring wrote:
> 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?

I don't set your limits. ;)

I try and assume best intentions. Was I wrong to assume you'd read the
other posts including my response where I mentioned Shamir's laws and
Debian's chain of trust?  (moot question - my time machine is in for a
service so we can't go back).

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

It's not automatically a deal breaker. It is a dumb thing for reasons
I've previously tried to illustrate with a food metaphor (which means
I'm hungry).
Would an extra step be a deal breaker? e.g. Virtualmin's install routine

Note: we are talking in the context of the Subject:

If you do take the time to dig through the earlier posts you'll see
(somewhere there) that I've posted a link to a later version of that
list - which might be possible to add to (it's a wiki).

The purpose of that list is to find indicators of project success - I
would call the curl or wget > bash a sign of stupid, which doesn't augur
well for the project's success (long-term). It's not a racing
handicapping guide though (it could be wrong).

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

OK...

> Maybe I'd give the script a quick glance, but I'm basically just going
> to do it. 

That sounds like a sound idea - dependant on what you have to lose, and
how much time you have.

The point I was trying to make in the analogy I gave earlier is that if
you give people a guide to downloading the script, and then running it -
they make take the opportunity to do what you are proposing.

Just a random thought from a hungry, low sugar mind - how hard is it to
host a script on that domain?  Any sort of peer review?

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

I'd suggest the offer users documentation for both steps, the order
seems important to me e.g.:-

====How to install====

[code]
#Download the script
wget something
#Make it executable if you want to inspect it do "cat something | more"
chmod +x something
#run the script
[/code]

===short way to install===

[code]
curl something | someshell
[/code]

The point (subject of this thread) is to instil confidence in the
project so that it will attract uses and achieve long-term success.

> :P
> 
> Regards,
> James
> .
> 


I hope that make sense.

Kind regards

--
"I use readability tools, I also try and employ critical thought, and I
rely strongly on proofreaders. I'm not a professional writer. I've used
none of those things when writing this, and it only "seemed" OK after a
quick re-read - my apologies in advance for all the very likely errors."
~ standard weasel disclaimer



More information about the linux mailing list