# Git on IPFS - Links and References

**URL:** <https://discuss.ipfs.tech/t/git-on-ipfs-links-and-references/730>\
**Category:** Ecosystem and Usage\
**Tags:** interoperability, use-cases-and-apps\
**Created:** [July 7, 2017, 1:29am UTC](https://discuss.ipfs.tech/t/git-on-ipfs-links-and-references/730 "2017-07-07T01:29:38Z")\
**Posts on this page:** 1\
**Showing post:** 24

<div class="post-metadata">

**Author:** ![Ericson2314](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/ericson2314/32/3846_2.png) [@Ericson2314](https://discuss.ipfs.tech/u/Ericson2314)\
**Post date:** [June 10, 2020, 4:22pm UTC](https://discuss.ipfs.tech/t/git-on-ipfs-links-and-references/730/24 "2020-06-10T16:22:05Z")

</div>

So perhaps the naive way isn’t so bad in relative terms? To elaborate on my reply in [Handle blob objects larger than MessageSizeMax · Issue #18 · ipfs/go-ipld-git · GitHub](https://github.com/ipfs/go-ipld-git/issues/18#issuecomment-641592971)

The attack is

> [@stebalien](#):
>
> ```auto
> hash := targetHash
> for {
> hash, chunk := solveForHashChunkPair(hash)
> send(hash, chunk)
> }
> 
> ```

But for any merkelized data, we have

```auto
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 [Merkle–Damgård construction - Wikipedia](https://en.wikipedia.org/wiki/Merkle%E2%80%93Damg%C3%A5rd_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.

---

_[View the full topic](https://discuss.ipfs.tech/t/git-on-ipfs-links-and-references/730)._