You took the time to go search through those repos, and then took the time to come here and point out your findings.
You could have easily just copy pasted what you wrote here into an Issue on those repos.
It would have helped out your government, made these projects a tad bit better, and taught a few developers something they'll remember in the future when they write more software for the government.
It's part of the "spirit" if you will. Let's support these efforts - they're long overdue and difficult enough to get done for those few trying.
Reporting issues to a vendor takes a hell of a lot of effort and time compared to idly posting them in a comment thread.
This is like those remarks along the lines of "it only takes 5 minutes to submit a patch to the documentation". No, it doesn't - it takes 5 minutes to write it and create a PR, and usually two hours to defend it from the maintainer's criticisms.
>usually two hours to defend it from the maintainer's criticisms
Isn't that what we want, though? Discussion and review, particularly with the people who are most familiar with the project (the maintainers) is what makes software better, not worse. 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?
No, it's not. Legitimate discussion and review, sure - but that doesn't take two hours. The problem is with maintainers arguing over small changes, trying to trivialize them, finding reasons to reject them, asking contributors to do more work first... It's pretty much impossible to just leave a contribution and move on.
This is something I encounter constantly. It's why I've stopped bothering submitting documentation fixes in most cases, and now resort to writing and publishing my own documentation. It makes one-off contributions to open-source unreasonably costly and non-viable. I know many others who feel the same.
If maintainers want more contributions to their open-source projects, they need to start recognizing that the contributor's time and skills are valuable as well - that means not second-guessing contributions unless there's a concrete reason to do so, and making an effort to write a comprehensive response to a contribution (especially if it's a rejection). And most of all, being clear about this policy.
It's easy to say "why don't you submit it to the project?" from the sidelines, but the reality is that 'formal' contributions nearly always come with an expectation of dedicating your time and attention towards them on a more-or-less ongoing basis. Many people cannot afford that, and as such publish them elsewhere.
Changing that starts with maintainers, not with contributors.
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.
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.
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?"
> 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.
In my experience, this is a continuous source of frustration and anxiety. Not responding doesn't stop the notifications, and on top of that it also makes the contributor look bad by ignoring follow-ups. It's much easier and less frustrating to just not file anything in the first place.
> 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?"
This is just flat-out bullshit, and frankly says more about you and your assumptions than about CiPHPer (who, for the record, is somebody I know personally). Have you considered that maybe CiPHPer is just tired of arguing with vendors and getting nowhere, and has now resorted to just publicizing their fuckups in the hope that maybe that will change something?
To be clear: nobody owes any vendor anything. While I personally at least attempt to disclose a vulnerability privately before going public, there is absolutely no requirement to do this. It is first and foremost the vendor's responsibility to keep their software and its dependencies up-to-date, not that of the public. Be happy that it's being reported at all, rather than just quietly sold on the black market.
The reality is that vendors have been grossly negligent of security for the past several decades, and still continue to do so, using all kinds of shit excuses about how much time and money it costs to fix something they shouldn't have fucked up in the first place. Don't be surprised when security researchers get tired of that shit, and just start dumping vulnerabilities publicly when there are indications that the vendor is negligent (like is the case here).
Again: the change here is to come from the vendors, not from the security researchers.
> 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".
> 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.
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.
> 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!?"
Except this isn't "some joe random developer", this is software created by and for the US government, which is featured on code.gov.
I'd expect them to take security seriously and apply all upstream security patches immediately, not sit on them for years after they've been resolved.
Anything but that is sheer negligence. What else hasn't been updated which contains vulnerabilities that do affect them?
> The initial issue was he came here and ranted about it, instead of pointing it out to the projects.
That's what joepie91 was trying to explain to you.
> 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.
Would you rather I do that or not report it to them at all? Choose only one. If I'm going to do it, I'm not going to do it your way. You can if you want.
Personally, I'd rather not report bugs at all. Until you've reported vulnerabilities to two or three dozen different projects, this might not mean much, but: It burns you out to keep reporting the same flaws to different projects.
Having developers respond to security risks with an air of entitlement just turns up the heat on the burn-out engine.
The first response to my comment here was
You should send in a pull request, or file a bug report in the repo.
Pay attention to the order of operations here. The "should" is immediately associated with a large amount of unpaid work, with an alternative that would also be a large amount of unpaid work disguised as a hypothetically smaller amount of effort. But as others have stated: It's not.
> 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.
Even if I had remembered to switch Github accounts, people would still associate it with my employer anyway. Kind of a moot point, really.
I gave you what you asked for. Next time, maybe don't tell people what they should do? It's rude to bark orders like that, and it won't get the result you want.
Perhaps if you didn't act like a jackass when reporting bugs, you'd have better interactions, and get less of the "burn out" feeling you're describing.
And next time you decide to put on a show, consider not doing it under your company name.
You're forgetting this arrogant display is here for all to witness, including folks who may (or may not, now) want to contract your company in the future. You also seem to forget the very folks behind code.gov are the same ones that influence who gets contracted with the government...
The people working on code.gov and all of the repositories are truly doing something great. Code has been in the federal government for at least 60 years, probably longer - and this is the first time something like code.gov has been produced. It's an amazing effort, and it's surely not easy to effect change like this at the federal level.
The open source initiative will help increase code quality at the federal level, as well as encourage less duplication of efforts (different agencies likely solve similar or the same problems very often). It also encourages a baseline standard of code and organization. This is a fantastic beginning!
Next time, a simple "Hey, did you guys know about CVE-2015-2171? You may have some vulnerabilities." is all that's needed. Instead, you let everyone know you were in a fit of rage - how dare someone suggest you comment on an issue you brought up!
We need to encourage and support these efforts, not shit all over them.
> You're forgetting this arrogant display is here for all to witness, including folks who may (or may not, now) want to contract your company in the future. You also seem to forget the very folks behind code.gov are the same ones that influence who gets contracted with the government...
If you base your "security talent" hiring decisions the same way you approach "contract customer service representative decisions, you'll end up with very pleasant people who don't know jack shit about security. Which would explain a lot of the results we're seeing. So you might be right.
If anyone is reading this thread and wants their software to be actually secure-- no sugar-coating or letting bad decisions happen-- get in touch. :)
> The people working on code.gov and all of the repositories are truly doing something great. Code has been in the federal government for at least 60 years, probably longer - and this is the first time something like code.gov has been produced. It's an amazing effort, and it's surely not easy to effect change like this at the federal level.
For once, we are in agreement.
> Next time, a simple "Hey, did you guys know about CVE-2015-2171? You may have some vulnerabilities." is all that's needed.
OK, why didn't you do that then?
It's so easy to tell others what to do, when you have no skin in the game. What will you do next time?
- Tell the other person what to do.
- Do it yourself, because it clearly matters to you.
> We need to encourage and support these efforts, not shit all over them.
> In short, don't be an ass... please.
I won't be an ass if and only if folks aren't making demands of how I spend my leisure time.
You could have easily just copy pasted what you wrote here into an Issue on those repos.
It would have helped out your government, made these projects a tad bit better, and taught a few developers something they'll remember in the future when they write more software for the government.
It's part of the "spirit" if you will. Let's support these efforts - they're long overdue and difficult enough to get done for those few trying.