4 ms·

I feel like those goals align pretty well with https://github.com/MichaelMure/git-bug https://github.com/MichaelMure/git-bug, and many are already there. If you

I feel like those goals align pretty well with https://github.com/MichaelMure/git-bug https://github.com/MichaelMure/git-bug, and many are already there. If you feel like pushing your own project is too much to bear, maybe consider contributing to git-bug to make it your own?

q3k 5y ago
I know of git-bug, it's a great idea and I watch its development carefully, but I'm explicitly looking to leverage benefits of a centralized system with bugless. I'm not targeting open source software projects that need a decentralized system that works well with an existing Git repository, but communities and organizations that already run infrastructure, including SSO/authz. What I want, for example, that would be difficult/impossible to achieve with git-bug's current distributed model (if I understand it correctly): per-issue/component authorization (secrecy!), ease of access to non-git users, history rewriting/sanitizing, built-in large attachment hosting, gigabytes of issue data and generally large scale deployments for large organizations.
- michaelmure 5y ago
  Let see: -- per-issue/component authorization (secrecy!): git-bug already support internally to attach crypto keypair to an identity and sign/verify the created commits. What's missing is proper tooling around that, ACLs and a way to configure them (a project settings datastructure), possibly a way to encrypt entirely the stored data. It's planned for the most part, good to have otherwise. -- ease of access to non-git users: the goal is to have the webui to act as the public portal with external auth (github or your company SSO). I definitely agree that a bugtracker should not be just on the dev computer and should not require special tooling. -- history rewriting/sanitizing: not so sure what you really want here. Editing comments is already possible. Otherwise, it's still possible to just delete a bug or add more concepts in the data model (archive, delete comment ...). -- built-in large attachment hosting: Definitely planned. The data model already support that, it's just a matter of exposing it in the different user interfaces. Now for the storage usage, see below. -- gigabytes of issue data and generally large scale deployments for large organizations: The funny thing when you put all the data in git is that the problem becomes "how to host git at scale", which is a sort of solved problem already. On top of the obvious, there is solutions like git LFS if you don't want to retrieve all the potentially large attachments. Also, as each bug is independent from each other, you can also shard a repo or just retrieve the bugs you care about with some filter.
  - q3k 5y ago
    For secrecy and access, just relying on end-user keys and encryption is not good enough for me - e2e encryption UX is tricky (key management, backup, access from multiple devices, onboarding), and tends to turn less technically minded users away (or they lock themselves out by not properly backing things up). For history rewriting and sanitizing: I mean, someone posted something that needs to be removed before it's seen by a wider audience. I don't know, customer PII in the wrong component, abusive content (eg. dox) on a public tracker or internally by a disgruntled employee, server logs in an attachment that should be removed a year after having been posted (in accordance with a privacy policy), etc. I want to ensure that content can be nuked, and access to sensitive data revoked. This is also another reason why secrecy via e2e encryption in a fully decentralized system doesn't work for me: if a user's key gets compromised, all secret data that this user had access to is forever accessible to the attacker. With server-side access, it can be revoked, which helps if the data has not yet been downloaded. Plus you can keep an audit trail to detect any attempts at data exfiltration, while data exfiltrated by key compromise might never be detected.
    - michaelmure 5y ago
      That's fair, those are indeed hard to do right or impossible (although I hope we can collectively solve the "people use crypto keys properly" problem at some point).
    - michaelmure 5y ago
      Just a note though, you could centralize git-bug. Standardize/build on what git-bug is doing, and just don't expose the bug data in the same repo as the code. You then just need the extra bits of centralized administration.

q3k 5y ago

I know of git-bug, it's a great idea and I watch its development carefully, but I'm explicitly looking to leverage benefits of a centralized system with bugless. I'm not targeting open source software projects that need a decentralized system that works well with an existing Git repository, but communities and organizations that already run infrastructure, including SSO/authz. What I want, for example, that would be difficult/impossible to achieve with git-bug's current distributed model (if I understand it correctly): per-issue/component authorization (secrecy!), ease of access to non-git users, history rewriting/sanitizing, built-in large attachment hosting, gigabytes of issue data and generally large scale deployments for large organizations.

michaelmure 5y ago
Let see: -- per-issue/component authorization (secrecy!): git-bug already support internally to attach crypto keypair to an identity and sign/verify the created commits. What's missing is proper tooling around that, ACLs and a way to configure them (a project settings datastructure), possibly a way to encrypt entirely the stored data. It's planned for the most part, good to have otherwise. -- ease of access to non-git users: the goal is to have the webui to act as the public portal with external auth (github or your company SSO). I definitely agree that a bugtracker should not be just on the dev computer and should not require special tooling. -- history rewriting/sanitizing: not so sure what you really want here. Editing comments is already possible. Otherwise, it's still possible to just delete a bug or add more concepts in the data model (archive, delete comment ...). -- built-in large attachment hosting: Definitely planned. The data model already support that, it's just a matter of exposing it in the different user interfaces. Now for the storage usage, see below. -- gigabytes of issue data and generally large scale deployments for large organizations: The funny thing when you put all the data in git is that the problem becomes "how to host git at scale", which is a sort of solved problem already. On top of the obvious, there is solutions like git LFS if you don't want to retrieve all the potentially large attachments. Also, as each bug is independent from each other, you can also shard a repo or just retrieve the bugs you care about with some filter.
- q3k 5y ago
  For secrecy and access, just relying on end-user keys and encryption is not good enough for me - e2e encryption UX is tricky (key management, backup, access from multiple devices, onboarding), and tends to turn less technically minded users away (or they lock themselves out by not properly backing things up). For history rewriting and sanitizing: I mean, someone posted something that needs to be removed before it's seen by a wider audience. I don't know, customer PII in the wrong component, abusive content (eg. dox) on a public tracker or internally by a disgruntled employee, server logs in an attachment that should be removed a year after having been posted (in accordance with a privacy policy), etc. I want to ensure that content can be nuked, and access to sensitive data revoked. This is also another reason why secrecy via e2e encryption in a fully decentralized system doesn't work for me: if a user's key gets compromised, all secret data that this user had access to is forever accessible to the attacker. With server-side access, it can be revoked, which helps if the data has not yet been downloaded. Plus you can keep an audit trail to detect any attempts at data exfiltration, while data exfiltrated by key compromise might never be detected.
  - michaelmure 5y ago
    That's fair, those are indeed hard to do right or impossible (although I hope we can collectively solve the "people use crypto keys properly" problem at some point).
  - michaelmure 5y ago
    Just a note though, you could centralize git-bug. Standardize/build on what git-bug is doing, and just don't expose the bug data in the same repo as the code. You then just need the extra bits of centralized administration.