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