The Security SIG repositories provide extra security-related packages and security-hardened override packages (replacing those from the main distribution) for Rocky Linux and other Enterprise Linux (EL) distributions.
Developing and maintaining various security related packages that are not in upstream EL. Identifying, developing, and maintaining security hardening changes relative to upstream EL packages. Occasionally including/backporting additional security fixes that are not yet in upstream EL packages. Contributing to the respective upstreams where practical.
Download the release package containing our repository configuration file and package signing public key. Use the version that corresponds to the major version of your EL distro.
This isn't as secure as checking the package signature would be _if_ you previously had our package signing public key, but on another distro you probably don't have that yet, so checking the digest against its copy obtained from this separate website is a best-effort measure.
Install the package with `rpm -U --nodeps`. The `--nodeps` option is needed to bypass the dependency check on our `rocky-release` package. In essense, you're manually confirming to `rpm` that you're installing on a compatible distro.
You'll normally install packages from the mirrors, which should just work. However, if there's any issue with the mirrors and you uncomment our `baseurl` line instead, then on non-Rocky you'll need to use `DNF_VAR_sigcontentdir=/pub/sig dnf` in place of simply `dnf`.
- [hardened_malloc](packages/hardened_malloc.md) (Security-focused memory allocator providing the malloc API, and a script to preload it into existing program binaries)
- [microcode_ctl](packages/microcode_ctl.md) (updates Intel CPU microcode to microcode-20231114, which fixes [CVE-2023-23583](issues/CVE-2023-23583.md))
Just like for other Rocky Linux SIGs, the source trees for Security SIG packages are maintained in [per-package git repositories](https://git.rockylinux.org/sig/security/src). Each repository contains branches `r8` and/or `r9` corresponding to target EL version.
If anyone else wants to join this effort - in any capacity including development, maintenance, testing, documentation, user support, spreading the word, or something else - please join the Mattermost channel below and let us know!
We also welcome well-reasoned suggestions/feedback/preferences on direction we should take (e.g., only making changes on top of EL's vs. offering newer upstream versions), what else to package, and what other changes to include.
