Killing plaintext git:// in favor of https:// cloning

Killing plaintext git:// in favor of https:// cloning

[Jason]

Hello projects-with-mailing-lists,

Now that git.zx2c4.com runs over HTTPS, I'm considering getting rid of
the plaintext git:// endpoint for cloning.

This means:

git clone git://git.zx2c4.com/cgit
-->
git clone https://git.zx2c4.com/cgit

git clone git://git.zx2c4.com/password-store
-->
git clone https://git.zx2c4.com/password-store


Does anybody have any objections or comments?

Thanks,
Jason

Killing plaintext git:// in favor of https:// cloning

[Jason]

Well, uh oh speghettio!

Looks like somebody has published in paper the git:// URI:

https://books.google.fr/books?id=kJsQAwAAQBAJ&pg=PA314&lpg=PA314&dq=git://git.zx2c4.com&source=bl&ots=W6M9TlYzCY&sig=g-PY0glN2ddWygtFDLiHgbiC69I&hl=en&sa=X&redir_esc=y#v=onepage&q=git%3A%2F%2Fgit.zx2c4.com&f=false

Perhaps there's a way to write a dummy daemon that prints a message...

Killing plaintext git:// in favor of https:// cloning

[mailings]

On 22/02/16 19:16, Jason A. Donenfeld wrote:
> Hello projects-with-mailing-lists,
>
> Now that git.zx2c4.com runs over HTTPS, I'm considering getting rid of
> the plaintext git:// endpoint for cloning.
>
> This means:
>
> git clone git://git.zx2c4.com/cgit
> -->
> git clone https://git.zx2c4.com/cgit
>
> git clone git://git.zx2c4.com/password-store
> -->
> git clone https://git.zx2c4.com/password-store
>
>
> Does anybody have any objections or comments?
>

Yes, why?
What's the point?

The repos are public, so cloning them over https bring nothing, except 
extra overhead and server load.


> Thanks,
> Jason
> _______________________________________________
> CGit mailing list
> CGit at lists.zx2c4.com
> http://lists.zx2c4.com/mailman/listinfo/cgit
>

-- 
Ferry Huberts

Killing plaintext git:// in favor of https:// cloning

[Jason]

On Mon, Feb 22, 2016 at 8:18 PM, Ferry Huberts <mailings at hupie.com> wrote:
> Yes, why?
> What's the point?

So that the contents of the repository cannot be modified in transit.

Killing plaintext git:// in favor of https:// cloning

[normalperson]

"Jason A. Donenfeld" <Jason at zx2c4.com> wrote:
> Now that git.zx2c4.com runs over HTTPS, I'm considering getting rid of
> the plaintext git:// endpoint for cloning.

> Does anybody have any objections or comments?

I suggest keeping git:// running as automated mirrors may not be
monitored very closely or easily updated.

git already has plenty of integrity checking built-in and
getting the proper hashes for the heads/tags over a
trusted-enough medium is enough (or reading the fine code).

And as others have said, HTTPS isn't impenetrable and the
CA system is still a major problem.

Also, TLS libraries can introduce new bugs and vulnerabilities
like Heartbleed.  Quoting from http://www.postfix.org/TLS_README.html

|  By turning on TLS support in Postfix, you not only get the
|  ability to encrypt mail and to authenticate remote SMTP clients
|  or servers. You also turn on thousands and thousands of lines of
|  OpenSSL library code. Assuming that OpenSSL is written as
|  carefully as Wietse's own code, every 1000 lines introduce one
|  additional bug into Postfix.

Something to keep in mind :)

Killing plaintext git:// in favor of https:// cloning

[Jason]

https://git.zx2c4.com/git-daemon-dummy/about/

I just wrote this.

Will consider whether or not to deploy it.

Killing plaintext git:// in favor of https:// cloning

[Jason]

On Tue, Feb 23, 2016 at 2:19 AM, Eric Wong <normalperson at yhbt.net> wrote:
> I suggest keeping git:// running as automated mirrors may not be
> monitored very closely or easily updated.

That's a good point. I'd forgotten about automated mirrors. I'll keep
logs of the git:// pulls for a month or so and see if there are any
regular pullers and also if I can track down the source IP. Perhaps
it's a manageable pool of people to switch over.

> git already has plenty of integrity checking built-in and
> getting the proper hashes for the heads/tags over a
> trusted-enough medium is enough (or reading the fine code).

No, git's built-in integrity protection really is not sufficient if
the transport is compromised.

> And as others have said, HTTPS isn't impenetrable

I'd like some specific details on this repeated claim.

> the CA system is still a major problem.

True. But there doesn't appear to be a widely deployed alternative.

> Also, TLS libraries can introduce new bugs and vulnerabilities
> like Heartbleed.

This is true, but I already require a public TLS deployment, so it's
there regardless.

Killing plaintext git:// in favor of https:// cloning

[normalperson]

"Jason A. Donenfeld" <Jason at zx2c4.com> wrote:
> On Tue, Feb 23, 2016 at 2:19 AM, Eric Wong <normalperson at yhbt.net> wrote:
> > git already has plenty of integrity checking built-in and
> > getting the proper hashes for the heads/tags over a
> > trusted-enough medium is enough (or reading the fine code).
> 
> No, git's built-in integrity protection really is not sufficient if
> the transport is compromised.

git commits, tags, and request-pull-formatted emails (with
unabbreviated commit IDs) may all be signed with GPG.

Once those are verified, "git fsck" results can be trusted.

> > And as others have said, HTTPS isn't impenetrable
> 
> I'd like some specific details on this repeated claim.

The known problem would be CAs being compromised.
I've also heard of MITM stripping proxies; but don't know
much about them.

> > the CA system is still a major problem.
> 
> True. But there doesn't appear to be a widely deployed alternative.

GPG-signed tags/commits/emails.  Probably not as widely deployed
as TLS CAs, but probably sufficient in Free Software circles.

> > Also, TLS libraries can introduce new bugs and vulnerabilities
> > like Heartbleed.
> 
> This is true, but I already require a public TLS deployment, so it's
> there regardless.

Vulnerabilities may affect clients, too (for example, the recent
OpenSSH roaming vulnerability).  IMHO, users should be given a
choice of which poison to pick.



Disclaimer: Personally, I don't GPG sign anything, myself,
either.  For selfish reasons, I do not want people to trust me
or my signature and would prefer they read and scrutinize
what little I write.  And we can't rule out undiscovered
vulnerabilties affecting GPG, either.

[pass] Killing plaintext git:// in favor of https:// cloning

[Jason]

On Tue, Feb 23, 2016 at 2:53 PM, Brian Minton <brian at minton.name> wrote:
> Certainly got can sign individual tags with an OpenPGP key. Each commit is
> also hashed and the hashes are known. If you sign every commit, or at least
> every release, the code can't be tampered with. This is the workflow of, for
> instance, the Linux kernel.

False. Commits in Linux development are not routinely signed.

[pass] Killing plaintext git:// in favor of https:// cloning

[Jason]

Yes, releases are. Obviously this conversation extends to much more
than releases, though. I sign tags too:
https://git.zx2c4.com/cgit/tag/?h=v0.12

Killing plaintext git:// in favor of https:// cloning

[hacking]

On 02/22/2016 07:16 PM, Jason A. Donenfeld wrote:
> Does anybody have any objections or comments?

git:// should be removed from clone urls

Cheers
Daniel

Killing plaintext git:// in favor of https:// cloning

[Jason]

Welp, in the last 2 days:

krantz log # grep git-daemon messages | grep 'Connection from' | wc -l
3079

So, I guess git:// will be sticking around, alas.

Killing plaintext git:// in favor of https:// cloning

[jea-signup-cgit]

On 22/02/16 19:16, Jason A. Donenfeld wrote:

>> Now that git.zx2c4.com runs over HTTPS, I'm considering getting rid of
>> the plaintext git:// endpoint for cloning.

Ferry Huberts Proclaimed Thus: 

>Yes, why?
>What's the point?
>
>The repos are public, so cloning them over https bring nothing, except 
>extra overhead and server load.

While pretty unlikely, in theory someone could MITM a git:// clone and
send the user a hax0red branch of cgit with integrated botnet which
the user then compiles and installs on their server.

Not sure if the extra server load is worth it to defend against this
case or not.  (Also, presumably the server is using the cgit smart http
endpoint so https clone is not much additional DATA, just the ssl
handshake; but definitely additional cpu for crypto operations.)

Thanks
-Joe

Killing plaintext git:// in favor of https:// cloning

[webmaster]

On 22/02/16 02:50 PM, Joe Anakata wrote:
>> Yes, why?
>> What's the point?
>>
>> The repos are public, so cloning them over https bring nothing, except
>> extra overhead and server load.
> While pretty unlikely, in theory someone could MITM a git:// clone and
> send the user a hax0red branch of cgit with integrated botnet which
> the user then compiles and installs on their server.
>

Everything is possible "in theory" ... But folks really need to stop 
thinking that https is the impenetrable solution to everything.

Killing plaintext git:// in favor of https:// cloning

[Jason]

On Mon, Feb 22, 2016 at 8:57 PM, Eclipse Webmaster (Denis Roy)
<webmaster at eclipse.org> wrote:
>
> Everything is possible "in theory" ... But folks really need to stop
> thinking that https is the impenetrable solution to everything.

Are you aware of some attack on TLS 1.2 that I'm not?

Killing plaintext git:// in favor of https:// cloning

[mailings]

On 22/02/16 20:50, Joe Anakata wrote:
>
> On 22/02/16 19:16, Jason A. Donenfeld wrote:
>
>>> Now that git.zx2c4.com runs over HTTPS, I'm considering getting rid of
>>> the plaintext git:// endpoint for cloning.
>
> Ferry Huberts Proclaimed Thus:
>
>> Yes, why?
>> What's the point?
>>
>> The repos are public, so cloning them over https bring nothing, except
>> extra overhead and server load.
>
> While pretty unlikely, in theory someone could MITM a git:// clone and
> send the user a hax0red branch of cgit with integrated botnet which
> the user then compiles and installs on their server.
>


That is a pretty unlikely and sophisticated attack vector, for 
admittedly little gain. Someone with an existing clone can immediately 
see that thing are off.

It is a vector though, so if you really want to defend against it, then 
just ignore my comments ;-)

> Not sure if the extra server load is worth it to defend against this
> case or not.  (Also, presumably the server is using the cgit smart http
> endpoint so https clone is not much additional DATA, just the ssl
> handshake; but definitely additional cpu for crypto operations.)
>
> Thanks
> -Joe
> _______________________________________________
> CGit mailing list
> CGit at lists.zx2c4.com
> http://lists.zx2c4.com/mailman/listinfo/cgit
>

-- 
Ferry Huberts

Killing plaintext git:// in favor of https:// cloning

[jea-signup-cgit]

"Eclipse Webmaster (Denis Roy)" Proclaimed Thus: 

>Everything is possible "in theory" ... But folks really need to stop 
>thinking that https is the impenetrable solution to everything.

HTTPS is definitely not the impenetrable solution to everything, but
there's no question it makes things *harder* for an attacker.

But as everyone else points out, this is a relatively unlikely attack;
there are almost certainly easier vectors of attack.  

(Also it was mentioned this would only work for people making a fresh
clone; anyone with an existing clone would almost certainly know
something was up.)

Something to keep in mind is that the https endpoint is already up, so
anyone who is actually concerned about this sort of attack can just
use https if they would like to, even if the git:// protocol stays open.

Also there is the issue of the book reference, which is hard to
change.  Though, for this, you could just have a dummy server which
redirects people, something which is essentially:

nc -l -p 9418 -c "echo -n 002AERR please use https://foo.bar/foo.git"

Cloning from that "git server" results in:

fatal: remote error: please use https://foo.bar/foo.git

(Of course, someone could still MITM *that*.  The returns from doing
so as an attacker are vanishingly small at that point.)

Thanks
-Joe

Killing plaintext git:// in favor of https:// cloning

[Jason]

On Mon, Feb 22, 2016 at 9:43 PM, Joe Anakata
<jea-signup-cgit at anakata.org> wrote:
> (Also it was mentioned this would only work for people making a fresh
> clone; anyone with an existing clone would almost certainly know
> something was up.)

No, definitely a MITM attack is feasible that would be fast
forwardable just fine for a pull onto an existing repo.

> Also there is the issue of the book reference, which is hard to
> change.  Though, for this, you could just have a dummy server which
> redirects people, something which is essentially:
>
> nc -l -p 9418 -c "echo -n 002AERR please use https://foo.bar/foo.git"

Right, this is exactly what I wound up doing, except much higher
performance using epoll:
https://git.zx2c4.com/git-daemon-dummy/about/
I haven't decided whether or not to deploy it, but the code is there.

> (Of course, someone could still MITM *that*.

Right. But the idea, anyhow, would just be to let the readers of the
book know what's up, rather than leaving them in the dark.