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

Attachment: signature.asc
Description: PGP signature

Reply via email to