Re: linux-distros list membership application - CIQ Rocky Linux Security Team

[Neal Gompa <ngompa13 () gmail com>]

On Fri, Oct 13, 2023 at 8:07 PM Martin Hecht <martin.hecht () hlrs de> wrote:
> Hi,
>
> On Fri, Oct 13, 2023 at 12:50 "Neal Gompa" <ngompa13 () gmail com> wrote:
> > > The publicly verifiable track record currently consists of timely
> > > rebuild and re-release of RHEL security update packages and security
> > > advisories, as published here:
> > >
> > > https://errata.rockylinux.org
> > >
> > > Not currently verifiable publicly, but Gregory further tells me:
> > >
> > > "We've been doing LTS privately to our customers for over a year now.
> > > This means we maintain security fixes for customers who need long term
> > > support for point releases."
> > From my point of view, this does not count. Rocky's public track record
> > of rebuilding RHEL updates and shipping them in a timely fashion does
> > not indicate that Rocky/CIQ can respond effectively when you have a craft
> > updates from scratch. Furthermore, there are public posts and articles
> > indicating that Rocky Linux/CIQ has trouble with shipping updates in a
> > timely fashion at all.
>
> I'd like to give an example against this. With the recent glibc issue
> (CVE-2023-4911) we were closely following the upcoming fixed packages.
> While we were installing the Rocky packages in the late evening of Thu Oct 5,
> I had the impression that the Redhat packages became available later on Friday.
> It might be attributed to some hours of delay between arriving on the repo
> servers vs. being announced via advisory. But, anyhow, accusing Rocky being
> late in providing packages at least is not valid in general imho. At least
> important ones, like this one, seem to arrive rather quickly. Without mentioning
> the distros, I have seen quite some announcements even around a week later.

The fix for Rocky 8 and Rocky 9 are purely imports from RHEL:

* R8: https://git.rockylinux.org/staging/rpms/glibc/-/commit/6433675bfaab392b362993d8ff8d576335e6bcd4
* R9: https://git.rockylinux.org/staging/rpms/glibc/-/commit/610a8a6829e1e604ff018daccf6bf63620edd19d

I did see that Louis Abel attempted to do something for Rocky 8, but
it was not shipped. I have also not seen much in terms of upstream
engagement indicating the bidirectional relationship expected for
members of linux-distros@.

> > > > Not be (only) downstream or a rebuild of another distro (or else we need convincing additional justification of 
> > > > how the list membership would enable you to release fixes sooner, presumably not relying on the upstream distro 
> > > > having released their fixes first?)
> > >
> > > Besides being a "downstream or a rebuild of another distro", CIQ has its
> > > LTS branches and Rocky Linux has its additional and replacement packages
> > > via the SIGs.  Security maintenance for these should be provided by CIQ
> > > and Rocky Linux.
> >
> > Special interest groups cannot count because they are intended to be
> > public community projects. Unless you're saying that all Rocky Linux
> > SIGs are shadows of CIQ work that can be held back for public consumption,
> > that is effectively out of scope for consideration.
>
> I think the point here is "*not only* being a rebuild of another distro".
> So, their engagement with SIG should already be a valid add-on to be honored.
> Anyhow, the fact that CIQ offers LTS branches and professional support,
> as well as their promise to provide backports of upstream fixes independent
> of RHEL clearly distinguishes them from a "pure distro rebuild".
>
> https://ciq.com/products/rocky-linux/benefits/enterprise-level-support/
>
>
> > > Some security issues in upstream packages may be mitigated or fixed by
> > > pushing "security override" packages via CIQ's customer-facing repos and
> > > the Security SIG repos, without waiting on upstream distro's fixes and
> > > for issues or point releases where no upstream fixes are expected.
> > >
> > > Related previously accepted membership application (precedent) is
> > > CloudLinux's, which is now perhaps best known for AlmaLinux, another
> > > prominent EL distribution:
> > >
> > > http://www.openwall.com/lists/oss-security/2017/07/02/2
> >
> > CloudLinux's membership was based on the fact that they replaced and
> > maintained a very large chunk of the distribution for their own
> > purpose. They used a RHEL compatible userland, but most of the server
> > software stacks and the kernel were replaced with their own builds.
> > They wanted access for the maintenance of that stuff, which is very
> > reasonable.
> >
> > Rocky/CIQ has not demonstrated a similar need from my point of view.
>
> You could take the hardened glibc version of the before mentioned SIG for this
>
> https://rockylinux.org/news/security-sig-update/
>
> Note, this is a different story than the backport of the fix for CVE-2023-4911.
>
> > Fedora is not a member because there is no mechanism in the project to
> > hide anything from the community. For this reason, I have not
> > considered joining as a representative of CentOS Hyperscale, Mageia,
> > or Fedora (all distributions that I do participate in security
> > response for).
>
> Well, assuming there was a security team in these projects able to obey
> the embargo regulations, wouldn't they have tried to join?
> But, nevertheless, what is the relation of the organizational structure
> of these projects with the current application of CIQ/Rocky, after all?

The point I'm making is that SIGs do not count because they cannot
obey embargo regulations. No open project or community project can do
that without having some mechanism for private controls, which is
antithetical to the community process. They fundamentally are
ineligible to join because they cannot keep anything secret.




--
真実はいつも一つ！/ Always, there's only one truth!