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
signature.asc
Description: PGP signature
