Hi Arnold, arn...@skeeve.com wrote: > > This is a whole longer topic about future directions of infrastructure > > but in the comparison of https and ssh then ssh is the better. In the > > difference between anonymous access by https and anonymous access by > > git:// then I worry about recommending git:// moving forward. > > So you're saying https:// is preferable to git:// ?
Look at it from the side of the No Compromise security advocates. The git:// protocol is unencrypted. It would be possible for well positioned actors to modify the data stream in flight. (ISPs *have* been caught removing STARTTLS from the options in plain stream SMTP connections.) Therefore "is it possible" for someone to modify the source code in a git repository by modifying an in flight clone using the git:// protocol? When asked "is it possible" one doesn't need to know any more of the question as the answer is almost always yes. Git uses SHA1 hashes. On the cryptographic scale SHA1 is now broken. Therefore in theory it is possible and in practice people are clever and less likely attacks have been successful therefore we can't say that git can detect this itself anymore. The GNU Project has been pretty slack, as compare to other projects such as Debian, with regards to security. Security is left up to each individual project maintainer. Which means that every project is unique. Every project must be evaluated individually on the scale of security. There are vague general guidelines but different maintainers feel more or less strongly about them and implement either more or less security depending upon it. Traditionally GNU has relied upon tar files for source distribution. And next to the tar file is a detached checksum or signature file. The guideline for downloaders is that they should download both and then verify the signature. If they do that they the signature is the protection for the tar file. The detached signature has some security problems associated with it and is also troublesome. Using git clones is a new thing and the process flow not well understood by the public at large. Ask ten developers around you (around you on the net) how do they verify the integrity of their freshly cloned git working copy? I dare say there will be at least nine blank stares. We trust the git SHA1 hashes to a very large degree and on the scale of security those have been broken. That isn't to say that carrying out a successful attack would be easy. On the contrary I think carrying out a successful attack would be extremely difficult in practice. But time passes and these things become more practical. Or are revealed as having actually been successful after the fact. Therefore there is a lot of community peer pressure to use https which is encrypted and should avoid the man-in-the-middle attack vector entirely. Or ssh. The theory goes that if one cloned using https or ssh and the https/ssh layer was tight then one should be able to trust the resulting git clone using SHA1 even though SHA1 has been broken. A lot of people would like to have http and raw git and raw svn and raw cvs shut off entirely. (I would need to search through gnu-prog-discuss to find specific messages but over the years that has been a view expressed there. If the topic launched there again I am sure that would be a significant viewpoint.) We still use anonymous ftp downloads too and that is the same problem. However the web browsers are starting to remove ftp from the web browser protocol now too for example. I don't think anyone using a web browser will miss not having ftp available in it. Therefore I am not sure about recommending git:// in the year 2019 and moving forward. I have been pushing back and keeping it available. But that isn't the same as recommending it. That https isn't quite as robust yet in the presence of network attacks reflects that we haven't spent the effort yet to make it more robust. Perhaps we should install web-application-firewalls in front for example. We definitely should spend more time developing "fail2ban" style rules to detect abuse and try to deflect it. And because there are a collection of daemons that must work together then for best use it requires a more advanced way of managing how many processes each can spawn in order to service traffic load within the available memory and cpu resources available. Or perhaps simply brute forcing the problem by adding more VM resources to it. I have been thinking that perhaps as a compromise to make the secure protocols the default but keep the insecure protocols available we should split the DNS name space of systems into secure and insecure names. Keep secure by default with the current names. Add "insecure" names and move all of the insecure protocols there. For example then one could git clone git://git.insecure.savannah.gnu.org/foo.git but that would make obvious the security level expected from that name. Hopefully that would satisfy (at least for now) the strong security everywhere advocates. And in the future they can aim at shutting down those entirely too. This is the first I mention this idea publicly. In other words, everyone feel free to comment. > > > I understand that ssh is best, but there's no reason for me to ask for > > > contributor access on all the GNU projects I follow via git! > > > > Definitely agreed! > > > > Perhaps it would be best to publish the https url and also the git url > > as as a fallback in the case of temporary problems? > > Not sure what you're suggesting here? I am weaseling a little because I don't know the right answer. But I worry about recommending git:// moving forward. Otherwise we might go from recommending it to forbidding it. That seems bad. Even though https has not so obvious practical problems and hidden complexity that advocates don't realize and that I don't like but if the requirement is no-compromise security then it is the only anonymous protocol in the list to choose from. Therefore we can only work through the problems caused by it. A certain level of unreliability seems to be the tradeoff for the gain in security. This mail is already long and I should stop but I must mention that there is some possibility of using an anonymous ssh login. Some systems make that available. I have played with it but haven't been able to successfully create a working environment. But potentially an anonymous ssh login could be used and then it would be available in the list of secure encrypted anonymous protocols as well. Bob
