Re: [Savannah-hackers-public] git and https URLs not working

[Bob Proulx]

Hi Arnold,

address@hidden 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