Hash history comments and sign them with the author's personal key.

[ChrisPenner]

Overview

Adds a migration which hashes and signs all of a codebase's history comments, as a step towards syncing them with Share.

Implementation approach and notes

Adds a Migration which:

• Creates a Personal Key for the user.
  • A personal key is a randomly generated EdDSA public/private key pair which is stored in the user's credentials.json file.
  • This key can be used to assert the user's identity across code-servers in a cryptographically verifiable way.
• Maps over all the user's history comments and hashes and signs them, we'll need the hash and author for syncing with share.

TODO:

• Actually sign the comments with the personal key, not just embedding the thumbprint.

Interesting/controversial decisions

It's hard to know whether personal keys are overkill or not, while it would likely be possible to get away with just Share auth in the short term, I don't think it's really sound in the presence of multiple codeservers; I opted to implement personal keys because I believe I'll get mileage out of them in the future, e.g. they can be used for things like service-account auth in CI and such.

Test coverage

I tested the migration by creating some comments on a trunk build and running the migration on it, then creating some new comments.

Loose ends

Next up is to implement the comment sync APIs.

[github-actions]

Some tests with 'continue-on-error: true' have failed:

• Cabal / smoke-test

Created by continue-on-error-comment

[aryairani]

We need a passphrase option here, right? Or what's the standard

[ChrisPenner]

@aryairani

We need a passphrase option here, right? Or what's the standard

Hrmm, this is a deep rabbit hole to go down that adds a ton of work;

• Do we support various keychains?
• Yubikeys/physical devices?
• Various password managers?
• gpg agent?

I was planning on having ucm manage these complete for the user as basic EdDSA keys, rather than having the user configure their own keys; thus it's basically treated the same as your Share token, but with the added ability of cryptographic signing and a public key.

Do you think passphrases or the other mentioned features are table-stakes?