This change: https://almalinux.org/blog/future-of-almalinux/ means that Alma is no longer covered by STIGs and other RHEL-specific certifications. Rocky is usually permitted to piggyback on such things. This has directly affected deployments (my team spent time migrating from one o the other as a direct consequence). Compatible, sure, but that is a narrow view of the value CentOS provided.
I cannot speak for AlmaLinux, but it's incorrect to say they're not compatible. They are most definitely still compatible with the upstream distributions. Yes, they have made some changes that make them quite different from the upstreams, but this was their choice and it works for their community and their overall goals. I personally don't see any issues with what they've chosen to do, but that's my extremely narrow view as all clients I work for only use RHEL or Ubuntu.
In regards to STIG, this makes me think of the "scap-security-guide" package that helps the openscap package run tests for compliance like PCI-DSS and HIPPA (among other things). While it is true that we mark ourselves as a "derivative" of RHEL in that package, it doesn't mean we have any certifications or the like and we certainly do not claim to have such certifications. The only thing we actually have officially is a CIS benchmark set at cisecurity.org.
AlmaLinux on the other hand appears to be upstreaming themselves into the content itself, which I think is pretty cool (https://github.com/ComplianceAsCode/content/tree/master/prod...). I've always wanted to see Rocky Linux do the same thing for the past few years, but I don't know what it would take. I've asked our security team some weeks back to look into what has to be done, so maybe something will happen. I just know it will take a long, long time to get things figured out either way. (As much as I'd like to look into it myself and work with the security team, I just don't have the time in between my personal life, day job, and the project.)
STIGs are not inherited. It absolutely does not work that way.
I think you're reading into the changes completely wrong. AlmaLinux has power to actually do things, fix issues, contribute real and meaningful changes, all while maintaining 100% compatibility. A lot has been done already, with plenty more to come, with 0 compatibility issues.
stonogo|11 months ago
nazunalika|11 months ago
In regards to STIG, this makes me think of the "scap-security-guide" package that helps the openscap package run tests for compliance like PCI-DSS and HIPPA (among other things). While it is true that we mark ourselves as a "derivative" of RHEL in that package, it doesn't mean we have any certifications or the like and we certainly do not claim to have such certifications. The only thing we actually have officially is a CIS benchmark set at cisecurity.org.
AlmaLinux on the other hand appears to be upstreaming themselves into the content itself, which I think is pretty cool (https://github.com/ComplianceAsCode/content/tree/master/prod...). I've always wanted to see Rocky Linux do the same thing for the past few years, but I don't know what it would take. I've asked our security team some weeks back to look into what has to be done, so maybe something will happen. I just know it will take a long, long time to get things figured out either way. (As much as I'd like to look into it myself and work with the security team, I just don't have the time in between my personal life, day job, and the project.)
jonathanspw|11 months ago
I think you're reading into the changes completely wrong. AlmaLinux has power to actually do things, fix issues, contribute real and meaningful changes, all while maintaining 100% compatibility. A lot has been done already, with plenty more to come, with 0 compatibility issues.