-
-
Notifications
You must be signed in to change notification settings - Fork 266
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Identity management: step two #130
Comments
Yes, that's the general idea. I haven't written much about it, but here goes the gist:
There is a few design decision to be made:
TODO is:
|
Some of this is happening in #376 |
Still a lot to do, but git-bug's core can now store/load crypto keys and check signatures. |
Per our digression in #963, I wanted to add a few comments related to a) actually signing commits (and as stated above identities) and impacts that this might have on the bridges. a. It's been a couple of years since I worked on GPG in Go but my recollection is that none of the Go libraries implements the new
b. The other problem I see with the above is that when a bridge is importing an identity, it should NOT have access to the private key to sign the created (or updated) identity - and yet it needs to create the users and make sure they're not adopted by the wrong user even without those signatures. I'm also wondering about the "protection rules" above - are there any vulnerabilities to a user who manually edits their project's |
Shot answer: I don't think those are issues, just some area in the design that need more than a naive thinking. Disclaimer: I never used GPG so it's a bit uncharted territory for me.
What I meant by that is really just "the private key is not stored in the git entity, only the public key". After that, where and how the private key is stored doesn't matter, as long as we are able to:
Note: those requirements don't imply that we have access to the private key. It would be perfectly reasonable to have those operations happening externally to git-bug, in the agent or a yubikey. I just implemented that part a bit naively for now. As for the identity data structure, that would mean we would store there only some kind of identifier for the private key (fingerprint, ...), to be able to search it on the user system. Once found, git-bug should make sure that it's indeed the key matching the public key. As for the actual code that would do that, my recollection matches yours. It might be difficult to find code that allows us to have this working easily, with great and transparent UX, and able to reach whatever the user normally use.
My thinking about this is that a bridge would only:
Once the identity is protected, the bridge can't touch it anymore. This could be a little weird but I suppose that's an acceptable UX if we consider that identities "live their lifes" in git-bug once imported. Possibly we can add the following for completeness:
Obviously more pair of eyes on this would be great but I think it's OK? Let's try to unpack some obvious scenario:
This one is obvious: it's unprotected. Nothing prevent anyone to do that. Add a public key.
In the data structure would be a single version, with one or more public key, without a git commit signature. There is no proper crypto signature, yet we have a hash of the full payload, that include the public key.
Now, once we have a matching private key, it would make sense to add a properly signed commit, just as precaution. Which brings us to ...
In the data structure would be 0+ commit without public key, followed by 1 commit with 1+ public key, followed by 1+ commit signed by a key present and valid in the previous commit. Most of the previous reasoning still apply:
The big difference is that it's now possible to have that identity non-uniformly replicated in the git remotes. There is actually two sub-scenario here:
IMHO the scenario 1 is unrealistic, so onward for scenario 2: // TO BE CONTINUED, I'M HUNGRY |
With user's becoming a thing in the codebase, I thought it would be cool to utilize git's gpg signed commit features to allow a user to "prove" their identity via public key.
Having user functionality is wonderful, but what is to stop someone from "adopting" the key of a repository maintainer? Using gpg signatures gives a git native method of verifying who said what on the timeline.
This is defeated however if there is already a system in place for handling identity verification.
The text was updated successfully, but these errors were encountered: