Several people asked if it would be possible to have "private" bugs, for security sensitive issues and such.

With the new identity management, we will eventually have crypto keypair associated with these identities to sign the bug editions and so on. We can leverage this and encrypt the bug operations with a multi-reader crypto scheme to limit who can read the bug.

https://crypto.stackexchange.com/a/12431 give insight about what such crypto scheme might looks like.

Some things to keep in mind though:

• user key revocation/rotation
• we might need to store independently from the bugs the groups information (symmetric key K to encrypt the data, K encrypted for each user keys). Bug data is immutable so if we want to give access to someone else, it's not possible if everything is in the encrypted OperationPack.
• what happen if a user key is leaked ?

It doesn't even have to be the whole bug, it can also be just a comment. If an operation is encrypted, it becomes a no-op for users that can't decrypt it, and it still works for them.

Another reason to have https://github.com/MichaelMure/git-bug/issues/118

I'd say another reason to have #75.

Then sensitive bugs can be shared via secured means, independently of the public bugs. Either pushing them to a private repo, encrypting it, or something else.

In my opinion making them private by marking them as such with 'metadata' will always be problematic. The main reason people want "private" bugs is because they want to treat a subset of bugs differently.

As of now, git-bug just gobles all bugs into a shared namespace which is problematic for at least two popular requested features: private bugs and bug PRs. And more importantly, the Inability to use git-bug as a "Distributed bug tracker embedded in Git".

@rafasc you make a very good point about the metadata. With this scheme, even thought every actual data (title, comments, author ...) would be encrypted, there is still the knowledge that a discussion is happening. Which might or might not be acceptable.

Sorry I didn't really replied to your inputs. Both of those subjects are for now at a lower priority and those issue serve mostly as brain dump for when they get into the drawing board. My point is, I don't have an answer yet.

And my motivation for commenting here was too keep the threads connected. So when the time comes to address this issue, the other suggestion is at least taken in consideration. :)

This bot triages untriaged issues and PRs according to the following rules:

• After 90 days of inactivity, the lifecycle/stale label is applied
• After 30 days of inactivity since lifecycle/stale was applied, the issue is closed

To remove the stale status, you can:

• Remove the lifecycle/stale label
• Comment on this issue

github-actions (github-actions) added label lifecycle/stale 1 year ago

This bot triages issues in order to help the maintainers identify what needs attention, according to the following lifecycle rules:

• After 90 days of inactivity, lifecycle/stale is applied
• After 90 days of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied

This bot will not automatically close stale issues.

To remove the stale status, you can:

• Remove the stale label from this issue
• Comment on this issue
• Close this issue
• Offer to help out with triaging

To avoid automatic lifecycle management of this issue, add lifecycle/frozen.

github-actions (github-actions) added label lifecycle/rotten 11 months ago

github-actions (github-actions) removed label lifecycle/stale 11 months ago

sudoforge removed label lifecycle/dormant 7 months ago