8 ms·

What if instead of publicly blaming an OSS product, you try to get a support contract with some of the engineers behind it? If your company is too cheap for tha

What if instead of publicly blaming an OSS product, you try to get a support contract with some of the engineers behind it? If your company is too cheap for that, maybe a PR would have been nice? Having very high expectations when using the software without contributing anything else than public shaming on something that clearly state in the license: "Licensor provides the Work ... WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND" shouldn't be ok, this is quite literally how you make open source developer to burn out

some_furry 2y ago
> What if instead of publicly blaming an OSS product, you try to get a support contract with some of the engineers behind it? If your company is too cheap for that, maybe a PR would have been nice? Yeah, no. That's not how security research works. If I disclose a security issue to you, it doesn't matter if you're a multinational trillion dollar corporation or a hobbyist in Nebraska, the onus is on you to fix it. Not the security researcher. Their job is done once it's disclosed. From the timeline: > 28/03/2024 – First communication sent with all details and a proposed fix. After that point, any additional help (including a pull request) is going above and beyond. I run into this attitude you're exhibiting a lot. Where proprietary software has the legal threats, the open source community is plagued by patch entitlement. Knowledge of a security issue in a project is, in and of itself, a valuable contribution. Expecting a PR devalues this work.
- noselasd 2y ago
  > If I disclose a security issue to you, it doesn't matter if you're a multinational trillion dollar corporation or a hobbyist in Nebraska, the onus is on you to fix it. Not the security researcher. Their job is done once it's disclosed. On the other hand, if I'm a hobbyist, I have 0 obligations to do or fix anything I've made open source. Patches are welcome ofcourse.
  - deleted 2y ago
    [deleted]
  - ziddoap 2y ago
    >I have 0 obligations to do or fix anything I've made open source. While technically true, this seems pretty scummy when you're advertising security software for real people and companies to use as their identity management. Nowhere on the Keycloak home page does it say "just a hobby project" or anything that would remotely indicate that it is not a serious project and that you shouldn't use the software. Instead, it seems like they are trying very hard to be taken seriously as an identity management product.
    - flanked-evergl 2y ago
      > Nowhere on the Keycloak home page does it say "just a hobby project" or anything that would remotely indicate that it is not a serious project and that you shouldn't use the software. https://github.com/keycloak/keycloak/blob/main/LICENSE.txt#L144-L175 https://github.com/keycloak/keycloak/blob/main/LICENSE.txt#L... Indeed 7. Disclaimer of Warranty. Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License.
      - ziddoap 2y ago
        Point 7 buried in the license document of the github repository is very much not https://www.keycloak.org/ https://www.keycloak.org/
        willcipriano 2y ago
        Customers have been refunded in full.
        mardifoufs 2y ago
  - marcosdumay 2y ago
    As long as you disclose that right-front on your value statement, yeah, you don't have any other obligation.
    - Macha 2y ago
      Is there an open source license that doesn't?
    - vetinari 2y ago
      It is right in the license.
      - KajMagnus 2y ago
        That's not what these licenses have come to mean. They're a way to reduce the risk that you'll get sued, but not any "I don't give a fuck" statement. You could add "I don't care about fixing security vulnerabilities" somewhere in the beginning of the readme, if you're developing security related OSS software? That'd be more clear. Maybe the WTFPL actually a little bit indicates that the developers maybe don't give a fuck, though: https://en.wikipedia.org/wiki/WTFPL https://en.wikipedia.org/wiki/WTFPL ?
        kube-system 2y ago
        That sounds a little like having your cake and eating it too. 'Giving a fuck' is not really a boolean value but more of a broad spectrum. Of course, anyone who writes any software cared a little bit about it at one point, or they wouldn't have written it. But warranty is about whether they care enough to cater specifically to you when you have a problem in the future. Maybe many of these projects do care enough to give general updates to the community as a whole on a best effort basis, but that's a lower level of assurance and more voluntary than what you'd get in a legal warranty.
        hifromwork 2y ago
        >You could add "I don't care about fixing security vulnerabilities" somewhere in the beginning of the readme I care about fixing security vulnerabilities in my OS projects, but I care more about my sanity, my family, getting enough money to survive, and a few other things. Unless you pay me I don't care about your problems with my free (as in a beer) software. And that's a good thing btw - I tried to ask for donations once, got the equivalent of a few cups of coffee per month, and... burned out almost immediately. I started to feel responsible for that project, staying up late to fix reported minor bugs, and it turns out watching Github issues 365 days a year for a few dollars monthly is not a great business strategy.
  - hinkley 2y ago
    Then you should never work on software with security implications, or if you do you should keep it to yourself. I’m a terrible party host, so I don’t host parties. I help other people do so when I can.
  - thunky 2y ago
    And you also shouldn't expect anyone to use your software. Which of course is up to you.
- rcxdude 2y ago
  There's no obligation for a hobbyist to fix the stuff they publish online. If they're selling the result, then sure, you can argue there's reasonable consideration, but just because a security researcher has made a contribution (and a valuable one) it doesn't compel any further contribution from the original author. Now, the lack of action does probably remove some of the credibility of the project as one that should be used in any security context (bit of a problem for something intended to be used as authentication).
  - some_furry 2y ago
    > There's no obligation for a hobbyist to fix the stuff they publish online. Correct, but I didn't say there was. The onus being on them to fix it is predicated on anyone having such an obligation at all. If anyone has an obligation, it's always the vendor, not the researcher. But keep in mind this situation involves an IBM-funded open source project under the Red Hat product line. The hobbyist remark is tangential to the story.
  - prmoustache 2y ago
    > There's no obligation for a hobbyist to fix the stuff they publish online. I may be wrong but this might not the case anymore in 2025 (not sure about the timeline) in the European Union because of the new cybersecurity acts.
    - some_furry 2y ago
      I don't have a business presence in the EU, so I rarely care about that for my own projects. (Insofar as I do care, it's limited to "let's not make GDPR compliance logically impossible when designing cryptographic features").
    - rcxdude 2y ago
      There's carve-outs in that for open source hobbyists ("not associated with commercial activity"). This was originally vaguely worded but they've now made it a lot less ambiguous, the only open source it covers is that which is being developed by a company which is also making money directly from it. (And in the case that a company takes that code and uses it in a product, they are responsible to fix any security vulnerabilities but also to report it to the author)
hypeatei 2y ago
Money doesn't guarantee anything, as seen by the recent issue with Okta. If you're using a centralized auth service and expecting no vulns or exploits, you're going to be severely disappointed. These are the juiciest targets and very complex pieces of software. I don't see an issue with calling out this Keycloak response time either. It's not inherently negative, just stating facts.
- debarshri 2y ago
  If you central auth - you have vulnerabilities If you decentralize auth - you have vulnerabilities. It can lead to shadow credentials as well as credential and auth sprawl. It is about de-risking your approach. Either approaches work until they don't.
deleted 2y ago
[deleted]
tapoxi 2y ago
Keycloak is a Red Hat product and is a dependency for many Red Hat products so I'd love it if people running the open source release can report the bug and get feedback. This isn't a student eating ramen supporting this software, its IBM.
- 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
aseipp 2y ago
Keycloak is not written by some random person in the middle of nowhere who is shouldering the burdens of the world. It is security sensitive software that in part is funded by major open-source corporations like Red Hat, including full time engineers. What you're reading in this blog is literally standard fare in security research where a disclosure happens after some set period of time, regardless of when, or even if, the fix happened. Fixing authentication bypasses is not "very high expectations", it's exactly what you would expect from this software. Get a grip on reality, please.
- threatofrain 2y ago
  Is it still funded by Red Hat today?
  - aseipp 2y ago
    Several developers and full-time employees, including the project lead, are still employed by Red Hat.
tgsovlerkhgsel 2y ago
Regardless of whether it's a project run by a big company or a guy in a shed, a security-critical project not fixing critical vulns for 10 months is an important bit of information when judging whether you should use it. It doesn't really matter whether it's someone's fault, or wrong, or whatever - what matters for the user is that using the project is likely unsafe. Sharing that information is a public service.
- hinkley 2y ago
  The number of software engineers who either don’t understand social contracts or only understand them when it benefits them to do so is frankly appalling. You said you’re going to do something and now people depend on you having done it. Volunteer organizations fall apart if they can’t trust each other.
  - from-nibly 2y ago
    People depending on you is not somethng in your control, therefore you can't be responsible for that. It's up to the people depending on you to make a judgement on whether or not that's a good idea. Social contracts are not contracts, they do not end up in court, and if you depend on them you have no recourse. The most anyone can say about social contracts is that you are allowed to be disappointed privately. And even then...
    - hinkley 2y ago
      No, they end up in the court of public opinion. <gestures around> And they make you lonely if you keep losing.
  - water-data-dude 2y ago
    This blog post is from another domain, writing, but it’s stuck with me over the years and colored how I see things like open source projects: https://journal.neilgaiman.com/2009/05/entitlement-issues.html https://journal.neilgaiman.com/2009/05/entitlement-issues.ht...
- 2y ago
its-summertime 2y ago
> maybe a PR would have been nice? They did. > 28/03/2024 – First communication sent with all details and a proposed fix. And for the second one, a fix existed 2 days after first communication, doing a PR doesn't magically make that go faster. For the third, a fix was done within a month, but once again was delayed, and didn't land until several months later. - - - RH does not provide support contracts for any affordable price. CNCF does not provide support contracts at all.
- hinkley 2y ago
  That was a very articulate and nice way of saying, “what if instead of using the tired old deflection you looked at the facts?”

some_furry 2y ago

> What if instead of publicly blaming an OSS product, you try to get a support contract with some of the engineers behind it? If your company is too cheap for that, maybe a PR would have been nice? Yeah, no. That's not how security research works. If I disclose a security issue to you, it doesn't matter if you're a multinational trillion dollar corporation or a hobbyist in Nebraska, the onus is on you to fix it. Not the security researcher. Their job is done once it's disclosed. From the timeline: > 28/03/2024 – First communication sent with all details and a proposed fix. After that point, any additional help (including a pull request) is going above and beyond. I run into this attitude you're exhibiting a lot. Where proprietary software has the legal threats, the open source community is plagued by patch entitlement. Knowledge of a security issue in a project is, in and of itself, a valuable contribution. Expecting a PR devalues this work.

noselasd 2y ago
> If I disclose a security issue to you, it doesn't matter if you're a multinational trillion dollar corporation or a hobbyist in Nebraska, the onus is on you to fix it. Not the security researcher. Their job is done once it's disclosed. On the other hand, if I'm a hobbyist, I have 0 obligations to do or fix anything I've made open source. Patches are welcome ofcourse.
- deleted 2y ago
  [deleted]
- ziddoap 2y ago
  >I have 0 obligations to do or fix anything I've made open source. While technically true, this seems pretty scummy when you're advertising security software for real people and companies to use as their identity management. Nowhere on the Keycloak home page does it say "just a hobby project" or anything that would remotely indicate that it is not a serious project and that you shouldn't use the software. Instead, it seems like they are trying very hard to be taken seriously as an identity management product.
  - flanked-evergl 2y ago
    > Nowhere on the Keycloak home page does it say "just a hobby project" or anything that would remotely indicate that it is not a serious project and that you shouldn't use the software. https://github.com/keycloak/keycloak/blob/main/LICENSE.txt#L144-L175 https://github.com/keycloak/keycloak/blob/main/LICENSE.txt#L... Indeed 7. Disclaimer of Warranty. Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License.
    - ziddoap 2y ago
      Point 7 buried in the license document of the github repository is very much not https://www.keycloak.org/ https://www.keycloak.org/
      - willcipriano 2y ago
        Customers have been refunded in full.
        mardifoufs 2y ago
- marcosdumay 2y ago
  As long as you disclose that right-front on your value statement, yeah, you don't have any other obligation.
  - Macha 2y ago
    Is there an open source license that doesn't?
  - vetinari 2y ago
    It is right in the license.
    - KajMagnus 2y ago
      That's not what these licenses have come to mean. They're a way to reduce the risk that you'll get sued, but not any "I don't give a fuck" statement. You could add "I don't care about fixing security vulnerabilities" somewhere in the beginning of the readme, if you're developing security related OSS software? That'd be more clear. Maybe the WTFPL actually a little bit indicates that the developers maybe don't give a fuck, though: https://en.wikipedia.org/wiki/WTFPL https://en.wikipedia.org/wiki/WTFPL ?
      - kube-system 2y ago
        That sounds a little like having your cake and eating it too. 'Giving a fuck' is not really a boolean value but more of a broad spectrum. Of course, anyone who writes any software cared a little bit about it at one point, or they wouldn't have written it. But warranty is about whether they care enough to cater specifically to you when you have a problem in the future. Maybe many of these projects do care enough to give general updates to the community as a whole on a best effort basis, but that's a lower level of assurance and more voluntary than what you'd get in a legal warranty.
      - hifromwork 2y ago
        >You could add "I don't care about fixing security vulnerabilities" somewhere in the beginning of the readme I care about fixing security vulnerabilities in my OS projects, but I care more about my sanity, my family, getting enough money to survive, and a few other things. Unless you pay me I don't care about your problems with my free (as in a beer) software. And that's a good thing btw - I tried to ask for donations once, got the equivalent of a few cups of coffee per month, and... burned out almost immediately. I started to feel responsible for that project, staying up late to fix reported minor bugs, and it turns out watching Github issues 365 days a year for a few dollars monthly is not a great business strategy.
- hinkley 2y ago
  Then you should never work on software with security implications, or if you do you should keep it to yourself. I’m a terrible party host, so I don’t host parties. I help other people do so when I can.
- thunky 2y ago
  And you also shouldn't expect anyone to use your software. Which of course is up to you.
rcxdude 2y ago
There's no obligation for a hobbyist to fix the stuff they publish online. If they're selling the result, then sure, you can argue there's reasonable consideration, but just because a security researcher has made a contribution (and a valuable one) it doesn't compel any further contribution from the original author. Now, the lack of action does probably remove some of the credibility of the project as one that should be used in any security context (bit of a problem for something intended to be used as authentication).
- some_furry 2y ago
  > There's no obligation for a hobbyist to fix the stuff they publish online. Correct, but I didn't say there was. The onus being on them to fix it is predicated on anyone having such an obligation at all. If anyone has an obligation, it's always the vendor, not the researcher. But keep in mind this situation involves an IBM-funded open source project under the Red Hat product line. The hobbyist remark is tangential to the story.
- prmoustache 2y ago
  > There's no obligation for a hobbyist to fix the stuff they publish online. I may be wrong but this might not the case anymore in 2025 (not sure about the timeline) in the European Union because of the new cybersecurity acts.
  - some_furry 2y ago
    I don't have a business presence in the EU, so I rarely care about that for my own projects. (Insofar as I do care, it's limited to "let's not make GDPR compliance logically impossible when designing cryptographic features").
  - rcxdude 2y ago
    There's carve-outs in that for open source hobbyists ("not associated with commercial activity"). This was originally vaguely worded but they've now made it a lot less ambiguous, the only open source it covers is that which is being developed by a company which is also making money directly from it. (And in the case that a company takes that code and uses it in a product, they are responsible to fix any security vulnerabilities but also to report it to the author)

hypeatei 2y ago

Money doesn't guarantee anything, as seen by the recent issue with Okta. If you're using a centralized auth service and expecting no vulns or exploits, you're going to be severely disappointed. These are the juiciest targets and very complex pieces of software. I don't see an issue with calling out this Keycloak response time either. It's not inherently negative, just stating facts.

debarshri 2y ago
If you central auth - you have vulnerabilities If you decentralize auth - you have vulnerabilities. It can lead to shadow credentials as well as credential and auth sprawl. It is about de-risking your approach. Either approaches work until they don't.

deleted 2y ago

[deleted]

tapoxi 2y ago

Keycloak is a Red Hat product and is a dependency for many Red Hat products so I'd love it if people running the open source release can report the bug and get feedback. This isn't a student eating ramen supporting this software, its IBM.

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

aseipp 2y ago

Keycloak is not written by some random person in the middle of nowhere who is shouldering the burdens of the world. It is security sensitive software that in part is funded by major open-source corporations like Red Hat, including full time engineers. What you're reading in this blog is literally standard fare in security research where a disclosure happens after some set period of time, regardless of when, or even if, the fix happened. Fixing authentication bypasses is not "very high expectations", it's exactly what you would expect from this software. Get a grip on reality, please.

threatofrain 2y ago
Is it still funded by Red Hat today?
- aseipp 2y ago
  Several developers and full-time employees, including the project lead, are still employed by Red Hat.

tgsovlerkhgsel 2y ago

Regardless of whether it's a project run by a big company or a guy in a shed, a security-critical project not fixing critical vulns for 10 months is an important bit of information when judging whether you should use it. It doesn't really matter whether it's someone's fault, or wrong, or whatever - what matters for the user is that using the project is likely unsafe. Sharing that information is a public service.

hinkley 2y ago
The number of software engineers who either don’t understand social contracts or only understand them when it benefits them to do so is frankly appalling. You said you’re going to do something and now people depend on you having done it. Volunteer organizations fall apart if they can’t trust each other.
- from-nibly 2y ago
  People depending on you is not somethng in your control, therefore you can't be responsible for that. It's up to the people depending on you to make a judgement on whether or not that's a good idea. Social contracts are not contracts, they do not end up in court, and if you depend on them you have no recourse. The most anyone can say about social contracts is that you are allowed to be disappointed privately. And even then...
  - hinkley 2y ago
    No, they end up in the court of public opinion. <gestures around> And they make you lonely if you keep losing.
- water-data-dude 2y ago
  This blog post is from another domain, writing, but it’s stuck with me over the years and colored how I see things like open source projects: https://journal.neilgaiman.com/2009/05/entitlement-issues.html https://journal.neilgaiman.com/2009/05/entitlement-issues.ht...
2y ago

its-summertime 2y ago

> maybe a PR would have been nice? They did. > 28/03/2024 – First communication sent with all details and a proposed fix. And for the second one, a fix existed 2 days after first communication, doing a PR doesn't magically make that go faster. For the third, a fix was done within a month, but once again was delayed, and didn't land until several months later. - - - RH does not provide support contracts for any affordable price. CNCF does not provide support contracts at all.

hinkley 2y ago
That was a very articulate and nice way of saying, “what if instead of using the tired old deflection you looked at the facts?”