[tor-dev] Git hosting changes, git:// support discontinued

[Jason Cooper]

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 at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20141208/1386948b/attachment.sig>