Gentlemen,

Can we take this off the forum NOW please?

By all means continue the debate somewhere else and eventually we can amend the 
guidance to reflect some balance between rigorous security and practicality for 
our very diverse set of 
contributors, but this debate is not suitable for what is supposed to be a 
low-traffic forum.

If this continues on the forum beyond the point at which you could reasonably 
have read my email I will ask the 
list admins to temporarily impose moderation on those involved.

        Steve

> On 3 Mar 2015, at 15:00, Sandeep Murthy <s.mur...@mykolab.com> wrote:
> 
>> HTTPS is the default github way. There is no other way to clone
>> from github if you don't have an account there.
>> What is your point?
> 
> You asked this earlier.  But then later you say.
> 
>>> It is not a moot point - when you clone a GitHub repo on the command line
>>> using git clone git://github.com/ etc. you are using the Git protocol to 
>>> access
>>> and make a local copy of a Git repo stored on GitHub.com.  GitHub.com
>>> “understands” the Git protocol and that’s why you can clone repos using it.
>> 
>> Sorry, I wasn't even aware of this. It's probably an old leftover. It's not
>> offered as an option if you look on the github webpage of any project;
>> it would only give you an https url or a subversion url (unless you are 
>> logged in and
>> have ssh keys uploaded, then it will offer ssh url).
>> I imagine the plain git can go away any day.
> 
> Almost all developers are aware of this.  That’s exactly my point, as I was 
> trying
> to explain.  With respect I don’t think you understand how GitHub works 
> currently.
> 
>> 
>> No, this is totally wrong point of view. Malicious code can be inserted 
>> anywhere,
>> in any piece of software which can potentially be installed with root 
>> permissions.
>> E.g. linux distributions have very elaborate security procedures for code
>> contributors, and for a good reason.
> 
> Yes malicious code can be inserted anywhere, but there are some who believe
> SSH is also broken.  I said you can use SSH as well, so I am not arguing 
> against
> using SSH, this should be determined by contribution guidelines which
> currently do not even mention SSH or HTTPS.
> 
> 
>>> 
>>> I just meant that HTTPS is the standard and also GitHub-recommended
>>> way of working with repos on GitHub for large distributed projects.
>> 
> 
>> Nobody forces you to have long ssh passphrases. On the other hand,
>> a short password is a good way to get hacked; passwords go over the networks,
>> while ssh passphrases do not.
> 
> I did not recommend a short password, but the degree of care you take
> about your password is an individual preference.  Obviously you should
> choose a good password andI I never suggested choosing an insecure
> crappy password.
> 
>> 
>> I would be vary of having a direct (i.e. with push rights)
>> contrbutor to GAP (or any, in fact) project
>> with such an lax attitude to security as you show here.
> 
> There is no lax attitude to security here - the degree of care a GAP
> contributor will take over their contributions should be guided by individual
> standards as well as recommended procedures - and currently neither HTTPS
> nor SSH is being recommended by your guidelines (CONTRIBUTING.md).
> 
> I think the guidelines should also mention things like signing and verifying
> commits using GPG, which is a good procedure.
> 
> The reason I replied in the first place was to change the guidelines to
> ensure that any contributor should use something secure like HTTPS and/or
> SSH.  If you want to use SSH over HTTPS fine (I also use it sometimes), but
> you should be aware of the pros/cons - SSH is not problem free.
> 
> Sandeep
> 
> _______________________________________________
> Forum mailing list
> Forum@mail.gap-system.org
> http://mail.gap-system.org/mailman/listinfo/forum


_______________________________________________
Forum mailing list
Forum@mail.gap-system.org
http://mail.gap-system.org/mailman/listinfo/forum

Reply via email to