Hash history comments and sign them with the author's personal key.#6004
Hash history comments and sign them with the author's personal key.#6004ChrisPenner merged 39 commits intotrunkfrom
Conversation
|
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;
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? |
37b15a0 to
aa40862
Compare
There was a problem hiding this comment.
Part of the migration, this adds nullable versions of the new columns.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
This just moved due to import needs.
There was a problem hiding this comment.
Some changes here to support the new comment hashes, author thumbprints, and author signatures.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
28e1af1 to
0af09bd
Compare
258064e to
6f4d4ac
Compare
There was a problem hiding this comment.
Moved into the unison-credentials package
| - http-types | ||
| - ki | ||
| - lens | ||
| - lock-file |
There was a problem hiding this comment.
Moved into unison-credentials
abdb970 to
9b4a76e
Compare
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. |
Which approach does command-line |
aryairani
left a comment
There was a problem hiding this comment.
after reverting the cabal hpack version lines (sorry) I would say it can be merged
ssh does support encrypted keys of course, in SSH's case that key represents your ability to sign into remote servers, 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 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? |
|
Makes sense. |
|
The Cabal smoke test failure seems like a simple one – need to add the new The Weeder failures seem to be due to CI using Weeder 2.7.0 vs
I suggest that this PR disable the Weeder check in CI. It‘ll be re-instated with the correct version when #6046 is merged. Independently, we can remove freckle/weeder-action in favor of running |
f4e6821 to
4966a7b
Compare
It seems to work now.
cb0e671 to
ef5feec
Compare
|
It looks like this was merged red, but it was merged as part of a later branch that made it green ✅ |
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:
credentials.jsonfile.unison-clithere.ensure hashing uses a canonicalized serialization of the components to ensure no hash-collisions that can result froma simple concatenationInteresting/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.