Idea: privacy-sensitive way to link commits to author in The Nest

Development
1

I’ve never liked the idea to tie an email address to my commits for privacy reasons, but of course I want to be linked somehow to my work. Would it be possible to rely on the key-pair used to sign commits instead? To avoid users claiming other users’ work by copy-pasting public keys in their profiles The Nest should check that a person really owns a given public key by asking to sign some random string before accepting it.

Could something like this work? I think I would like it more than GitHub’s solution (it generates a no-reply email for users that don’t want to make email addresses public).

2

This is actually how it was done before I made the mistake of switching to PGP. It’s actually really cool, and I want that too. Let’s see if I can find a way to implement it in the next Pijul.

1 Like
3

I’m curious, why do you consider switching to PGP a mistake? As much as I like minisign I wonder if the lack of key revocation is a problem when signing commits

4

Because it would now be easier to code your own domain-specific tiny clone of PGP, including key revocation, than to install Pijul 0.12 on any platform other than NixOS (where installing anything is almost always trivial anyway).

5

I wrote an implementation of PGP in Rust years ago, I swore I would never touch PGP ever again after that, and I got tricked again. Anyway, Sequoia PGP is a great implementation of PGP, the problem is not the implementation, it’s the clunky standard requiring weird crypto libraries and overcomplicated APIs.

6

I see. I thought Sequoia was a pure implementation in Rust, I guess that will never happen and that’s why a lot of cryptographers gave up PGP already.

What about adding key revocation to minisign?

7

As I suggested elsewhere before, we should design a forward-secure scheme for this.

We’d have a key update procedure which looks vaguely like: A repository creates their own current secret key, which they store in ~/.pujil-repo-secrets or similar, but not even under the repository tree itself. The repository adds the corresponding public key to itself. If the repository had a previous public key, then the new key certifies it. If the repository had a previous secret key, then it certifies this new public key, and deletes its old secret key. The public keys and certificates go into [repo]/.pujil/forensics.

We run this key update procedure periodically, maybe yearly or monthly by default, which causes some growth of .pujil/forensics. If you copy or move a repository, even locally, then it’ll create a completely new secret key, well unless you edit the secret key fine in ~/.pujil-repo-secrets too. All repositories automatically sign their patches using their current secret key.

All this yields ownership chain which show from which local repositories patches originate. A simple cp command creates an entirely new identiy, but you then cross certify from other repos if desired. An individual user is defined by the certiffications chains, both manual and forward & backward from automatic key updates. You can sign repository states too.

In this way, all users sign all their patches. If some machine gets compramized, then attackers only have access to its current secret keys, not older ones. If a bad patch is discovered, then .pujil/forensics gives considerable information.

At some point, someone could add encryption of repository secret keys using the machine’s TPM too, but that’s optional. Another password protected layer would be optional too.