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.
• Extracts the credentials management into its own package, since we need to use it in the migration and can't depend on unison-cli there.
• ensure hashing uses a canonicalized serialization of the components to ensure no hash-collisions that can result froma simple concatenation

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

• Verify that the credentials.json is ported correctly.

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.

[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?

[ChrisPenner]

Part of the migration, this adds nullable versions of the new columns.

[ChrisPenner]

Part 3 of the migration, this makes the new columns non-nullable in SQLite's own annoying way, which is creating a new table and copying all the data between them, then dropping the original and renaming the new one.

[ChrisPenner]

This just moved due to import needs.

[ChrisPenner]

Some changes here to support the new comment hashes, author thumbprints, and author signatures.

[ChrisPenner]

Now that migrations need a credential manager I rewrote the bulk of the credential manager stuff to support a proper singleton, which should be safer when multiple parts of the app may have their own credential managers; I also pulled it out into its own package so it can be accessed in the Migration.

[ChrisPenner]

All new Personal Key stuff.

A personal key is just a public-private EdDsa key pair, which is stored in the user's credentials.json file.

[ChrisPenner]

Moved into the unison-credentials package

[ChrisPenner]

Moved into unison-credentials

[aryairani]

it's basically treated the same as your Share token, but with the added ability of cryptographic signing and a public key.

Okay, makes sense. Sorry I just spotted your reply now.

Edit: It was a draft PR at the time so I feel less bad about not noticing the comment.

[aryairani]

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?

Which approach does command-line ssh use?

[aryairani]

danger here; in the other cabal files too

[aryairani]

side note: stack 3.1.1 (which I haven't tested yet?) has a force-hpack option (or something) which will make this less dangerous once we're on that version.

[aryairani]

after reverting the cabal hpack version lines (sorry) I would say it can be merged

[ChrisPenner]

@aryairani

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?

Which approach does command-line ssh use?

ssh does support encrypted keys of course, in SSH's case that key represents your ability to sign into remote servers,
in our case, currently the key is only used to signify the author of a comment.

If we're legitimately concerned about a user's credentials file being stolen or leaked then we shouldn't be storing unencrypted auth tokens on disk at all; since currently an attacker would just take the user's OAuth token rather than their personal key.

AFAIK storing unencrypted credentials is quite a common practice, e.g. the AWS cli just stores your unencrypted creds at ~/.aws/credentials; google does the same in ~/.config/gcloud/

Not saying it's bad to allow requiring a password for this stuff, and maybe if we end up using the personal key for accessing Unison Cloud we may wish to add more layers of security, but at the moment I don't think it's worth the time to implement, since if an attacker has access to your file-system we have bigger concerns than them fraudulently signing comments in your name;

Hrmm, Is that a reasonable stance?

[aryairani]

Makes sense.
🤞 for CI

[github-actions]

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

• Cabal / smoke-test

Created by continue-on-error-comment