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

[Neil Hanlon <neil () shrug pw>]

On 10.07.2024 11:23, 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.

Indeed, the Hyperscale SIG applies patches and versions of software that
have a different support and feature scope compared to CentOS Stream
Linux. Combined with its significant user base and existing strategy for
managing public vulnerabilities, it indicates that handling embargoed
releases would be managed professionally.

> 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

Although I am not a frequent contributor to the oss-security list nor a
member of the distros list, I am happy to vouch for Michel, Davide, and
Neal. All three are respected members of various open source
communities. In my experience over the past few years, they have shown a
strong commitment to ensuring timely, secure updates across the Linux
ecosystem. I have no reservations about their inclusion in these lists,
especially considering their involvement in Fedora.

> Best regards,
>
> --
> _o) Michel Lind
> _( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2

Attachment: signature.asc
Description: