6 ms·

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

> 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.
  - cloudhead 3y ago
    That's not quite right, we solved this in Radicle. Each change in ownership (adding/removing maintainers) is signed by the previous set of owners. You can therefore trace the changes in ownership starting from the original set, which is bound to the Repository ID.
    - e12e 3y ago
      How do you fork an abandoned repo?
      - cloudhead 3y ago
        When you fork an abandoned repo, you are essentially giving it a new repository identity, which is a new root of trust, with a new maintainer set. You'll then have to communicate the new repository identifier and explain that this is a fork of the old repo.
    - mariusor 3y ago
      Sure, but again, you've added convenience - or what you feel like it's convenience - for something that probably can be achieved right now with open source tools. A "CONTRIBUTORS" file with sign-offs by maintainers is an example of a solution for the same thing. I don't deny that your improvements can benefit certain teams/developers but I feel like there are very few people that would actually care about them and they're not making use of alternatives.
      - cloudhead 3y ago
        A CONTRIBUTORS file is easy to change by anyone hosting the repository - it's useless for the purpose of verification, unless you have a toolchain to verify each change to said file. "Sign-offs by maintainers" it not useful either unless you already know who the maintainers are, and you are kept up to date (by a trusted source) when the maintainers change. This is what Radicle does, for free, when you clone a repo.
- mariusor 3y ago
  By the same way I know how the commit signers are who they say they are in "regular" usage of GPG: I have verified the key belongs to them, or their keys are signed by people I trust to have verified, etc, etc. Like a sibling said, the problem is social rather than technical.
- matheusmoreira 3y ago
  By joining the web of trust. Meeting people, verifying each other's identities and getting keys signed. Debian seems to be quite good at this. https://wiki.debian.org/Keysigning https://wiki.debian.org/Keysigning https://wiki.debian.org/Keysigning/Coordination https://wiki.debian.org/Keysigning/Coordination https://wiki.debian.org/Keysigning/Offers https://wiki.debian.org/Keysigning/Offers
DinaCoder99 3y ago
Perhaps, but none of that commit history is related to the invocation to git clone. To acquire and verify you need both a url and a hash for each branch head you want to verify

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.
- cloudhead 3y ago
  That's not quite right, we solved this in Radicle. Each change in ownership (adding/removing maintainers) is signed by the previous set of owners. You can therefore trace the changes in ownership starting from the original set, which is bound to the Repository ID.
  - e12e 3y ago
    How do you fork an abandoned repo?
    - cloudhead 3y ago
      When you fork an abandoned repo, you are essentially giving it a new repository identity, which is a new root of trust, with a new maintainer set. You'll then have to communicate the new repository identifier and explain that this is a fork of the old repo.
  - mariusor 3y ago
    Sure, but again, you've added convenience - or what you feel like it's convenience - for something that probably can be achieved right now with open source tools. A "CONTRIBUTORS" file with sign-offs by maintainers is an example of a solution for the same thing. I don't deny that your improvements can benefit certain teams/developers but I feel like there are very few people that would actually care about them and they're not making use of alternatives.
    - cloudhead 3y ago
      A CONTRIBUTORS file is easy to change by anyone hosting the repository - it's useless for the purpose of verification, unless you have a toolchain to verify each change to said file. "Sign-offs by maintainers" it not useful either unless you already know who the maintainers are, and you are kept up to date (by a trusted source) when the maintainers change. This is what Radicle does, for free, when you clone a repo.
mariusor 3y ago
By the same way I know how the commit signers are who they say they are in "regular" usage of GPG: I have verified the key belongs to them, or their keys are signed by people I trust to have verified, etc, etc. Like a sibling said, the problem is social rather than technical.
matheusmoreira 3y ago
By joining the web of trust. Meeting people, verifying each other's identities and getting keys signed. Debian seems to be quite good at this. https://wiki.debian.org/Keysigning https://wiki.debian.org/Keysigning https://wiki.debian.org/Keysigning/Coordination https://wiki.debian.org/Keysigning/Coordination https://wiki.debian.org/Keysigning/Offers https://wiki.debian.org/Keysigning/Offers

DinaCoder99 3y ago

Perhaps, but none of that commit history is related to the invocation to git clone. To acquire and verify you need both a url and a hash for each branch head you want to verify