[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