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

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?

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

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.

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

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

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 is making me super nervous.

What am I missing?  How can these concerns be mitigated?

						- Ted