3 ms·

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

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...

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...