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.