Git on IPFS - Links and References

@cogwire Very much! I would send you a message but apparently new users can’t do that… We are just getting started on something called Git DAC. Found this thread while looking at the best way to store git repos on IPFS. If you can message me, go for it. Otherwise find me on twitter, or let me know how you would prefer to connect! We might even start offering some bounties to help bootstrap the initial phases of the project, so if you or anyone you know is handy with IPFS and other decentralized architectures please point them my way!

Another tool for publishing Git repositories to IPFS with webhooks similar to “github-ipfs” but with wider feature-set: https://github.com/AuHau/ipfs-publish

I just announced a new remote that indirects all the objects to per type folders.

As well as avoiding the sharding problem, the file contents are readable and the root of the repo are actually the contents of the pushed branch.

So perhaps the naive way isn’t so bad in relative terms? To elaborate on my reply in https://github.com/ipfs/go-ipld-git/issues/18#issuecomment-641592971

The attack is

But for any merkelized data, we have

hash := targetHash
for {
    chunkWithHash := solveForChunk(hash)
    send(chunkWithHash)
    hash := extractSha1Cid(chunkWithHash)
}

i.e. the fraudulent chunk can utilize “plausible CIDs” which keep the attack alive for future rounds.

Also, thanks to https://en.wikipedia.org/wiki/Merkle–Damgård_construction, SHA-1 will put the length in padding at the end, so attack up front still needs to commit to a length. This means no attack can waste resources indefinitely. Furthermore, Users are free to set policies specifying some function of the largest blob they’ll try to receive given the degree they trust the peer, to further mitigate spam.

Now it could well be that solveForChunk is substantially harder than solveForHashChunkPair, but given that SHA-1 is kinda “hosed anyways”, I’d consider cautiously banning for most CIDs, but making an exception for git-raw + sha1 given it’s ubiquity.

Ultimately, I think it’s in IPFS’s best interest to lobby hard for git + sha256 to chunk blobs, but IPFS will have more clout if there’s a stop-gap solution for git + sha1 to attract git users.