3 ms·

Keycloak has been donated to CNCF in 2023. So it's not a RH / IBM product anymore. I would even go as far as say that it never was; Red Hat had their own produ

by hiciu 2y ago

Keycloak has been donated to CNCF in 2023. So it's not a RH / IBM product anymore. I would even go as far as say that it never was; Red Hat had their own product called "Red Hat Single Sign On" that was, for some time, based on opensource Keycloak project, but the opensource Keycloak project has existed before RH SSO. And exists now that RH SSO product has been deprecated (retired? Idk what happened). Red Hat does offer a "Red Hat build of Keycloak" now, and of course Keycloak would not exists in it's current form without Red Hat. But saying that "Keycloak is a Red Hat product and therefore Red Hat and / or IBM should support it" would be, in my opinion, harmful for the whole opensource movement. If, by being engaged with opensource project, a company risks it's reputation then such company could decide against any engagement, or would engage only if it could keep control of the project / community around it.

tapoxi 2y ago
If there's a Red Hat build of Keycloak, and Red Hat products depend on Keycloak, then this vulnerability is present in all of those Red Hat products.
- TheNewsIsHere 2y ago
  Not necessarily. Red Hat issues patches and backports to customers regularly and those don’t necessarily flow upstream right away (or sometimes ever).
ffsm8 2y ago
RH SSO was the LTS build of keycloak with business support. Keycloak doesn't publish hot fixes for previous major versions, and these major versions come out on a very tight release schedule / every few months. So if you didn't want to upgrade all the time, you'd have been forced to use rhsso. And now the red hat keycloak build. https://github.com/keycloak/keycloak/discussions/25688 https://github.com/keycloak/keycloak/discussions/25688
- vbezhenar 2y ago
  > So if you didn't want to upgrade all the time, you'd have been forced to use rhsso. Or just not upgrade at all. Not the most wise strategy for security-focused software, but I'm sure many teams do that. Especially because keycloak often being heavily customized with plugins and themes, so upgrading this setup might actually be not trivial.
tofflos 2y ago
Off-topic but I love this naming convention from Red Hat which I hope gets more traction across the industry. It absolutely detest wading through vendor marketing material to figure out which open source product is being used under the hood. With names like "Red Hat Build of Keycloak" and "Microsoft Build of OpenJDK" it's crystal clear. I believe it works out better for the vendors as well because there are so many obstacles with evaluating anything that requires a license in an enterprise setting. If the technical person downloads and evaluates the underlying open source version some manager will insist on purchasing a support contract before going to production.
- bigfatkitten 2y ago
  Though Red Hat did a search and replace for RHSSO with "Red Hat Build of Keycloak" in their docs, and now they are extremely painful to read with Red Hat Build of Keycloak sometimes appearing three times in one sentence when "Keycloak" or some other shortened form would suffice.

by hiciu 2y ago

tapoxi 2y ago

If there's a Red Hat build of Keycloak, and Red Hat products depend on Keycloak, then this vulnerability is present in all of those Red Hat products.

TheNewsIsHere 2y ago
Not necessarily. Red Hat issues patches and backports to customers regularly and those don’t necessarily flow upstream right away (or sometimes ever).

ffsm8 2y ago

RH SSO was the LTS build of keycloak with business support. Keycloak doesn't publish hot fixes for previous major versions, and these major versions come out on a very tight release schedule / every few months. So if you didn't want to upgrade all the time, you'd have been forced to use rhsso. And now the red hat keycloak build. https://github.com/keycloak/keycloak/discussions/25688 https://github.com/keycloak/keycloak/discussions/25688

vbezhenar 2y ago
> So if you didn't want to upgrade all the time, you'd have been forced to use rhsso. Or just not upgrade at all. Not the most wise strategy for security-focused software, but I'm sure many teams do that. Especially because keycloak often being heavily customized with plugins and themes, so upgrading this setup might actually be not trivial.

tofflos 2y ago

Off-topic but I love this naming convention from Red Hat which I hope gets more traction across the industry. It absolutely detest wading through vendor marketing material to figure out which open source product is being used under the hood. With names like "Red Hat Build of Keycloak" and "Microsoft Build of OpenJDK" it's crystal clear. I believe it works out better for the vendors as well because there are so many obstacles with evaluating anything that requires a license in an enterprise setting. If the technical person downloads and evaluates the underlying open source version some manager will insist on purchasing a support contract before going to production.

bigfatkitten 2y ago
Though Red Hat did a search and replace for RHSSO with "Red Hat Build of Keycloak" in their docs, and now they are extremely painful to read with Red Hat Build of Keycloak sometimes appearing three times in one sentence when "Keycloak" or some other shortened form would suffice.