Currently, the message that you get when you to do https://www.drupal.org/project/{project}/report-security-issue
is this one:
This project is not covered by the Drupal Security Team’s advisory policy. Security issues do not need to be privately reported for the {PROJECT} project.
The wording of this message suggests that it would be a reasonable thing to just go ahead and publicly announce a security issue. That's absolutely NOT reasonable. Even if a project is not covered by the security team. This can be the case because it's still in beta / rc. I think we all know how many beta / rc or even dev modules a typical production Drupal site has installed.
Regardless of the state of a module it is irresponsible to publicly disclose any security issue without first at least attempting to contact the maintainer and giving them a chance to reply. The message is a security threat in itself in that regard.
Instead, it should probably read more like this:
This project is not covered by the Drupal Security Team’s advisory policy, becuse {x, y, z}. Please attempt to contact the maintainer of {x} directly through their {link} contact form or attempt to message them discretely on one of the commonly used channels of community communication (Twitter, Slack, etc.). If the maintainer does not respond within a reasonable time-frame, you can publicly disclose the issue.
Comments
I fully agree, public
I fully agree, public disclosure should only be done after communication with the maintainers failed.
The code is in https://git.drupalcode.org/project/drupalorg/blob/dev/drupalorg/drupalor... , so we could go ahead and make a patch to change it there.
Any objections?
I am not sure maintainers
I am not sure maintainers want to be contacted by "users/researchers" directly. The security team deals with a large number of false positives and folks asking for support We can discuss this at our next meeting.
Agreed, I am sure there are
Agreed, I am sure there are former maintainers of modules (still in beta/alpha) which have since left the community and simply don't care about them anymore. In that case, this could be a simple opt-in flag on the module just like the opt-in for security team coverage.
Information leak
I suppose this could be considered information leak.
https://www.owasp.org/index.php/Information_Leak_(information_disclosure)
One of the reasons that
One of the reasons that issues go to the public queue is it helps ensure the information won't get lost. A scenario I haven't seen raised yet is:
On a style note: you've used several emotionally charged and subjective words like "irresponsible" and "not reasonable." For us to have a good faith conversation it would help to avoid words like that. I assure you that there's a wide spectrum of perspectives on this topic and many security professionals consider private disclosure to be irresponsible and not reasonable. Let's just discuss pros and cons of strategies without resorting to subject, emotional appeals.
The current wording was chosen pretty carefully in a community reviewed process involving dozens of stakeholders from across the project. There's some good history of the process and wording in
knaddison blog | Morris Animal Foundation
Sure, if the maintainer does
Sure, if the maintainer does not respond after a while, the issue should be released publicly. Another option would be to add security related issues to d.o where, if the maintainer does not respond within a set amount of days the issue becomes public.
Of course there are conflicting opinions about this topic just like with everything. But if they go beyond the problem of security reports going unnoticed I would be really keen to hear them. However, if this is the only concern then I strongly feel that it's the wrong decision to instead suggest to report them publicly right away.
Regarding your side-note: I don't see how these words are emotionally charged. They just transport my opinion on this subject. Without opinion, there is no discussion. I mean, the topic we are talking about is "responsible disclosure". In that context, the word "irresponsible" can hardly be described as emotionally charged ;-)
You claim the current Drupal
You claim the current Drupal process is "irresponsible" based on being the opposite of so-called "responsible" disclosure. That whole vocabulary and perspective on the topic of security are out of date. The phrase "responsible disclosure" has been out of date for 8+ years now, for exactly the reason it is wrong to use here. You can get a sense for the nature of the issues with the phrasing in the CERT Guide to Coordinated Vulnerability Disclosure. which says:
You say you're keen to hear the reasons for why we have the system we have and they are in the resources I linked.
Was there something specific that sparked your interest in this subject?
knaddison blog | Morris Animal Foundation
I did not write my initial
I did not write my initial post to discuss terminology but to question the content of the happy message at the top of the page that's linked to when you click on the "Report a security vulnerability". Whether or not you want to call it responsible / irresponsible or coordinated disclosure is irrelevant. I'd appreciate if we could focus this discussion on the contents of the message in question and not the adjectives of my initial post.
The message currently suggests that one should simply go ahead and write a blog post or tweet about it. There is a security process for full projects for a reason. If, due to limited amount of resources, it's impossible to cover all projects (absolutely understandable), then this message should at least attempt to make it clear that attempting to privately contact a maintainer (even if it's just an alpha/beta/rc) should be preferred. I struggle to see how this should even be controversial.
The message does not suggest
The message does not suggest they write a blog post nor tweet. It is set at the top of the issue creation form with the form pre-filled to a priority of critical and an issue tag of security. Perhaps those nuances are missed by folks, but the only appropriate change to the help message would be to make it more clear to file the issue below.
I could see changing the message to be more clear about where to report, as an issue in the public queue using the below form.
knaddison blog | Morris Animal Foundation