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

[Jason A. Donenfeld]

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.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

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

[Daniel Reichelt]

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
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

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

[Jason A. Donenfeld]

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
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

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

[Jason A. Donenfeld]

On Tue, Feb 23, 2016 at 2:53 PM, Brian Minton  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.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

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

[Eric Wong]

"Jason A. Donenfeld"  wrote:
> On Tue, Feb 23, 2016 at 2:19 AM, Eric Wong  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.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

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

[Jason A. Donenfeld]

On Mon, Feb 22, 2016 at 9:43 PM, Joe Anakata
 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.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

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

[Ferry Huberts]

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@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit



--
Ferry Huberts
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

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

[Jason A. Donenfeld]

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

So that the contents of the repository cannot be modified in transit.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

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

[Ferry Huberts]

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@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit



--
Ferry Huberts
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

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

[Jason A. Donenfeld]

Well, uh oh speghettio!

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

https://books.google.fr/books?id=kJsQAwAAQBAJ=PA314=PA314=git://git.zx2c4.com=bl=W6M9TlYzCY=g-PY0glN2ddWygtFDLiHgbiC69I=en=X_esc=y#v=onepage=git%3A%2F%2Fgit.zx2c4.com=false

Perhaps there's a way to write a dummy daemon that prints a message...
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit

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

[Jason A. Donenfeld]

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
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit