Re: New bug in Audit

From: Paul Moore <paul@paul-moore.com>
To: Steve Grubb <sgrubb@redhat.com>
Cc: linux-audit@redhat.com
Subject: Re: New bug in Audit
Date: Mon, 9 Jan 2023 23:38:48 -0500	[thread overview]
Message-ID: <CAHC9VhSPoAtf-_1LOsHFc7XbO76azy_Q_MjG6Y1a1wOAaVPXLA@mail.gmail.com> (raw)
In-Reply-To: <8169595.T7Z3S40VBb@x2>

On Mon, Jan 9, 2023 at 10:59 AM Steve Grubb <sgrubb@redhat.com> wrote:
> On Friday, January 6, 2023 3:33:18 PM EST Paul Moore wrote:
> > > This mailing list is *focused* on upstream work and support, and while
> > > it does not preclude talking about distro specific bugs, I believe
> > > there are better avenues for those discussions (e.g. see the RHBZ link
> > > I provided in my response) as upstream isn't really going to be able
> > > to provide adequate help for someone experiencing problems with a
> > > distro kernel which has a number of patches and backports.
> > >
> > > If you have a problem with this approach, perhaps we should move
> > > upstream development to an audit mailing list on vger.kernel.org and
> > > leave this list for RH specific issues?
> >
> > Steve, I realize it's only been ~24hrs, but should I assume you are
> > okay with that (the upstream focused approach)?
>
> For the 18 years I've spent on this mail list, it has alway been open to any
> topic audit related. I've answered questions for many distributions. If I can
> reproduce the issue, then it's a bug worth looking at. If I can't reproduce
> it, I let them know. I've even answered questions for people writing their
> own audit implementation.

Since I was asked to maintain the upstream Linux Kernel audit
subsystem I've generally asked people to try and reproduce their
problems on a modern~ish upstream Linux Kernel as it simply isn't
sustainable for me to replicate the environment of every problem
report.  Enterprise distributions which run old and/or heavily patched
Linux Kernels should have their own support staff to provide
assistance in these areas, the upstream developers can't support every
distro kernel that ships.

> A lot of the email is upstream kernel work - no doubt. But Many times, we
> miss upstream kernel bugs because no one is running upstream code. We usually
> hear about it when a distribution which stays close to upstream releases a
> new update.

In which case I would expect the distro support team to reproduce the
problem and report it upstream and/or submit an upstream patch for
review.  This has been shown to work very well, and fits nicely within
the "upstream first" motto adopted by some of the better Linux
distributions.

> The text where you sign up for this mail list does not limit the topc to
> upstream work,

Perhaps the term "limit" is a bit strong, but I think it would be good
if the list welcome message indicates that the list is primarily for
the development and support of the upstream Linux audit tools,
distribution specific concerns should be sent to the distribution
provider.

> it allows for any discussion as long as it's audit related. I
> do not think making a new mail list is in anyone's interest. Bugs will always
> get misreported if there are 2 lists.

I disagree, the upstream and Fedora SELinux mailing lists have been a
good example of this working well.  I also tend to think there is some
value in having a vendor agnostic mailing list host, but that's more
of a tie breaker in my mind, and not reason enough alone to force a
switch.

-- 
paul-moore.com

--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit