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