Git hosting changes, git:// support discontinued
Hi there, git users! Today, weasel changed our gitweb setup to use cgit from now on in the wake of a migration to wheezy. This move hopefully improves speed without taking away any needed functionality. At the same time, we've discontinued supporting clones via the git:// Protocol. It is unauthenticated and you probably shouldn't use it if at all possible. Access via https:// has been provided for years, and should continue to work without any hiccups. If there are questions or concerns, let's here them. Cheers Sebastian
On Sun, Nov 30, 2014 at 06:48:09PM +0100, Sebastian Hahn wrote:
Hi there, git users!
Hi Sebastian!
At the same time, we've discontinued supporting clones via the git:// Protocol.
:(
It is unauthenticated and you probably shouldn't use it if at all possible.
How does that matter? All of the tags are signed by Nick Mathewson. This allows the server *and* the path to be untrusted. Verifying the code with PGP tags isn't too hard: # initial clone $ gpg --recv-keys 8D29319A $ git clone git://git.torproject.org/git/tor $ cd tor $ git checkout tor-0.2.4.25 $ git tag -v tor-0.2.4.25 $ ...build... # subsequent updates $ git remote update origin # I prefer this to pull, ymmv $ git checkout tor-0.2.4.26 $ git tag -v tor-0.2.4.26 $ ...build...
Access via https:// has been provided for years, and should continue to work without any hiccups.
No issue there for folks that prefer the extra layer.
If there are questions or concerns, let's here them.
My problem with cancelling access via git:// is that the alternative (https) trains new users to think they need to trust the server. The fact is they don't. They need to trust the person identifying himself as Nick Mathewson who holds the private key for 8D29319A. I'd much prefer they be taught not to trust the path *or* the server. Please consider restoring git:// access. thx, Jason.
On Sun, 30 Nov 2014 17:32:05 -0500 Jason Cooper <tor@lakedaemon.net> wrote:
It is unauthenticated and you probably shouldn't use it if at all possible.
How does that matter? All of the tags are signed by Nick Mathewson. This allows the server *and* the path to be untrusted.
What about intermediary commits between tagged releases? Yes, signing each commit is possible, and probably even a good idea, but it's not currently done. Regards, -- Yawning Angel
On Sun, Nov 30, 2014 at 11:55:31PM +0000, Yawning Angel wrote:
On Sun, 30 Nov 2014 17:32:05 -0500 Jason Cooper <tor@lakedaemon.net> wrote:
It is unauthenticated and you probably shouldn't use it if at all possible.
How does that matter? All of the tags are signed by Nick Mathewson. This allows the server *and* the path to be untrusted.
What about intermediary commits between tagged releases? Yes, signing each commit is possible, and probably even a good idea, but it's not currently done.
git uses chained hashes so that verifying the integrity of the tagged commit also verifies the integrity of the previous commits between the prior tag and the current one (Actually, across the entire history, but once I've cloned and validated, I'm primarily concerned with commits from subsequent pulls). It seems the git user manual [0] has the clearest description. Each commit hash includes the hash of the parent(s) commit(s) [1], and the trust model is described a little further down, here [2]. thx, Jason. [0] https://www.kernel.org/pub/software/scm/git/docs/user-manual.html [1] https://www.kernel.org/pub/software/scm/git/docs/user-manual.html#commit-obj... [2] https://www.kernel.org/pub/software/scm/git/docs/user-manual.html#trust
On Sun, 30 Nov 2014 19:19:58 -0500 Jason Cooper <tor@lakedaemon.net> wrote:
On Sun, Nov 30, 2014 at 11:55:31PM +0000, Yawning Angel wrote:
On Sun, 30 Nov 2014 17:32:05 -0500 Jason Cooper <tor@lakedaemon.net> wrote:
It is unauthenticated and you probably shouldn't use it if at all possible.
How does that matter? All of the tags are signed by Nick Mathewson. This allows the server *and* the path to be untrusted.
What about intermediary commits between tagged releases? Yes, signing each commit is possible, and probably even a good idea, but it's not currently done.
git uses chained hashes so that verifying the integrity of the tagged commit also verifies the integrity of the previous commits between the prior tag and the current one (Actually, across the entire history, but once I've cloned and validated, I'm primarily concerned with commits from subsequent pulls).
So, I didn't communicate that well, so I'll try again: Assuming people use the unauthenticated git protocol, and want to clone a copy of master, maint-0.2.4 or maint-0.2.5, how do they ensure that the copy they received is correct? So "intermediary commits" as in "stuff that happens between releases, with the next release having not happened yet" ('interim' would have been a better word to use in hindsight). Sure you can validate up to the last tag, but for all the commits that follow, there's no magic PGP signed tag that covers those. I don't see any reason to allow a unauthenticated protocol when authenticated alternatives exist and are well supported in the first place, but that's just me. Regards, -- Yawning Angel
On Mon, Dec 01, 2014 at 12:42:09AM +0000, Yawning Angel wrote:
On Sun, 30 Nov 2014 19:19:58 -0500 Jason Cooper <tor@lakedaemon.net> wrote:
On Sun, Nov 30, 2014 at 11:55:31PM +0000, Yawning Angel wrote:
On Sun, 30 Nov 2014 17:32:05 -0500 Jason Cooper <tor@lakedaemon.net> wrote:
It is unauthenticated and you probably shouldn't use it if at all possible.
How does that matter? All of the tags are signed by Nick Mathewson. This allows the server *and* the path to be untrusted.
What about intermediary commits between tagged releases? Yes, signing each commit is possible, and probably even a good idea, but it's not currently done.
git uses chained hashes so that verifying the integrity of the tagged commit also verifies the integrity of the previous commits between the prior tag and the current one (Actually, across the entire history, but once I've cloned and validated, I'm primarily concerned with commits from subsequent pulls).
So, I didn't communicate that well, so I'll try again:
Assuming people use the unauthenticated git protocol, and want to clone a copy of master, maint-0.2.4 or maint-0.2.5, how do they ensure that the copy they received is correct?
Ok, so we need to define the scenario a bit more here. Who are the users, and what is there workflow? afaict, the users pulling the above branches are devs. Which means they aren't 'pull once, build, run, forget'. We can also restrict our scenario to live traffic injection. After all, if the bad commit is physically in the repo on the server, https isn't going to help.
So "intermediary commits" as in "stuff that happens between releases, with the next release having not happened yet" ('interim' would have been a better word to use in hindsight). Sure you can validate up to the last tag, but for all the commits that follow, there's no magic PGP signed tag that covers those.
Very good point and I did miss that from the last email. But this does mean we're speaking primarily about devs.
I don't see any reason to allow a unauthenticated protocol when authenticated alternatives exist and are well supported in the first place, but that's just me.
Looking at the above outlined scenario, if I were a tor dev, and someone injected a commit into master as I pulled it, that's eventually going to fail. Because the next time I pull, the attacker *has* to modify what I receive again so as to prevent git from barfing on the non-linear history. The attacker needs 100% success to avoid being caught. There is also the problem (for the attacker) that I push my branches to a public repo, and others pull/merge them... That's a helluva dance to dance. However, if the attacker can place the commit in the repo on the public server, that a much easier job and much more feasible (if the tree is considered the master tree). Because it's a single point of failure in the security posture of development workflow, I'd prefer to avoid placing any trust in the public git server. Saying "https only" run counter to that and inadvertently trains the users (hopefully not the devs) to place trust in the wrong entity. But again, this is all just my opinion, and I'm simply requesting that git:// access not be shut off. I'm a big boy, if the answer is "no", that's fine. I just wanted to make sure the point was addressed about trusting PGP tags vice public-facing git servers. thx, Jason.
Hi Jason, On 30 Nov 2014, at 23:32, Jason Cooper <tor@lakedaemon.net> wrote:
On Sun, Nov 30, 2014 at 06:48:09PM +0100, Sebastian Hahn wrote:
Access via https:// has been provided for years, and should continue to work without any hiccups.
No issue there for folks that prefer the extra layer.
My point is basically that there's no reason not to always use the extra layer.
If there are questions or concerns, let's here them. My problem with cancelling access via git:// is that the alternative (https) trains new users to think they need to trust the server. The fact is they don't. They need to trust the person identifying himself as Nick Mathewson who holds the private key for 8D29319A.
We don't just have tor.git up there, a lot of repos don't include a single signed commit or even tag. You're right that trusting the server is nothing a good dev should do, but I'm also not worried about our demographic here. On a tangent, referring to keys by their short (or long, for that matter) keyid is not a good idea. How to verify Nick actually has the blessing of the Tor project (or any subset of people therein, etc) to sign tags is yet another problematic area without a real solution. In conclusion: Yes, don't trust the server. I sleep a lot better pretending that people don't trust it.
I'd much prefer they be taught not to trust the path *or* the server.
Please consider restoring git:// access.
I have considered it, but my conclusion remains not to do it for now. Further discussion is invited. Thanks Sebastian
On Mon, Dec 01, 2014 at 05:49:35AM +0100, Sebastian Hahn wrote:
Hi Jason,
On 30 Nov 2014, at 23:32, Jason Cooper <tor@lakedaemon.net> wrote:
On Sun, Nov 30, 2014 at 06:48:09PM +0100, Sebastian Hahn wrote:
Access via https:// has been provided for years, and should continue to work without any hiccups.
No issue there for folks that prefer the extra layer.
My point is basically that there's no reason not to always use the extra layer.
Agreed.
If there are questions or concerns, let's here them. My problem with cancelling access via git:// is that the alternative (https) trains new users to think they need to trust the server. The fact is they don't. They need to trust the person identifying himself as Nick Mathewson who holds the private key for 8D29319A.
We don't just have tor.git up there, a lot of repos don't include a single signed commit or even tag.
Yes, this is sad. And something I'm slowly working on.
You're right that trusting the server is nothing a good dev should do, but I'm also not worried about our demographic here.
Yes, and this is something that came to mind as I thought about it more. *I* like to pull git trees and build from scratch. But apparently that's not the norm any more (am I dating myself? :-P) I gave up on attending the local Unix/Linux group because they asked a room of ~35 "Linux fans" who had ever built their own kernel. Not a single hand... So, yeah, we probably aren't training end users by requiring https://, because end users, sadly, are leet when they know how to do 'apt-get install ...' vice the Software Center.
On a tangent, referring to keys by their short (or long, for that matter) keyid is not a good idea. How to verify Nick actually has the blessing of the Tor project (or any subset of people therein, etc) to sign tags is yet another problematic area without a real solution.
Yes, using the 32bit identifier certainly is prone to collisions, but we also aren't attempting to validate that key in this thread. At the 2013 Kernel Summit, Linus advised using 12 characters for abbreviated commit hashes over the current norm of 7. Same problem, different aspect. $ git config --add core.abbrev 12 #if you were curious I know some folks like to use google hangouts to validate keys. Not that google is secure in any way, but the level of difficulty to intercept and modify an interactive audio/video stream makes it almost as good as face to face. Any live, interactive stream will do, if it's user-to-user encrypted, that's even better. The one problem PGP keys *don't* have is the centralized authority infrastructure. Honestly, I much prefer the difficulty of validating PGP keys over the lack of control and forced trust you get with the CA system.
In conclusion: Yes, don't trust the server. I sleep a lot better pretending that people don't trust it.
Agreed.
I'd much prefer they be taught not to trust the path *or* the server.
Please consider restoring git:// access.
I have considered it, but my conclusion remains not to do it for now. Further discussion is invited.
No problem. Thanks for hashing it over with me. thx, Jason.
On Mon, Dec 8, 2014 at 8:57 AM, Jason Cooper <tor@lakedaemon.net> wrote: [...]
On a tangent, referring to keys by their short (or long, for that matter) keyid is not a good idea. How to verify Nick actually has the blessing of the Tor project (or any subset of people therein, etc) to sign tags is yet another problematic area without a real solution.
Yes, using the 32bit identifier certainly is prone to collisions, but we also aren't attempting to validate that key in this thread. At the 2013 Kernel Summit, Linus advised using 12 characters for abbreviated commit hashes over the current norm of 7. Same problem, different aspect.
Yeah; and it's not like generating collisions or second preimages on a 48-bit identifier is out-of-reach for a bored undergraduate. Using a 12-char abbreviated ID this long will prevent more accidental collisions, but for resisting deliberate collisions, I won't really be happy until git migrates away from SHA1 entirely. -- Nick
On Mon, Dec 08, 2014 at 10:25:15AM -0500, Nick Mathewson wrote:
On Mon, Dec 8, 2014 at 8:57 AM, Jason Cooper <tor@lakedaemon.net> wrote: [...]
On a tangent, referring to keys by their short (or long, for that matter) keyid is not a good idea. How to verify Nick actually has the blessing of the Tor project (or any subset of people therein, etc) to sign tags is yet another problematic area without a real solution.
Yes, using the 32bit identifier certainly is prone to collisions, but we also aren't attempting to validate that key in this thread. At the 2013 Kernel Summit, Linus advised using 12 characters for abbreviated commit hashes over the current norm of 7. Same problem, different aspect.
Yeah; and it's not like generating collisions or second preimages on a 48-bit identifier is out-of-reach for a bored undergraduate. Using a 12-char abbreviated ID this long will prevent more accidental collisions,
For the most part, when a commit is referenced, it's not just the 12 character abbreviation, it's also the Subject line. See the 'Fixes: ...' tag used when flagging commits for the stable tree. This adds a little more robustness against accidental collisions, but as you say...
but for resisting deliberate collisions, I won't really be happy until git migrates away from SHA1 entirely.
Funny you should mention that. :) There's two aspects to that problem. The first, and easy one, is migrating the code away from sha1. Hopefully to something flexible, so new repos could specify core.hash=skein1024 or some other hash that floats the author's boat. The second problem is that of existing repos. My current thought is an enhanced signed tag that contains the following per commit: <full sha1 commit hash> <full XXX hash> <commit subject> Where XXX is the secondary hash of your choice. The hash would be computed exactly the same way as a 'native' repo commit hash using that hash function. This way, an attacker who can generate a sha1 collision to modify an existing commit would now have to generate a collision for a completely different hash function as well. This only protects people who check PGP signed tags, of course. I think it would be a good interim step to set up something like an Observatory that keeps tabs on the core projects (Linux, bash, libc, openssl, etc). It wouldn't even need author participation at first, as long as the observatory counter-signed the tag shortly after the author did. Then we could be reasonably confident that there wasn't time to generate a collision on a commit for which we hadn't signed yet. thx, Jason.
participants (4)
-
Jason Cooper -
Nick Mathewson -
Sebastian Hahn -
Yawning Angel