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

[Konstantin Ryabitsev <konstantin@linuxfoundation.org>]

On Thu, Apr 02, 2026 at 09:07:06AM -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?

Yes, I can totally relate to that sentiment, but "scant docs" is definitely
not a problem unique to this project. :)

> 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?

Right, let me clarify this. I don't expect that we'd be keeping *any* kernel
bugs in torvalds/linux.git. Kernel development happens on a subsystem level
and especially bugs are rarely relevant across the tree, so, in my mind, bug
tracking would be done per-subsystem. They can either use their own fork of
the kernel for this, or they can use a dedicated repo just for bugs.

E.g.:

    pub/scm/linux/kernel/git/mysubsystem/linux.git:refs/bugs/
    pub/scm/linux/kernel/git/mysubsystem/bugs.git:refs/bugs/

You can definitely keep the bugs in your main subsystem tree, as they are in
their own ref and don't impact the heads in any way.

> 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.

That part we don't really care about, though if subsystems like, they can
bridge to a GH/GL tracker. The primary purpose of git-bug, to me, is to keep
bug data a) transparent, b) capable of fully replicating so it doesn't get
gated at a single-point-of-failure.

> 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.

That's actually the whole point. Only subsystem maintainers would be able to
create a bug. To *report* a bug, the reporter would use an ingestion frontend
as I described -- bugs.kernel.org or similar that would pre-analyze the bug,
create a bug report and *then* send the report to maintainers. A bug report
doesn't automatically become a tracked bug in git-bug unless the maintainer
then imports that report into their bug-tracker.

So, yes, only the person who has write access to the repo can create a bug and
that's by design. Everyone else participates via discussions that are synced
to the bug entry whenever the maintainer runs "update" on the bug.

The git-bug entry is simply for lifecycle/tracking/triage purposes.

> 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...
> 
> 4) A git pull from some other bug tracking repo would completely
> bypass any kind of anti-SPAM or quality checking.

Not even part of the picture. The only pushing/pulling that happens is
between co-maintainers to their canonical repo and never from any other
source.

> 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.)

Hopefully that clarifies this concern.

> 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.

This, too.

> This is making me super nervous.
> 
> What am I missing?  How can these concerns be mitigated?

Regards,
-- 
KR