centos-stream VS homebrew-core

In an unexpected and surprising move, contrary to what Red Hat has been saying lately to the community about CentOS Stream collaboration and rebuilders, Red Hat will refuse patches to CVE issues, developed by downstream contributors, in CentOS Stream citing "no customer demand".

Link to CentOS Stream Gitlab of the AlmaLinux CVE patch commit: https://gitlab.com/redhat/centos-stream/rpms/iperf3/-/merge_requests/5

Discussion going on Reddit: https://www.reddit.com/r/AlmaLinux/comments/1544w8b/red_hat_refuses_almas_cve_patches_to_centos/

The source RHEL is built from can be found here with absolutely no restrictions: https://gitlab.com/redhat/centos-stream

https://gitlab.com/redhat/centos-stream/src/kernel/centos-st...

Fedora and many other distros do a lot of valued work, too.

FWICS there are FIPS kernel variants for Ubuntu <= 20.04 LTS (2020) but not 22.04 LTS (2022), and Debian and Ubuntu don't have the selinux policy set that Fedora and RHEL+EPEL have. https://ubuntu.com/kernel

From https://news.ycombinator.com/item?id=36480033 :

> Would it be feasible to sed-replace the RHEL and/or Fedora selinux and container-selinux rulesets for use with other Linux distros?

> "AFAIU only SUSE can run both AppArmor and SELinux?*

> And browsers are running as unconfined in selinux with like all major distros; even on ChromiumOS

Act like you added `systemd-nspawn respawn` to every SysV-init script and correctly formatted the epoch time in the correct column of each of the log files to merge and then logship again.

There is nothing stopping any of the rebuilders from using gitlab.com/redhat/centos-stream to continue rebuilding.

Is "284.18 1" the commit that gets you the kernel version 5.14.0-284.18.1 ?

$ brew info eza ==> eza: stable 0.18.13 (bottled) Modern, maintained replacement for ls https://github.com/eza-community/eza Not installed From: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/e/eza.rb License: MIT ==> Dependencies Build: pandoc ✘, pkg-config ✔, rust ✘ Required: libgit2 ✘ ==> Analytics install: 12,792 (30 days), 38,295 (90 days), 68,375 (365 days) install-on-request: 12,790 (30 days), 38,293 (90 days), 68,375 (365 days) build-error: 0 (30 days)

Is disabling the compromised repo the typical GitHub policy? My concern is there are monorepos used by package managers, like brew, that are a collection of thousands of projects [1]. These monorepos seem like a prime target for attack and if GitHub disables one because a malicious commit was merged then you've taken down an entire ecosystem.

[1] https://github.com/Homebrew/homebrew-core

> Correct. Though we do not appear to be affected, this revert was done out of an abundance of caution.

[1] https://github.com/Homebrew/homebrew-core/pull/167512

> right, but now you know even less about your setup when you some roadblock

This is the same with a binary though. And with homebrew, you can't follow patches or flags used or if they change.

- https://github.com/Homebrew/homebrew-core/blob/c964ad7fa53ad...

definitely be careful about using fortune in a corporate environment or public space if you don't know what dat files you are using or you might just get an extremely unwelcome surprise.

I was practicing a presentation and used to use "fortune" all the time. I forget exactly what it output but I remember being absolutely mortified about what could have happened if that had popped up during an internal company tech talk.

Kudos to brew for keeping unsuspecting people safe

https://github.com/Homebrew/homebrew-core/commit/3fb3c4c3e55...

I'm sorry to be asking this as I find it a bit silly, but it's blocking my PR [3], so could a few of you star the project on Github [1] to get my PR to run?

[1] https://github.com/laktak/chkbit-py

[2] https://brew.sh

[3] https://github.com/Homebrew/homebrew-core/pull/160018