> 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
