6 ms·

While Git is designed in some way for peer-to-peer interactions, there is no deployment of it that works that way. All deployments use the client-server model b

While Git is designed in some way for peer-to-peer interactions, there is no deployment of it that works that way. All deployments use the client-server model because Git lacks functionality to be deployed as-is in a peer-to-peer network. For one, it has no way of verifying that the repository you downloaded after a `git clone` is the one you asked for, which means you need to clone from a trusted source (ie. a known server). This isn't compatible with p2p in any useful way. Radicle solves this by assigning stable identities[0] to repositories that can be verified locally, allowing repositories to be served by untrusted parties. [0]: https://docs.radicle.xyz/guides/protocol#trust-through-self-certification https://docs.radicle.xyz/guides/protocol#trust-through-self-...

ianopolous 3y ago
How do you handle the SHA1 breaks in an untrusted p2p setting?
- cloudhead 3y ago
  If you mean collision attacks, this shouldn't be a problem with Git, since it uses Hardened SHA-1. Eventually, when Git fully migrates to SHA-2, we will offer that option as well. > Is Hardened SHA-1 vulnerable? > No, SHA-1 hardened with counter-cryptanalysis (see ‘how do I detect the attack’) will detect cryptanalytic collision attacks. In that case it adjusts the SHA-1 computation to result in a safe hash. This means that it will compute the regular SHA-1 hash for files without a collision attack, but produce a special hash for files with a collision attack, where both files will have a different unpredictable hash. From https://shattered.io/ https://shattered.io/
  - ianopolous 3y ago
    So you use hardened sha1 in radicle? It would be great to see this in the docs.
    - cloudhead 3y ago
      Everything that is replicated on the network is stored as a Git object, using the libgit2[0] library. This library uses hardened SHA-1 internally, which is called sha1dc (for "detect collision"). Will add to the docs, good idea! [0]: https://github.com/libgit2/libgit2/blob/ac0f2245510f6c75db1b1e7af7ca01c15dec26bc/src/util/hash/sha1dc/sha1.c#L1745-L1756 https://github.com/libgit2/libgit2/blob/ac0f2245510f6c75db1b...
mariusor 3y ago
> it has no way of verifying that the repository you downloaded after a `git clone` is the one you asked for Respectfully disagree here. A repository is a(or multiple) chain(s) of commits, if each commit is signed, you know exactly that the clone you got is the one you asked for. You're right that nobody exposes a UI around this feature, but the capability is there if anyone would have any workflows that require to pull from random repositories instead of well established/known ones.
- cloudhead 3y ago
  Here's the problem: how do you know that the commit signers are the current maintainers of the repo?
  - mambru 3y ago
    Does that matter if the signatures are valid?
    - cloudhead 3y ago
      Yeah, because for eg. I can publish the given repository from my server with an additional signed commit (signed by me) on top of the original history, and that commit could include a backdoor. You have no way of knowing whether this additional commit is "authorized" by the project leads/owners or not.
      - xyzzy_plugh 3y ago
        That is in fact the point, it's decentralized by nature. The entire idea behind git's decentralization is that your version with an additional backdoor is no lesser of a version than any other. You handle that at the pointer or address level i.e. deciding to trust your server.
  - pastage 3y ago
    That problem is social you can never be sure of that even with hardware signing of commits. No tech can ever solve that. Just get "pull requests" from contributors you know and pull from maintainers you trust. Is the social model.
hanniabu 3y ago
The problem I'd like to see solved is source of truth. It'd be nice if there were a way to sign a repo with an ENS or domain withiut knowing the hash. Another thing is knowing if the commit history has been tampered with without knowing the hash. The reason for needing to not know the hash is for cases like tornado cash. The site and repo was taken down. There's a bunch of people sharing a codebase with differing hashes, you have no idea which is real or altered. This is also important for cases where the domain is hacked.
- vinnyhaps 3y ago
  > The reason for needing to not know the hash is for cases like tornado cash. The site and repo was taken down. There's a bunch of people sharing a codebase with differing hashes, you have no idea which is real or altered. > This is also important for cases where the domain is hacked. I think at some point you need to know some sort of root-of-trust to kick off the trusting process. I believe in this case, you would trust a certain DID or set of DIDs (i.e. a Tornado Cash developer's public key). You can clone their version of the project and the history of the project MUST be signed by their private key for it to be legitimate. To clarify, in Radicle, a peer's set of references are always signed by their key and this data is advertised so that you can always verify, using their public key, that this data is indeed what this peer has/had in their Git history. If this ever diverges then any fetching from that peer is rejected.
  - hanniabu 3y ago
    Right now the devs are in jail so you wouldn't be able to seed from them (computers off) so you'd need to trust another reference
- matheusmoreira 3y ago
  This is just another form of the cryptographic key distribution problem. Doesn't matter where the git repository comes from, you can be sure it hasn't been tampered with if the signatures are valid. Domains with DNSSEC are an interesting solution. PGP public keys are distributable via DNS records. https://www.pgp.guide/pgp_dns/ https://www.pgp.guide/pgp_dns/ https://weberblog.net/pgp-key-distribution-via-dnssec-openpgpkey/ https://weberblog.net/pgp-key-distribution-via-dnssec-openpg...
adastra22 3y ago
The entire Linux kernel development team wouldn’t to differ…

ianopolous 3y ago

How do you handle the SHA1 breaks in an untrusted p2p setting?

cloudhead 3y ago
If you mean collision attacks, this shouldn't be a problem with Git, since it uses Hardened SHA-1. Eventually, when Git fully migrates to SHA-2, we will offer that option as well. > Is Hardened SHA-1 vulnerable? > No, SHA-1 hardened with counter-cryptanalysis (see ‘how do I detect the attack’) will detect cryptanalytic collision attacks. In that case it adjusts the SHA-1 computation to result in a safe hash. This means that it will compute the regular SHA-1 hash for files without a collision attack, but produce a special hash for files with a collision attack, where both files will have a different unpredictable hash. From https://shattered.io/ https://shattered.io/
- ianopolous 3y ago
  So you use hardened sha1 in radicle? It would be great to see this in the docs.
  - cloudhead 3y ago
    Everything that is replicated on the network is stored as a Git object, using the libgit2[0] library. This library uses hardened SHA-1 internally, which is called sha1dc (for "detect collision"). Will add to the docs, good idea! [0]: https://github.com/libgit2/libgit2/blob/ac0f2245510f6c75db1b1e7af7ca01c15dec26bc/src/util/hash/sha1dc/sha1.c#L1745-L1756 https://github.com/libgit2/libgit2/blob/ac0f2245510f6c75db1b...

mariusor 3y ago

> it has no way of verifying that the repository you downloaded after a `git clone` is the one you asked for Respectfully disagree here. A repository is a(or multiple) chain(s) of commits, if each commit is signed, you know exactly that the clone you got is the one you asked for. You're right that nobody exposes a UI around this feature, but the capability is there if anyone would have any workflows that require to pull from random repositories instead of well established/known ones.

cloudhead 3y ago
Here's the problem: how do you know that the commit signers are the current maintainers of the repo?
- mambru 3y ago
  Does that matter if the signatures are valid?
  - cloudhead 3y ago
    Yeah, because for eg. I can publish the given repository from my server with an additional signed commit (signed by me) on top of the original history, and that commit could include a backdoor. You have no way of knowing whether this additional commit is "authorized" by the project leads/owners or not.
    - xyzzy_plugh 3y ago
      That is in fact the point, it's decentralized by nature. The entire idea behind git's decentralization is that your version with an additional backdoor is no lesser of a version than any other. You handle that at the pointer or address level i.e. deciding to trust your server.
- pastage 3y ago
  That problem is social you can never be sure of that even with hardware signing of commits. No tech can ever solve that. Just get "pull requests" from contributors you know and pull from maintainers you trust. Is the social model.

hanniabu 3y ago

The problem I'd like to see solved is source of truth. It'd be nice if there were a way to sign a repo with an ENS or domain withiut knowing the hash. Another thing is knowing if the commit history has been tampered with without knowing the hash. The reason for needing to not know the hash is for cases like tornado cash. The site and repo was taken down. There's a bunch of people sharing a codebase with differing hashes, you have no idea which is real or altered. This is also important for cases where the domain is hacked.

vinnyhaps 3y ago
> The reason for needing to not know the hash is for cases like tornado cash. The site and repo was taken down. There's a bunch of people sharing a codebase with differing hashes, you have no idea which is real or altered. > This is also important for cases where the domain is hacked. I think at some point you need to know some sort of root-of-trust to kick off the trusting process. I believe in this case, you would trust a certain DID or set of DIDs (i.e. a Tornado Cash developer's public key). You can clone their version of the project and the history of the project MUST be signed by their private key for it to be legitimate. To clarify, in Radicle, a peer's set of references are always signed by their key and this data is advertised so that you can always verify, using their public key, that this data is indeed what this peer has/had in their Git history. If this ever diverges then any fetching from that peer is rejected.
- hanniabu 3y ago
  Right now the devs are in jail so you wouldn't be able to seed from them (computers off) so you'd need to trust another reference
matheusmoreira 3y ago
This is just another form of the cryptographic key distribution problem. Doesn't matter where the git repository comes from, you can be sure it hasn't been tampered with if the signatures are valid. Domains with DNSSEC are an interesting solution. PGP public keys are distributable via DNS records. https://www.pgp.guide/pgp_dns/ https://www.pgp.guide/pgp_dns/ https://weberblog.net/pgp-key-distribution-via-dnssec-openpgpkey/ https://weberblog.net/pgp-key-distribution-via-dnssec-openpg...

adastra22 3y ago

The entire Linux kernel development team wouldn’t to differ…