Re: [Savannah-hackers-public] git over https

[James Cloos]

> "BP" == Bob Proulx  writes:

BP> Thorsten Glaser poked us in relation to deprecating the cvs pserver
BP> support to use anonymous ssh (traditionally anoncvs) for this type of
BP> access.  See https://www.openbsd.org/papers/anoncvs-slides.pdf .  What
BP> would you think of using anonymous instead?  I think that would be a
BP> superior way to go.

The best way to do anonymous ssh is to publish a well-known async key (I
suggest the null ed25519 key) and tell users to use that to achieve read-
only anon ssh access.

But for git everyone else does smart-git over https.  Sv SHOULD, too.

-JimC
-- 
James Cloos  OpenPGP: 0x997A9F17ED7DAEA6

Re: [Savannah-hackers-public] git over https

[Bob Proulx]

Bob Proulx wrote:
> This isn't the final configuration though since this uses the package
> installed git, which should be fine but doesn't support shallow clones
> with --depth 1 yet as of the OS Trisquel 7 release with git 1.9.1.
> Therefore we are using git from a Debian Jessie Stable chroot with git
> 2.1.4.  The reason to use the chroot is to get a stable release with a
> community supported security release stream.  Therefore I need to
> point it to the custom version from the chroot.  Then everything
> should be working.

Done.  I tinkered this into working using the custom git and with that
shallow clones with --depth 1 work with http and https now too.

I think I will let things simmer for a bit yet before making any wide
announcements.  Just in case there is a more serious problem and we
have to revert.  That way people won't lose functionality.

Bob

Re: [Savannah-hackers-public] git over https

[Bob Proulx]

Leo Famulari wrote:
> Bob Proulx wrote:
> > Drat!  This does appear to be a regression.
> > 
> > In your opinion is that enough of a regression to warrent reverting
> > (once again) the git service back to the old server?  Of course that
> > means another IP address change thrash for people who have ssh
> > configured to watch such things.  And more delay in getting things
> > moved.  Sigh.
> 
> I'm not sure, because I've never set up the "smart" protocol, and thus
> have never been able to compare them from the same server. Perhaps one
> of them is more efficient, but I don't know. The only difference I've
> noticed as a user is the informative output. I think it's a major
> improvement to offer HTTPS, so perhaps the "smart" protocol can be saved
> for later.

I guess we get to avoid that question.  I researched the task and have
been tinkering the configuration together today.  I will copy the
nginx configuration here in case other people need to do the same
thing.  This would work for most people.

This isn't the final configuration though since this uses the package
installed git, which should be fine but doesn't support shallow clones
with --depth 1 yet as of the OS Trisquel 7 release with git 1.9.1.
Therefore we are using git from a Debian Jessie Stable chroot with git
2.1.4.  The reason to use the chroot is to get a stable release with a
community supported security release stream.  Therefore I need to
point it to the custom version from the chroot.  Then everything
should be working.

Bob

location = /git { return 302 $request_uri/; }
location /git/ {
location ~ /git(/.*) {
gzip off;
include fastcgi_params;
fastcgi_pass unix:/var/run/fcgiwrap.socket;
fastcgi_param SCRIPT_FILENAME 
/usr/lib/git-core/git-http-backend;
fastcgi_param PATH_INFO $1;
fastcgi_param GIT_HTTP_EXPORT_ALL true;
fastcgi_param GIT_PROJECT_ROOT /srv/git;
client_max_body_size 0;
}
}

Re: [Savannah-hackers-public] git over https

[Leo Famulari]

On Tue, Feb 07, 2017 at 03:18:32PM -0700, Bob Proulx wrote:
> Leo Famulari wrote:
> > I bet that most of them use the unauthenticated HTTP or Git protocols
> > and are vulnerable to man-in-the-middle attacks and eavesdropping.
> 
> Certainly it is vulnerable to easedropping.  And to some extent https
> metadata is also vulnerable too.  And since all of the hosted projects
> that might be downloaded is available to anyone I think that even with
> https it is possible for a well funded attacker with access to the
> metadata to know what someone has downloaded.  But with git using SHA1
> hashes for everything I think it would be quite the challenge to
> produce a viable modification attack.  (However I acknowledge that
> some of the proof of concept attacks for other attacks that I have
> looked at have quite surprised me by the cleverness used and that they
> did work.)

I don't think that the SHA1 hashes can protect somebody who is doing
`git clone` against MITM, because they would not already have a SHA1
graph that would become broken.

For `git fetch`, the attacker could add their changes after the most
recent commit.

> > I think this is a regression from the old Savannah server. The old
> > server appears to use the so-called "smart HTTP" Git protocol [0], which
> > provides informative output while it is working. On the other hand, the
> > "dumb HTTP" Git protocol [1] does not provide any output.
> 
> Drat!  This does appear to be a regression.
> 
> In your opinion is that enough of a regression to warrent reverting
> (once again) the git service back to the old server?  Of course that
> means another IP address change thrash for people who have ssh
> configured to watch such things.  And more delay in getting things
> moved.  Sigh.

I'm not sure, because I've never set up the "smart" protocol, and thus
have never been able to compare them from the same server. Perhaps one
of them is more efficient, but I don't know. The only difference I've
noticed as a user is the informative output. I think it's a major
improvement to offer HTTPS, so perhaps the "smart" protocol can be saved
for later.

Re: [Savannah-hackers-public] git over https

[Leo Famulari]

On Tue, Feb 07, 2017 at 02:29:36PM -0500, Paul Smith wrote:
> I'm not asking for _authenticated_ HTTPS support, just anonymous access
> over HTTPS.  More straightforwardly, I'm looking for HTTPS as an
> alternative to our current HTTP support, not an alternative to our
> current SSH support.

I'd like to clarify what I meant by "authenticated", just in case anyone
was confused. I'm only interested in using HTTPS to authenticate the
server to the client. It's possible to do it the other way around, but I
don't think it's necessary since anyone can use SSH.

So, I concur with Paul.

Re: [Savannah-hackers-public] git over https

[Bob Proulx]

Leo Famulari wrote:
> The advantage of HTTPS compared to SSH is that it can be used
> anonymously, without setting up a Savannah account. Currently, users who
> wish to fetch source code from Savannah using an authenticated protocol
> must create a Savannah account. This is inconvenient for casual users.

I am sympathetic.  And as you know we are heading toward https
everywhere that https can be used.  However you would not believe how
many things need significant effort in order to get there.  Because
over the decades the collection of services that is Savannah has
acquired quite a few features and warts.  Just git itself has moved
back and forth a half dozen times and been reverted due to showstopper
problems due to previously unknown conflicts.  It seemed a lot simpler
to me too before I became sucked into the machinery. :-)

> I bet that most of them use the unauthenticated HTTP or Git protocols
> and are vulnerable to man-in-the-middle attacks and eavesdropping.

Certainly it is vulnerable to easedropping.  And to some extent https
metadata is also vulnerable too.  And since all of the hosted projects
that might be downloaded is available to anyone I think that even with
https it is possible for a well funded attacker with access to the
metadata to know what someone has downloaded.  But with git using SHA1
hashes for everything I think it would be quite the challenge to
produce a viable modification attack.  (However I acknowledge that
some of the proof of concept attacks for other attacks that I have
looked at have quite surprised me by the cleverness used and that they
did work.)

> For this reason, I would not call HTTPS a fallback method, but
> rather in the same class as SSH.

I disagree.  I don't think https is in the same league here.  But that
doesn't mean I am trying to stop https.  Far from it.  I have put in a
lot of time trying to get everything moving forward.  It is available
now.

> >   git clone https://git0.savannah.gnu.org/git/emacs.git
> > Cloning into 'emacs'...
> > ... takes about twenty minutes with no output on my network ...
> 
> I think this is a regression from the old Savannah server. The old
> server appears to use the so-called "smart HTTP" Git protocol [0], which
> provides informative output while it is working. On the other hand, the
> "dumb HTTP" Git protocol [1] does not provide any output.

Drat!  This does appear to be a regression.

In your opinion is that enough of a regression to warrent reverting
(once again) the git service back to the old server?  Of course that
means another IP address change thrash for people who have ssh
configured to watch such things.  And more delay in getting things
moved.  Sigh.

> It takes me ~40 seconds to clone the Guix Git repository from
> . To me, that's pretty fast
> for an 83 MB download. And it's the same speed as cloning over SSH from
> the old server.

Of course I chose Emacs because it has a large repository of about
275M and my network is probably slower. :-)

Bob