4 ms·

> Isn't that what we want, though? Generally. But on the other hand, no, this isn't a monoculture, where everyone wants the same exact thing. > Discussion and

> Isn't that what we want, though? Generally. But on the other hand, no, this isn't a monoculture, where everyone wants the same exact thing. > Discussion and review, particularly with the people who are most familiar with the project (the maintainers) is what makes software better, not worse. Tell that to vim: https://github.com/vim/vim/issues/638 https://github.com/vim/vim/issues/638 Tell that to node.js: https://github.com/nodejs/node/issues/5798 https://github.com/nodejs/node/issues/5798 Tell that to WordPress: https://core.trac.wordpress.org/ticket/21022 https://core.trac.wordpress.org/ticket/21022 https://core.trac.wordpress.org/ticket/25052 https://core.trac.wordpress.org/ticket/25052 etc. Despite all of the time that industry experts have contributed towards identifying and discussing security problems, these projects have severe inertia in the security realm. How much more time do you want us to carve out of our lives for projects that won't fix their problems? > If you're not willing to do that then why comment on issues you find in open source projects at all, other than to stroke your own ego? I don't like the way this is framed. It's a hidden false dichotomy.

iamatworknow 10y ago
I don't disagree with your or joepie91_'s points in that many (maybe most) open source project maintainers are perhaps more guarded and difficult in accepting contributions than they should be. That said, even if you submit a pull request or an issue ticket and the maintainer doesn't follow up, or is making the issue unnecessarily complicated to resolve formally and merge into the main branch, at least the record of your findings is there attached to the repo as a rejected pull request or a closed issue ticket, and that can help someone who comes along after the fact who maybe experienced the same issue you did and can benefit from your comments. Maybe that same person who comes along later will have the time to fight for having the changes merged, and can use your comments as further evidence that the issue is worth reconsidering. I stand by the idea that finding the issue, but posting it on an unrelated forum (like HN) instead of attaching it to the project itself serves no purpose than to tell others who are probably not even users of the open source code "look at this problem I found/solved, aren't I great?"
- CiPHPerCoder 10y ago
  In this case: I did, and it was immediately closed without any change to the code, documentation, process, or culture.
  - iamatworknow 10y ago
    I'd say you did your due diligence then.
  - Alupis 10y ago
    > In this case: I did, and it was immediately closed without any change to the code, documentation, process, or culture. You left out the part where they told you this perceived issue did not impact their codebase, due to how they were using the upstream project you cited.[1] > While this is an issue it does not affect us as we aren't using session cookies with slim You then started to rant about how they don't update their dependencies "quick enough". [1] https://github.com/samilliken/openDCIM/issues/837 https://github.com/samilliken/openDCIM/issues/837
    - joepie91_ 10y ago
      > You left out the part where they told you this perceived issue did not impact their codebase, due to how they were using the upstream project you cited. This is completely irrelevant. Vulnerable dependencies are vulnerable dependencies, and trying to avoid updates because you're "not affected" is a really good way to get owned. This is for the exact same reason that "yes, there's an XSS vulnerability in the admin panel, but that doesn't matter because it requires an admin login" is invalid. At some point, somebody is going to combine multiple "unexploitable" vulnerabilities or exploitation paths that you overlooked, and successfully compromise your system. A vulnerable dependency means that you need to update that dependency, full stop. No exceptions.
      - Alupis 10y ago
        Whether it's relevant or not is up for the project maintainer to decide. All anyone can do is point out what they perceive as a potential problem, and then let the others take it from there. CiPHPerCoder didn't exactly do that. He came out guns ablaze from the start, using bolded text, italics and inflammatory phrasing - basically just stopping short of calling the project maintainer a complete idiot. It's not surprising CiPHPerCoder got the reaction he did - it is, however, surprising he decided to do all this under his company's name. It's almost like CiPHPerCoder is personally offended that some joe random developer hasn't heard about some obscure CVE CiPHPerCoder was involved with, or that they didn't handle it like he would like. "Do you know who I am!?" The initial issue was he came here and ranted about it, instead of pointing it out to the projects. Eventually he "gave in" and reported it to a single project, but took this holier-than-thou tone and was aggressive the entire time. That's ridiculous.

iamatworknow 10y ago

I don't disagree with your or joepie91_'s points in that many (maybe most) open source project maintainers are perhaps more guarded and difficult in accepting contributions than they should be. That said, even if you submit a pull request or an issue ticket and the maintainer doesn't follow up, or is making the issue unnecessarily complicated to resolve formally and merge into the main branch, at least the record of your findings is there attached to the repo as a rejected pull request or a closed issue ticket, and that can help someone who comes along after the fact who maybe experienced the same issue you did and can benefit from your comments. Maybe that same person who comes along later will have the time to fight for having the changes merged, and can use your comments as further evidence that the issue is worth reconsidering. I stand by the idea that finding the issue, but posting it on an unrelated forum (like HN) instead of attaching it to the project itself serves no purpose than to tell others who are probably not even users of the open source code "look at this problem I found/solved, aren't I great?"

CiPHPerCoder 10y ago
In this case: I did, and it was immediately closed without any change to the code, documentation, process, or culture.
- iamatworknow 10y ago
  I'd say you did your due diligence then.
- Alupis 10y ago
  > In this case: I did, and it was immediately closed without any change to the code, documentation, process, or culture. You left out the part where they told you this perceived issue did not impact their codebase, due to how they were using the upstream project you cited.[1] > While this is an issue it does not affect us as we aren't using session cookies with slim You then started to rant about how they don't update their dependencies "quick enough". [1] https://github.com/samilliken/openDCIM/issues/837 https://github.com/samilliken/openDCIM/issues/837
  - joepie91_ 10y ago
    > You left out the part where they told you this perceived issue did not impact their codebase, due to how they were using the upstream project you cited. This is completely irrelevant. Vulnerable dependencies are vulnerable dependencies, and trying to avoid updates because you're "not affected" is a really good way to get owned. This is for the exact same reason that "yes, there's an XSS vulnerability in the admin panel, but that doesn't matter because it requires an admin login" is invalid. At some point, somebody is going to combine multiple "unexploitable" vulnerabilities or exploitation paths that you overlooked, and successfully compromise your system. A vulnerable dependency means that you need to update that dependency, full stop. No exceptions.
    - Alupis 10y ago
      Whether it's relevant or not is up for the project maintainer to decide. All anyone can do is point out what they perceive as a potential problem, and then let the others take it from there. CiPHPerCoder didn't exactly do that. He came out guns ablaze from the start, using bolded text, italics and inflammatory phrasing - basically just stopping short of calling the project maintainer a complete idiot. It's not surprising CiPHPerCoder got the reaction he did - it is, however, surprising he decided to do all this under his company's name. It's almost like CiPHPerCoder is personally offended that some joe random developer hasn't heard about some obscure CVE CiPHPerCoder was involved with, or that they didn't handle it like he would like. "Do you know who I am!?" The initial issue was he came here and ranted about it, instead of pointing it out to the projects. Eventually he "gave in" and reported it to a single project, but took this holier-than-thou tone and was aggressive the entire time. That's ridiculous.