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@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx> 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.
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev