Feedback

[cjb]

Feedback

[cjb]

Hi, thanks for the comments.

Can we know for sure that what we ask for is what we are going to get

We ask for a git hash, receive some objects, apply them, and see if we ended up at the git hash we asked for. If not, we got the wrong objects and should try again with someone else.

We already have a distributed naming system, why not use it?

You're welcome to. The blockchain links a single global username to a public key hash. You can link anything you want to that hash. It's optional. I did it because github.com has a single global username so this should too. I'll accept PRs to support doing DNS lookups or whatever as well.

[essen]

Trying to give feedback on the design, since I can't contribute to the implementation.

If not, we got the wrong objects and should try again with someone else.

So this doesn't provide security then.

The nice thing about a central authority is that you can be reasonably certain that you download the right thing. As things stand I would have more confidence in git{hub,lab,orious,others} than in this current solution.

I'm not sure what a PR adding support for DNS as well as blockchain I am not sure how that would work. You kind of have to use one or the other, you can't really make the distinction based on the name. I believe the DNS is more appropriate as we know how it works, it is cacheable, etc. which is why I suggested it.

[cjb]

It sounds like your feedback is "this is a peer-to-peer network, and I don't like peer-to-peer networks". That's not a very useful design criticism.

In a peer-to-peer network, anyone could lie to you. The important thing is being able to detect when they're lying before any damage has been caused, which this design does.

I am not sure how that would work

For example, we could just make git clone gittorrent://domain.name/repo check for a DNS entry that specifies a gittorrent mutable key hash.

[Licenser]

I am not 100% familiar with the hashing mechanism in git, but I'd suspect them to be designed to provide security against accidental miss-interpretation of files and are not designed to prevent malicious attempts to fake identity.

I think the concern essen is raising is that having one does not necessarily imply having the other. Source code also has other requirements (and possibilities) on that then say, text documents.

I've read a very interesting article (I can't find right now) about doing exactly that, having crafting source files with the same hash (I think the method in question was md5 but I am not 100% sure) but the second one modified to give other results. (I'll add the link if I can dig it up)

[cjb]

I am not 100% familiar with the hashing mechanism in git, but I'd suspect them to be designed to provide security against accidental miss-interpretation of files and are not designed to prevent malicious attempts to fake identity.

You are incorrect; Git intentionally uses cryptographically-secure hashes, not mere checksums.

[Licenser]

Doing a quick research git uses a SHA1 hash, the approach I've seen a few times for hashing against file modification is to use more then one hashing algorithm so attacks that generate 'content' in order re-validate the same hash are a lot harder.

Something that deals with the same issue that comes to mind is pkgsrc (the package repository/build system) they combine sha1, md5 and the file size as a protection against modification.

The problem does not apply so much when the content follows a strict format and adding padded data would destroy it, however for most source code that is not the case.

offtopic: I don't think this deserves its own issue so I'm lumping it in here, but is there a channel for this project on any irc network? I checked #gittorrent in freenode after seeing this on reddit yesterday but it was empty. IRC would be good both for collaborators to discuss the project and for non-contributors to idle and see what's happening

[Licenser]

here is the original article I was mentioning: http://natmchugh.blogspot.de/2014/10/how-i-made-two-php-files-with-same-md5.html

it uses a collision attack on md5, but people are starting to warn against the same attacks becoming to be possible on sha1

[essen]

My feedback is I like p2p networks. That's how I started my first post. But if you want your solution to be usable in the long term, you have to provide better guarantees than you have today.

Git uses hashes because it's unlikely that two hashes will ever be the same. Not because it's guaranteed. It's not. SHA1 is already vulnerable if you have a lot of money, and if not, just wait 10 years.

I really would like to make my projects available in a distributed fashion, that's why I like what you have done so far, but I can't use it until I am sure my users are protected at least as well as they are today.

Not being able to know that what you get is what you actually wanted would make many types of usage very dangerous, like when having some kind of build system that fetches repositories regularly.

So again, great job so far, I like it. Now if it's meant to be nothing more than a prototype, it's perfectly fine as it is. But if you intend to make it a solution that can stand the test of time, there's a lot more work to be done, and I hope my small advice helps.

Cheers.

[cjb]

SHA1 is already vulnerable if you have a lot of money, and if not, just wait 10 years.

The type of collision you would need in order to share a hash and then have someone else deliver malware that matches that hash is called a second preimage attack. No-one has ever found one for SHA1. So it's nonsense to say that SHA1 is vulnerable to it today if you have money. It is absolutely beyond the known state of the art as an attack.

I too would be unsurprised if things look different in ten years. But presumably Git and BitTorrent would change to something else, perhaps SHA2, perhaps not, and so would this project. I don't think it's the role of this project to pick a different hash algorithm for the Git developers. They can make that decision themselves.

Git also supports gpg-signed tags! If you worry about this, you could sign your releases. The chance of someone finding a second preimage attack against SHA1 that also functions as a good PGP signature is even lower than the currently ~0 chance of someone finding a second preimage attack against SHA1.

[cjb]

@miotatsu Hi! I'm in Freenode #gittorrent now.

[essen]

OK it looks like my main worry is not justified, good point. There's still a possibility of someone masquerading another project and sending garbage to everyone who tries to fetch it, possibly in an attempt to ddos that project.

I'm not saying another hash should be used. I'm saying you can't use just this hash to ensure that what you get is correct. When using github or equivalent you have the hash check and the authority check (through SSL certificates) so you can be fairly confident that what you get is what you asked for. Your solution bypasses the central authority and so this check is not performed anymore. It would be good to have an equivalent. This would probably get rid of any concerns anyone might have.

I'm not sure how signing tags help people who fetch specific commits, or always stay at the head of the branch (the project developers for example). Not sure what the details around signing are though.

[cjb]

I agree that using a multihash scheme in the medium-term would be better. But I don't see a straightforward way to fit one into this design, until e.g. BitTorrent itself supports longer hash algorithms. Still, I think it's important to note that this doesn't seem like a real problem today; hopefully Git and BitTorrent will take notice and offer alternatives before it becomes one.