5 ms·

Here's the problem: how do you know that the commit signers are the current maintainers of the repo?

by cloudhead 3y ago

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
        All good points, but now you moved the trust requirement from me having to trust the people working on the code, to me having to trust the tool that hosts the code. I'm not convinced your model is better. :P
        3y ago
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

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
      All good points, but now you moved the trust requirement from me having to trust the people working on the code, to me having to trust the tool that hosts the code. I'm not convinced your model is better. :P
      - 3y ago

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