Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 10 Jul 2024 16:15:33 -0500
From: Mark Esler <mark.esler@...onical.com>
To: oss-security@...ts.openwall.com
Subject: Re: linux-distros application for CentOS Project's
 Hyperscale SIG

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/

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.