Identify a user with Github #9
Replies: 12 comments
-
@dpc so do you think this is a bad idea or....? From floating the idea in the matrix channel the response seemed generally not-so-keen. I still think it's a good idea though, so I've tried to write down my thoughts here 🤷 |
Beta Was this translation helpful? Give feedback.
-
I think @kornelski is already working on being able to do "trust ". However under the hood, everyone gets a crevid. I think this is a sweet compromise for making life easier for majority of users, while not breaking anything for users of other services. In Also, I'd like to point our that the meaning of
|
Beta Was this translation helpful? Give feedback.
-
BTW. I'm super happy to see go implementation being worked on! |
Beta Was this translation helpful? Give feedback.
-
I've implemented something that is technically GitHub-independent: proving that user owns the URL, and the URL may be a GitHub repo.
This works for any URL, so it works with GitLab, corporate git repos, self-hosted domains, etc. It doesn't require any other keys, so there's no extra crypto work. I've also implemented
To use GitHub-published SSH keys you'd have to require user to prove they have the corresponding private key. SSH supports tons of algorithms, so it'd require crev clients to support tons of algorithms. So I think establishing ownership of a github URL with existing Crev Id signatures is a simpler solution. |
Beta Was this translation helpful? Give feedback.
-
There are still interesting things that can be done with GitHub API. In my GUI I plan to use GitHub's API to see who user follows on GitHub, check for |
Beta Was this translation helpful? Give feedback.
-
Sounds cool 👍
Right. I think that makes sense for cargo-crev. With go-crev there's nothing much to break right now, so I might forge ahead with Github users as a first-class identity type, but I'll mull it over and experiment a bit.
Got it. That was my understanding of it too, but good to align 😁
Yup, so far I've been building the implementation with this in mind. |
Beta Was this translation helpful? Give feedback.
-
Thanks for the details! One thing I'm not clear on about proving ownership of a URL:
So does that mean that this is not considering situations where we have aggregators or caches or whatever? Maybe this isn't a problem now...
So we look at whether the URL contains proofs created and signed by the user? If an aggregator has one of my proofs, then if I put that aggregator's URL in the
How so? I thought the point of asymmetric keys is that I can prove the user has the private one by validating one of their signatures using the public one. Or am I missing something? I does mean the user has to point to the key we have to use to sign things and we have to figure that out.
Noted, will think about this 🤔
Cool idea 👏 |
Beta Was this translation helpful? Give feedback.
-
When you make a review, always include your own URL. Never sign someone else's URL. Aggregators copy proofs unchanged. They can't change the URL in the proof file, because the URL is signed. So you know which proofs are aggregated, because URL in the proof does not match the URL you've fetched the proof from. You can know URL ownership only when the URL you've fetched matches the URL signed inside the proofs you've fetched. If you fetch crevid1 = evil.com/bar then you know that crevid2 owns |
Beta Was this translation helpful? Give feedback.
-
I guess that makes sense and most users would do so anyway, but does it restrict signing an aggregator? Let's say there's team of researchers and they all put their ids into the same repo. Or a a team inside a company. Does everything still holds? Another one problem that I haven't considered - anyone that is able to get their proofs into an aggregator, will be able to pretend to be the "owner" of that aggregator? Are there any problems lurking there? |
Beta Was this translation helpful? Give feedback.
-
Good point. I suppose currently an aggregator can monitor what it aggregates, and don't take unauthorized proofs claiming its URL. Should we have something explicit for aggregators that clearly says "I'm an aggregator, these identities are not mine"? Or a unique location in the repo for the "own" identity? |
Beta Was this translation helpful? Give feedback.
-
@kornelski Maybe. I guess aggregators will not really have their own ID anyway, so is there even a point trying to pretend to be them? I guess we can worry about it once there are actually some aggregators around. :D |
Beta Was this translation helpful? Give feedback.
-
I think we'll need to hash it out eventually. I've created an issue for this: https://github.com/crev-dev/crev/issues/7 |
Beta Was this translation helpful? Give feedback.
-
Github provides a way to identify developers.
Github already supports hosting public keys (V3 endpoint)
Advantages
Simple easy identity names
Users can be identified by short, simple, human-readable usernames.
Note: they are not stable so the actual stable Github account ID must be resolved.
It's nice to be able to say like
gocrev id trust @LaurenceGA
.This can lower the barrier to entry for potential members of the community.
Most developers have a Github identity
Again, quickly lowers a barrier to entry for potential members of the community.
You can even trust someone before they create a CrevID, in case they do later.
Single key and identity dissociation
Github supports multiple keys. So I can sign proofs from multiple different devices with different keys, as long as they're both linked to my Github account. This saves me from having to share these keys across devices. Furthermore, if I lose a key, I can easily transition to a new one without people having to trust my new key, because they already trust my identity.
Easy setup
You can just type
gocrev id set-current @me
and we can auto-fetch your keys. You don't have to set a password. People don't always like creating new accounts and having to come up with a new password with produce some deterrent effect.
Easy repository discovery
We can just have a look at the user's repositories and look for a
/crev-proofs
.Not fool proof of course, but might help a bit.
Disadvantages
More power to monopoly
Ties many identities to Github, and already huge monopoly. People should have the choice not to have to use a single provider.
Verification more complicated
We have to check all of a user's public keys. This means an API call for each unique user across all proofs.
CrevID is fine
This does require more work to implement. But, cargo-crev is already looking at more type of identity and since go-crev is a new implementation, it's a good opportunity to re-think.
Beta Was this translation helpful? Give feedback.
All reactions