4 ms·

Does it support commit signing? I spent a while reading the website and couldn't find anything suggesting it does. Lack of that is a showstopper for me (and fra

Does it support commit signing? I spent a while reading the website and couldn't find anything suggesting it does. Lack of that is a showstopper for me (and frankly, should be a showstopper for anyone).

alwillis 4y ago
Yes: sl help sign
juped 4y ago
Please stop signing commits
- sixstringtheory 4y ago
  This is a new one for me. Why is it bad to sign commits?
elric 4y ago
There is a distinct lack of decent identity management/security in all of the version control systems I've used. It's a hard problem to solve, especially in a distributed/decentralized system (like git). Signing git-style commits is problematic in the face of merge conflicts or rebasing. A patch-style system (like Pijul) probably makes this easier: if everything is a patch, every patch can be signed atomically. I'd really like to see a DCVS with better signing support and with some form of access control (on the remote), so every change can be traced back to the author, and so that some parts of a repo can only be modified by specific authors. Git hooks (on the remote) can sort of achieve the latter, but it's a bit of a pain.
- hgomersall 4y ago
  I don't see why the git way is problematic. It means someone is verifiably taking responsibility for all changes. That applies to conflicts and reading as much as normal commits. Edit: I'm not saying there's not a better way, just that I don't understand the problem with git.
  - elric 4y ago
    Two issues: 1. You could retroactively sign something with an expired key and rewrite history 2. The one doing the conflict resolution signs the whole merge commit, but didn't author the stuff they're signing.
    - hgomersall 4y ago
      1. I accept there's a requirement for a second level of verification on the signature, but I can't see how that's avoided in any scenario (that is, the signing is orthogonal to the verification). 2. That's the point though. The person doing the commit takes responsibility. The individual commits are still there before the merge (including signatures), so there's no loss of responsibility or credit before the merge.
- pmeunier 4y ago
  > A patch-style system (like Pijul) probably makes this easier: if everything is a patch, every patch can be signed atomically. In Pijul, patch authors are public keys and patches are signed by default. The link with an author's identity is done outside of the patches to allow for changes in name or email address.
- juped 4y ago
  If there's a "the remote", it's not a DVCS, and you can rely on ssh or whatever.

alwillis 4y ago

Yes: sl help sign

juped 4y ago

Please stop signing commits

sixstringtheory 4y ago
This is a new one for me. Why is it bad to sign commits?

elric 4y ago

There is a distinct lack of decent identity management/security in all of the version control systems I've used. It's a hard problem to solve, especially in a distributed/decentralized system (like git). Signing git-style commits is problematic in the face of merge conflicts or rebasing. A patch-style system (like Pijul) probably makes this easier: if everything is a patch, every patch can be signed atomically. I'd really like to see a DCVS with better signing support and with some form of access control (on the remote), so every change can be traced back to the author, and so that some parts of a repo can only be modified by specific authors. Git hooks (on the remote) can sort of achieve the latter, but it's a bit of a pain.

hgomersall 4y ago
I don't see why the git way is problematic. It means someone is verifiably taking responsibility for all changes. That applies to conflicts and reading as much as normal commits. Edit: I'm not saying there's not a better way, just that I don't understand the problem with git.
- elric 4y ago
  Two issues: 1. You could retroactively sign something with an expired key and rewrite history 2. The one doing the conflict resolution signs the whole merge commit, but didn't author the stuff they're signing.
  - hgomersall 4y ago
    1. I accept there's a requirement for a second level of verification on the signature, but I can't see how that's avoided in any scenario (that is, the signing is orthogonal to the verification). 2. That's the point though. The person doing the commit takes responsibility. The individual commits are still there before the merge (including signatures), so there's no loss of responsibility or credit before the merge.
pmeunier 4y ago
> A patch-style system (like Pijul) probably makes this easier: if everything is a patch, every patch can be signed atomically. In Pijul, patch authors are public keys and patches are signed by default. The link with an author's identity is done outside of the patches to allow for changes in name or email address.
juped 4y ago
If there's a "the remote", it's not a DVCS, and you can rely on ssh or whatever.