© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
bbfa235
(Get the code!)
> It looks like the proposed patches don't actually engage the security protection they introduce, requiring an admin to make a policy configuration change before their environment will be protected from the issue described here. Am I interpreting that accurately, or misreading?
That is correct and intentional so that we don't introduce backward incompatible API behavior by default. This would land in Rocky with a backward compatible setting, and then in Stein we'll update the default policy rule to be admin-only, but it at least gives operators time to adjust to the change.
Looking at the Class B1 description:
"A vulnerability that can only be fixed in master, security note for stable branches, e.g., default config value is insecure"
The "default config value is insecure" is true, but the "can only be fixed in master" is not really true, since we can backport a fix for this, it's just not enabled by default. Maybe I'm reading too much into the intent of B1 though.
If a B1 classification means that vendors don't have to try and patch this all the way back to its origin release, then that's probably not a bad thing since it looks like this goes back to at least Diablo:
https:/