Re: [tor-dev] Git hosting changes, git:// support discontinued
On Mon, Dec 08, 2014 at 10:25:15AM -0500, Nick Mathewson wrote: > On Mon, Dec 8, 2014 at 8:57 AM, Jason Cooper 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: 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. signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Git hosting changes, git:// support discontinued
On Mon, Dec 8, 2014 at 8:57 AM, Jason Cooper 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 ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Git hosting changes, git:// support discontinued
On Mon, Dec 01, 2014 at 05:49:35AM +0100, Sebastian Hahn wrote: > Hi Jason, > > On 30 Nov 2014, at 23:32, Jason Cooper 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. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Git hosting changes, git:// support discontinued
On Mon, Dec 01, 2014 at 12:42:09AM +, Yawning Angel wrote:
> On Sun, 30 Nov 2014 19:19:58 -0500
> Jason Cooper wrote:
>
> > On Sun, Nov 30, 2014 at 11:55:31PM +, Yawning Angel wrote:
> > > On Sun, 30 Nov 2014 17:32:05 -0500
> > > Jason Cooper 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.
signature.asc
Description: Digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Git hosting changes, git:// support discontinued
Hi Jason, On 30 Nov 2014, at 23:32, Jason Cooper 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 signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Git hosting changes, git:// support discontinued
On Sun, 30 Nov 2014 19:19:58 -0500
Jason Cooper wrote:
> On Sun, Nov 30, 2014 at 11:55:31PM +, Yawning Angel wrote:
> > On Sun, 30 Nov 2014 17:32:05 -0500
> > Jason Cooper 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
pgpsUCIBbLyRC.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Git hosting changes, git:// support discontinued
On Sun, Nov 30, 2014 at 11:55:31PM +, Yawning Angel wrote: > On Sun, 30 Nov 2014 17:32:05 -0500 > Jason Cooper 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-object [2] https://www.kernel.org/pub/software/scm/git/docs/user-manual.html#trust signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Git hosting changes, git:// support discontinued
On Sun, 30 Nov 2014 17:32:05 -0500 Jason Cooper 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 pgpBtpnfUsqCQ.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Git hosting changes, git:// support discontinued
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. signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] 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 signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
