Identity management about git-bug HOT 10 CLOSED

in a fully distributed git world, this is a more important and difficult question...
how do we prevent identity theft?

By having crypto keys. See #130

should measures preventing that be the default or optional?
would each user decide whether they want to use a secure way of identity management, or each repo, or a mix/combination of the two?

My view is that as a general UX principle git-bug should have a default that is 1) functional with little to no configuration 2) address a wide range of use cases and 3) allow to add additional constraint to restrict to a more specific use case.

For this problem in particular, I think the best way would be:

• default would have no crypto keys. Identity theft is possible but that's not a problem in a lot of real life scenario (you would first need to have git write access). Identities are marked as "unprotected".
• it's possible for each user to opt-in and protect their identity by adding keys
• when a project config exist, add a settings to enforce having keys for each identities

is avatar-URL really enough, or should the avatar image rather (optionally) be stored in the repo?

It's very crude at the moment. Yes, it should be improved and stored in the repo if possible.

I feel like such decisions are really hard, and in the end will always have to be changed later on, as one did not think of everything from the start, so the most important thing in my eyes, is to use versioning, and in such a way that really everything can be changed, if deemed necessary, or even just beneficial.

If by versioning you mean data model versioning, it's already there. Every piece of data stored in git has this version number. It's especially important because those are immutable. It's not really used though at the moment.

what is the login used for?

An identity's login is optional and is only meant to store the login used on the bridge that created this identity. It's just informational, to display in the UI both full name and login when available. This exist in part because Github mainly display the login (so you know people by that name) so if you don't have the login in git-bug's UI you can see names you have never seen before even though you know the people.

from git-bug.

Here is the CLI UX I thought about, comments ?

# Display current identity (any identity if <id> is specified)
git bug user [--time <time>] [<id>]

# Create a new identity
git bug user create

# Adopt an existing identity as your own
git bug user adopt <id>

# List identities
git bug user ls

# Display the current name (any identity if <id> is specified)
git bug user name [--time <time>] [<id>]

# Display the current email (any identity if <id> is specified)
git bug user email [--time <time>] [<id>]

# Display the current login (any identity if <id> is specified)
git bug user login [--time <time>] [<id>]

# Display the current avatarURL (any identity if <id> is specified)
git bug user avatarURL [--time <time>] [<id>]

# Set the current name
git bug user set name <name>

# Set the current email
git bug user set email <email>

# Set the current login
git bug user set login <login>

# Set the current avatarURL
git bug user set avatarURL <avatarURL>

# Display the current keys (any identity if <id> is specified)
git bug keys [--time <time>] [<id>]

# Manage keys (to be determined)
git bug keys import ...
git bug keys export ...
git bug keys add ...
git bug keys generate ...
git bug keys revoke ...

from git-bug.

#89 has been merged with the bulk of the changes, but there is a few things left to iron properly before a release can happen.

from git-bug.

As of now, this is pretty much done. All the core features are there, tested and working.

What is left is the few command line tool to get/set particular identity fields:

# Display the current name (any identity if <id> is specified)
git bug user name [--time <time>] [<id>]

# Display the current email (any identity if <id> is specified)
git bug user email [--time <time>] [<id>]

# Display the current login (any identity if <id> is specified)
git bug user login [--time <time>] [<id>]

# Display the current avatarURL (any identity if <id> is specified)
git bug user avatarURL [--time <time>] [<id>]

# Set the current name
git bug user set name <name>

# Set the current email
git bug user set email <email>

# Set the current login
git bug user set login <login>

# Set the current avatarURL
git bug user set avatarURL <avatarURL>

from git-bug.

Is there an intention to allow adopting a bridge identity that has otherwise not interacted with the particular repository? This comment is partially a way of allowing me to adopt my GitHub identity for this repo, because I'm not sure if I can merge the two if I use the exporter. Is that what git bug user set login would do?

from git-bug.

in a fully distributed git world, this is a more important and difficult question...
how do we prevent identity theft?
should measures preventing that be the default or optional?
would each user decide whether they want to use a secure way of identity management, or each repo, or a mix/combination of the two?
is avatar-URL really enough, or should the avatar image rather (optionally) be stored in the repo?
...

I feel like such decisions are really hard, and in the end will always have to be changed later on, as one did not think of everything from the start, so the most important thing in my eyes, is to use versioning, and in such a way that really everything can be changed, if deemed necessary, or even just beneficial.

what is the login used for?

from git-bug.

EDIT: Better read a short article about DIDs,
then the official standard linked to below. ;-)

I just stumbled over W3Cs Decentralized Identifiers (DIDs):

Decentralized identifiers (DIDs) are a new type of identifier to provide verifiable, decentralized digital identity. These new identifiers are designed to enable the controller of a DID to prove control over it and to be implemented independently of any centralized registry, identity provider, or certificate authority. DIDs are URLs that relate a DID subject to a DID document allowing trustable interactions with that subject.

it sounds quite optimal so far. It is still in the making though (as of mid 2020)!

from git-bug.

Not super knowledgeable about DID but AFAIK they don't work offline ?

Note that identities in git-bug is just an interface (https://github.com/MichaelMure/git-bug/blob/master/identity/interface.go). It could be replaced by another implementation someday if the need arise.

from git-bug.

Not super knowledgeable about DID but AFAIK they don't work offline ?

I concluded that same thing just now before coming back here. :-)
basically, DID relies on the unique, singular state of global-state block-chains like Bitcoin and Etherium. In theory, one could fetch stuff once and keep it offline available, but even then I would not deem it a fitting technology, as it relies on the global unique state/the whole internet, and is thus not itsself P2P to the core, as is something like IPFS, git, or git-bug.
It might make sense though, to ditch the blockchian part (basically, the DID address/URL and the way of how to get to the DID document), but use the DID document part of the standard; an example.
This is mostly concerned about authentication and communication. I am not sure if it allows having additional, custom key-value pairs in there, like login. At some point the specification said, that only the DID IRI might be used, which would suggest that it would not be valid. then again, git-bug would not be bound to adhere to that, apart from theoretically having problems with DID document parsing libraries.

Just brainstorming here; not that I think I know how it should be.

Note that identities in git-bug is just an interface (https://github.com/MichaelMure/git-bug/blob/master/identity/interface.go). It could be replaced by another implementation someday if the need arise.

perfect, thanks! :-)

from git-bug.

Closing as it's either done, outdated or non-actionable.

from git-bug.