Re: linux-distros application for CentOS Project's Hyperscale SIG

[Mark Esler <mark.esler () canonical com>]

On Wed, Jul 10, 2024 at 03:51:44PM -0400, Demi Marie Obenour wrote:
> On Wed, Jul 10, 2024 at 11:23:56AM -0500, Michel Lind wrote:
> > I am submitting this application on behalf of CentOS Project's Hyperscale SIG.
> >
> > Myself (Michel Lind), as well as Davide Cavalca and Neal Gompa (SIG co-chairs), would be joining if approved.
> >   https://sigs.centos.org/hyperscale/sig/membership/
> >
> >
> > 1. Be an actively maintained Unix-like operating system distro with substantial use of Open Source components
> >
> >   We actively maintain CentOS Stream Hyperscale https://sigs.centos.org/hyperscale/communication/reports/. It is 
> > based on CentOS Stream with key packages upgraded or rebuilt with additional features enabled, intended for 
> > large-scale enterprise deployments but also potentially on modern desktops.
> >
> > Hyperscale can be installed on x86_64 and aarch64 desktops via 
> > https://mirror.stream.centos.org/SIGs/9-stream/hyperscale/images/experimental/ - and CentOS Stream installations 
> > can be converted in place (see https://sigs.centos.org/hyperscale/content/repositories/main/).
> >
> > 2. Have a userbase not limited to your own organization
> >
> >   Our membership and deliverables are open to anyone who wishes to join; contributors have included companies such 
> > as Meta, Datto, Twitter/X, and Intel, as well as individuals
> >   
> > 3. Have a publicly verifiable track record, dating back at least 1 year and continuing to present day, of fixing 
> > security issues (including some that had been handled on (linux-)distros, meaning that membership would have been 
> > relevant to you) and releasing the fixes within 10 days (and preferably much less than that) of the issues being 
> > made public (if it takes you ages to fix an issue, your users wouldn't substantially benefit from the additional 
> > time, often around 7 days and sometimes up to 14 days, that list membership could give you)
> >
> >   Since we provide an overlay on top of CentOS Stream and EPEL, we generally inherit updates as they became 
> > available - and monitor issues as soon as they are disclosed.
> >
> > Between the three of us we have a track record of pushing EPEL security updates: 
> > https://bodhi.fedoraproject.org/updates/?search=&releases=EPEL-8&releases=EPEL-9&releases=EPEL-9N&releases=EPEL-8N&type=security&user=salimma%2C+dcavalca%2C+ngompa
> >
> >   We are increasingly provided updates that our users need before they are fixed in CentOS Stream, for example:
> >   
> >   - pmix: https://cbs.centos.org/koji/buildinfo?buildID=50809 built on Sep 15 2023 addressing 
> > https://nvd.nist.gov/vuln/detail/CVE-2023-41915 from Sep 9 2023 (commit pushed for c9s on Nov 2 2023 - 
> > https://gitlab.com/redhat/centos-stream/rpms/pmix/-/commit/d674de0cb5d716940f01e937f2a7bb79fbd81f5c)
> >   - openssh: https://cbs.centos.org/koji/buildinfo?buildID=54523 built on Jul 2 2024 addressing CVE-2024-6387 from 
> > Jul 1 2024 (fixed in Stream Jul 4)
> >
> > 4. 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?)
> >
> > Our user base uses CentOS Stream in production, while the upstream project mostly uses it for integrating changes 
> > into upcoming RHEL releases; as such we not only ship newer packages (e.g. kernel, systemd, qemu) with features not 
> > enabled in CentOS Stream and RHEL (e.g. Btrfs) but we also need to patch security issues faster, given Stream 
> > receives urgent security fixes only after they are released for RHEL.
> >
> > See examples in previous points for some issues we fixed independently of upstream distro - as we ship more 
> > packages in the future to support more use cases, the need to release security fixes faster will only grow.
> >
> > 5. Be a participant and preferably an active contributor in relevant public communities (most notably, if you're 
> > not watching for issues being made public on oss-security, which are a superset of those that had been handled on 
> > (linux-)distros, then there's no valid reason for you to be on (linux-)distros)
> >
> > We are individually members of oss-security, in addition to various distribution development lists
> >
> > 6. Accept the list policy (see above)
> >
> > accepted
> >
> > 7. Be able and willing to contribute back (see above), preferably in specific ways announced in advance (so that 
> > you're responsible for a specific area and so that we know what to expect from which member), and demonstrate 
> > actual contributions once you've been a member for a while
> >
> > The three of us handle security related issues, with Neal Gompa focusing on issues related to release engineering, 
> > and Davide and I on updates in general especially those that are built with specific customizations.
> >
> > 8. Be able and willing to handle PGP-encrypted e-mail
> >
> > We are able and willing
> >
> > 9. Have someone already on the private list, or at least someone else who has been active on oss-security for years 
> > but is not affiliated with your distro nor your organization, vouch for at least one of the people requesting 
> > membership on behalf of your distro (then that one vouched-for person will be able to vouch for others on your 
> > team, in case you'd like multiple people subscribed)
> >
> > Jonathan Wright from AlmaLinux can vouch for us
> >
> > Best regards,
> >
> > -- 
> >  _o) Michel Lind
> > _( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2
>
> I know that at least Neal Gompa is also a Fedora developer.  Would it
> be permissible for him to also handle security patches for Fedora, if
> Fedora is also affected?
> -- 
> Sincerely,
> Demi Marie Obenour (she/her/hers)
> Invisible Things Lab

Hi,

I am curious what this could mean for Fedora Asahi Remix [0], as the
applicants maintain both distros.

Is there interest in the Asahi SIG applying as well?

I heartily endorse the applicants membership request and appreciate
their work. Hooray for ARM \o/

Mark Esler

n.b. to clarify scopes: Asahi Linux [1] is an upstream to Fedora Asahi
Remix. Asahi Linux has partnered with and has members in the Asahi SIG
[2] to make Fedora Asahi Remix the flagship Asahi distro [3].

[0] https://fedora-asahi-remix.org/
[1] https://asahilinux.org/
[2] https://fedoraproject.org/wiki/SIGs/Asahi
[3] https://asahilinux.org/2023/08/fedora-asahi-remix/

Attachment: signature.asc
Description: