Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Introducing Git protocol version 2

opensource.googleblog.com

Post reply on HN
Print view View original

131–140 of 167 posts

Re: Introducing Git protocol version 2

#131

Post by hedora »

netheril96 wrote: post #123
trumped wrote: post #64

Earlier quoted context omitted.

Does he do it as a Google employee or on his own time? If he does it on his own time, why does it matter that he works at Google? and If he does it as a Google employee, when are the ads coming? edit: 3 replies, 5 down-votes and no answer to the main question...

I guess others downvote you because your insinuation about how Google will sneak ads into an open source project. They've never done that before, so it is rather odd accusation.

They moved a bunch of open source functionality out of AOSP to force all-or-nothing adoption of their services + tracking.

Re: Introducing Git protocol version 2

#132

Post by eridius »

Someone1234 wrote: post #127
eridius wrote: post #125

Earlier quoted context omitted.

Requiring Git-LFS support would be rather problematic for anyone who self-hosts git repos over SSH.

They'd just stick to Protocol 1

Why should people who self-host repos not be able to benefit from the improvements in protocol 2? Especially if other future extensions to protocol 2 prove useful for self-hosters?

Git is a decentralized version control system. Its core networking protocol must remain useful for people who self-host.

Re: Introducing Git protocol version 2

#133

Post by rspeer »

icebraining wrote: post #39
Someone1234 wrote: post #22

Too bad they didn't make Git LFS part of Version 2[0]. Most vendors[2] support LFS already but because it isn't required, some still lack it and its support cannot be assumed. [0] https://git-lfs.github.com/ [1] https://github.com/git-lfs/git-lfs/wiki/Implementations

I say that's LFS' fault. Why do you even need a custom server? It should just be able to use any ol' file server or S3-API compatible service, and do everything on the client side. I find git-annex a much better solution, it's a shame everyone went with LFS.

My experience with git-annex is that it seems heavily designed for individuals and not for projects. The places it looks for files are often just a computer you were once developing on, and it sometimes expects you to go find that computer. It never forgets about any crazy place your files have been.

It was very hard to use in asymmetric cases where different people have different credentials, such as where one person has access to a computer and others don't, or where a couple of core developers have authenticated R/W access to a file server or an S3 bucket and everyone else just has HTTP.

Re: Introducing Git protocol version 2

#134

Post by Too »

simias wrote: post #28

Let that be a reminder to all the coders out there: if you ever design a protocol or file format to communicate between machines always remember to add a version field or some other way to allow for updates and revisions later without breaking everything. Having a way to specify extensions in a backward-compatible way is nice too.

I'm mostly surprised they solved a critical server bug on the client side and by introducing even more hacks into the protocol. I mean, who in their right mind would run a public git server with this super easy to exploit DOS bug:

    Unfortunately due to a bug introduced in 2006 we aren't
    able to place any extra arguments (separated by NULs) other
    than the host because otherwise the parsing of those
     arguments would enter an infinite loop.
I'm not sure if entering an infinite loop means what i think it does in this context but that's almost CVE worthy and they should release a fix and mark that version as obsolete as ever and never have to make their clients cater to it any more.

Re: Introducing Git protocol version 2

#135

Post by [deleted] »

seabrookmx wrote: post #4
ksec wrote: post #3

I thought google uses hg, have they switched over to git as well?

For all the "big" Google projects they use a proprietary system called piper. I think all their open-source stuff (Angular, GoLang, Android) uses git (and sometimes Gerrit). Although given Google's scale, I'm sure there's some teams/projects that use Mercurial.

[deleted]

Re: Introducing Git protocol version 2

#136

Post by pritambaral »

paxy wrote: post #128
pritambaral wrote: post #99

Earlier quoted context omitted.

The GPL is a license, not a Contributor Agreement or a Copyright Transfer. The author remains the owner of the copyright when they let others use it under a license, even open source licenses like the GPL. Licensing a software out does not mean the author can no longer "claim any ownership". In the case of OSS licenses, it just means that they can't claim sole ownership.

Yes, but from the perspective of the end user (me), the license guarantees that I can use the current version of the software for free forever without Google or anyone else forcing any changes. Plus, if I don't like any changes they make, I can fork my own copy and continue developing on that (which the community will certainly do in a heartbeat if needed).

Yes, of course. I was just trying to clarify that that guarantee is due to the software being licensed to you and not because ownership gets transferred from the author.

Re: Introducing Git protocol version 2

#137

Post by Dragonai »

vga805 wrote: post #63
chrisseldo wrote: post #25

Earlier quoted context omitted.

>"Linus Torvalds said in 2012 that one of his own biggest successes was recognizing how good a developer Hamano was on Git, and trusting him to maintain it."

wow! what an accolade

Seconded. I can only imagine how good Junio must be to have earned that kind of praise and trust.

Re: Introducing Git protocol version 2

#138

Post by kumarharsh »

chrisseldo wrote: post #25
oneeyedpigeon wrote: post #15

The current (and pretty much only, ever, despite Linus having been the creator) maintainer of git is a google employee [1], in case anyone else was wondering. [1] https://en.m.wikipedia.org/wiki/Junio_Hamano

>"Linus Torvalds said in 2012 that one of his own biggest successes was recognizing how good a developer Hamano was on Git, and trusting him to maintain it."

I came across this email from Linus announcing the handover: https://lwn.net/Articles/145123/

It's interesting how the first ever git project itself was looking for new maintainer almost as soon as it was created.

Re: Introducing Git protocol version 2

#139

Post by falsedan »

harveynick wrote: post #119
falsedan wrote: post #96

Earlier quoted context omitted.

Then don't waste peoples time with vacuous comments.

Ironic reply. Sincere apologies if you can't derive any information from my comment, but that doesn't mean there isn't any there.

The only information is “google employs me”.

Re: Introducing Git protocol version 2

#140

Post by tialaramex »

EvilTerran wrote: post #100
stingraycharles wrote: post #50

Earlier quoted context omitted.

But why is this not supported by TLS? Is it set up in such a way that it could never be amended to have a fallback?

If the newest version of a secure communication protocol includes some way to negotiate down to an older version, that opens the door to downgrade attacks - you risk ending up with a protocol that, in practice, has all the vulnerabilities of both versions.

You can work around this by having downgrade protection, and TLS 1.3 has this out of the box, it was also added belatedly to TLS 1.2 (but obviously the problem there is, you can still downgrade whenever either client or server knows TLS 1.2 but doesn't have protection yet)

In TLS 1.3 the downgrade protection works like this:

If I'm a TLS 1.3 server, and a connection arrives that says it can only handle TLS 1.2 or lower, I scribble the letters "DOWNGRD" (in ASCII) near the end of a field labelled Random that is normally entirely full of random bytes.

If I'm a TLS 1.3 client, I try to ask for TLS 1.3 from the server when I connect, if instead I get a TLS 1.2 or earlier reply, I check the Random field, and see if it spells out "DOWNGRD" near the end. If it does, somebody is trying to downgrade my connection, I am being attacked and can't continue.

This trick works because if bad guys tamper with the Random field then the connection mysteriously fails (client and server are relying on both knowing all these bytes to choose their encryption keys with ephemeral mode) while older clients won't see any meaning in the letters DOWNGRD near the end of these random bytes - so they won't freak out.

You might worry: What if somebody just randomly picked "DOWNGRD" by accident for a TLS 1.3 connection ? If every single person in the world makes one connection per second, this is likely to happen to one person, somewhere, only once every few years. So we don't worry about this.

Post reply on HN