Re: slowly decommission bugzilla? (was: Re: kernel.org tooling update)

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Thu, 2026-04-02 at 09:07 -0400, Theodore Tso wrote:
> On Thu, Apr 02, 2026 at 12:59:46AM -0400, Konstantin Ryabitsev wrote:
> > # git-bug
> > 
> > The git-bug project aims to keep bug tracking integrated into the
> > git repository itself. It's not a new project -- it's been around
> > for a while, though its development has been advancing in spurts.
> > The fundamentals are sound and the design is robust. It's an active
> > project with ongoing development:
> 
> The documentation from git-bug is not great from the perspective of
> someone who is trying to understand the security properties of the
> system.  But after looking at the architecture documents, I *think*
> this is how it works.  Please correct me if I'm wrong, perhaps git-
> bug can improve their architecture docs?

I'll second that.  I didn't really understand how it works until I both
read the docs and played with the b4 bugs to see what they were
storing.

> 1) A separate git repository is used for the bug store it's not the
> same git repo as the project where the project's sources are stored.
> (Your use of "the git repro" in your first paragraph made me made my
> eyebrows --- *surely* we wouldn't put the bug tracking information in
> linux.git, right?  But looking at the the git-bug documentation, it
> wasn't immediately obvious without my having to read way more
> documentation pages than I would have liked.  From git-bug's
> perspective, if they want to keep people from running away screaming
> before giving it a fair shake, they should think about having some
> high-level architecture documents that explains how this actually
> works.)

No, that's not necessarily correct.  For instance if you look at the
bugs in the b4 repo, they're in the main tree and you can fetch them
with

git fetch origin +refs/bugs/*:refs/bugs/*

However, each bug is its own disconnected commmit tree, so technically
they can be separated from the main repo and certainly if you remove
the refs/bugs/<id> and do a git prune it will eliminate all commits for
that bug because they're now disconnected (modulo some playing with the
packs, if they're already packed).

> 2) The primary way that git-bug seems to be focused is that "bridges"
> are used to sync status between some other bug tracker (such as
> github's issue tracker) and the git bug.

I think bridges are just for portability.  They don't seem to be
required (at least the only bridge is a jira one and b4 isn't using
it).

> 3) You *can* create new bugs via the git-bug CLI, but this
> seems... weird, since only a person who has write access to a git
> repo can create a bug.  Sure, anyone can fork the git repo, and
> create a bug in their local repo, but then in order to publish it,
> either (a) you have to have credentials so you can publish to some
> publically available bug tracker via a bridge, or (b) you can
> convince someone to pull from your repo to get your new bug --- but
> that is going to have to be a trusted source, because...

Perhaps it would be better to look at it the same way we look at
development trees: anyone can create a bug in their local tree at
refs/bugs/<id>.  By virtue of the id is generated, it will be globally
unique.  But you're right, to make it visible to all, the master tree
has to pull it.  git-bugs doesn't define the mechanism by which the
master tree decides to pull, so that's up to the implementation I
suppose.

Part of the idea of b4 bugs seems to be a web interface for creating
bugs in projects.

> 4) A git pull from some other bug tracking repo would completely
> bypass any kind of anti-SPAM or quality checking.  This is much like
> how a maintainer might trust doing a git pull from a submaintainer,
> but the submaintainer has to be trusted, because doing code review
> before doing a pull is... possible, but it requires a human being to
> sanity check a pull and make look for red flags, but in general you
> only pull from trusted repositories.  (Which is why I hate github
> PR's as being a security disaster in waiting for Jia Tan style
> attacks, but that's for another rant.)

Well, yes, but you could say the same about any code pull request a
maintainer accepts.  We mitigate this by only pulling from trusted
sources, so the same mitigations should work for bugs.

> 5) If there are any data format attacks where a maliciously crafted
> git-bug object can trigger some kind of security failure (SQL
> injection, shell quoting attacks, ... the mind boggles), which can be
> introduced either via a malicious issue that translates through a
> bridge, or via a "git pull" from a trusted repository, this could be
> used to attack either trusted infrastructure where the webui is
> hosted, or a developer's development machine behind their firewall.

I could say the same as above, but I think here you're talking about
the json data in /ops which is easier to craft maliciously than simple
git pull data which is all blobs as far as our web based git repos see.
The risk is certainly there, yes, but there are well known ways of
sanitizing json data, so it doesn't look to be off the charts.

Regards,

James