We've got some licensing and third-party code rules for Drupal.org CVS.
The Security Team has set some policies that it enforces, but these policies impact module maintainers and, so far, we have not really informed maintainers that they should agree to the policies of the Security Team as well.
This is the big one: http://drupal.org/security-advisory-policy
We also attempt to follow a "14 days from reporting to release" and our template e-mail to module maintainers includes a date roughly 14 days in the future:
We make security releases each Wednesday and aim to resolve security vulnerabilities within two weeks if possible. We are planning to have this issue fixed and an SA made no later than {Wednesday in approximately two weeks}. If we don't have a response or fix from you by then we may fix it directly or unpublish the module's releases.
That policy comes from a general sense that "sooner is better than later" but also from general Application Security best practices, notable documented at http://www.ocert.org/disclosure_policy.html
So, is a 14 day policy a reasonable one to ask of module maintainers? Should these requirements be presented to users as they request CVS applications? Can/should we enforce this on module maintainers?
One concern with asking people to agree to these policies is that it will increase the barriers to hosting code on drupal.org. Code that is hosted elsewhere is guaranteed to be less secure - in the total worldview - because it is less likely to be inspected and will not get an Update Status notification. Note that I'm not saying all code on d.o is inspected, but I do know that I have grepped the entire cvs.d.o contrib codebase on several occasions which found multiple vulnerabilities and several others do the same periodically as they find greppable code.
Comments
I think that it is quite
I think that it is quite reasonable to put it in our CVS guidelines or something that putting your code here means you have to have basic responsibilities for that code, mostly including security. If you're not, find a co-maintainer or we'll unpublish it.
Senior Drupal Developer for Lullabot | www.davereid.net | @davereid
another alternative
The "or unpublish it" thing is just one option.
Perhaps this would dovetail in with the Proposal from Heine on official releases being delayed. We could say "if you don't agree to the security policies then your project will not be allowed to create official releases.
knaddison blog | Morris Animal Foundation
Another reason I'm fine with
Another reason I'm fine with 14 days for security issues is if our abandoned project process takes only 14 days to complete, so should security issues.
Senior Drupal Developer for Lullabot | www.davereid.net | @davereid
that's a non sequitur to me.
that's a non sequitur to me. For abandoning a module you need to nothing but to throw a switch. To do a security release this actually requires work.
I don't think I was quite
I don't think I was quite clear. I'm in favor of 14 days just for the maintainer to respond; not respond, submit patch, write draft SA, and create release with sec team. We give maintainers two weeks to respond on issue if their module is still maintained or not, so the same time frame should be used for maintain response.
Senior Drupal Developer for Lullabot | www.davereid.net | @davereid
Our general approach has been
Our general approach has been to suggest 14 days, but it's been rare that we enforced any disclosure until well past 30 days.
I think it's clear that we need to make it easier for maintainers to roll releases containing only security fixes on top of the last stable release. We discussed this in SF, and hopefully we can alter the CVS branch naming rules to enable this soon.
I think the introduction of
I think the introduction of such a policy could possibly lead to people hosting their code elsewhere and we should tread very lightly.
I agree
Of course I agree since I said the same thing in my original post.
So, how do we balance the needs of the security team (getting things out before public disclosure, clearing the queue of issues which are unlikely to be fixed so they don't waste unnecessary time) with the needs of module maintainers so that they are happy hosting the code on drupal.org and in compliance with the policies(which are now de facto if not stated/agreed to).
knaddison blog | Morris Animal Foundation
I don't think that "getting a
I don't think that "getting a SA out before disclosure" is really a need of the sec team. The arbitrary short timeframes that some people seem to think are good ideas are not really acceptable, IMO, so we shouldn't really care too much about them.
I also think that streamlining our internal processes is far more important than to impose anything on the contributors.
So, I don't have any suggestion for balancing things that may well be non-balancable.
I suggest we shelve this until our internal processes have been improved sufficiently and revisit it later. My guess is that we'll find it no longer neccessary to debate it.
And I just got a !/§Z!(§()! captcha again...
Doing a SA + release within
Doing a SA + release within 14 days is generally undue short to request from a volunteer run project.
I don't think we could do a release for Drupal core in such a time, why should we demand this from contributors?
seems reasonable - do you agree with some deadline?
This is a very reasonable perspective. Do you agree that there should be some deadline (1 month? 3 months?) after which we should make the issue public?
I think a timeline of:
knaddison blog | Morris Animal Foundation
I think one month would be
I think one month would be ok. We should not see this as a fixed date, though. Some people might take extended vacations, be ill, or do something more important thatn fixing a bug that can only be "exploited" if you already sort-of own the site...
$!"§(/)!) captchas
Right, So I think the only
Right,
So I think the only real 'deadline' we should put is some time for the maintainer to get back to us and let us know someone is handling the issue.
Perhaps 2 classes/categories of modules
Perhaps we need an opt in security guideline/pledge of contrib modules. This would be more useful for authentication, authorization, node access, etc modules. Just like accessiblility, i18n, d7 release, etc guidelines/pledges, modules could opt into supporting them. I know this leads to a sort of bumper sticker mentality, but I think it would be informative and perhaps motivational.
Module_X supports drupal contrib catchy-name-here security guidelines
- more than one maintainer
- unit test coverage
- N day turnaround on security patches.
- ...other demonstrable security practices (http://drupal.org/writing-secure-code)
I wouldn't consider a module with one maintainer on vacation for a month a secure module unless it was a pretty basic module that had been out of beta for a while.
www.johnbarclay.com
This sounds
This sounds interesting.
Though I think this could give the impression that there are 'secure' and 'insecure' modules on the repos. The question that would follow is why we are allowing insecure modules at all to be downloaded from the site.
That would look very good though if we named it something more in the line of 'Quality standards' (that would include security and responsiveness though) but it wouldn't look like pointing the finger at other 'insercure' modules (that may not be insecure).
Encourage quality standards, still encouraging contributions.
Reading the comments here looks like we are trapped in the middle of how to enforce some guidelines and quality standards for the modules, but still not discourage contributions or pushing people to post their modules somewhere else.
I know this is something bigger than just security guidelines but we should really push for some 'prize' on modules that are well maintained and get security issues fixed timely.
The idea could be that only modules that have stable releases and meet some of the standards mentioned on the comments above show up on the module listing pages at first glance. We could add (or reuse) a tag like 'Maintained' or 'Stable' that is set as default filter. Anyone wanting to see other modules just changes that filter.
Then, module gets a security report, and is not fixed for whatever time, goes from list A to list B. The security issue is not fixed for some longer time, then we just unpublish it as we do know.
This btw, would clean up our module mess because there are modules there that haven't got a stable release for years. And people downloading modules don't really know what it means using a non stable release (security issues published right away). So I think this also would encourage contributors to put out stable releases.
Still, for someone that just wants to contribute some half baked module and don't worry too much about it, we still allow it, just we don't 'promote' such modules.
different module statuses
Yes, this is somewhat along the lines of the Heine's proposal for release review though it takes it a bit farther.
I think you and JohnBarclay have some similar ideas here and they are pretty strong.
I'm also coming around on "giving maintainers 14 days to respond" (or even 30) but letting the total time from report to release be longer than that.
knaddison blog | Morris Animal Foundation
published deadline for acknowledgement, and follow it
my 2¢:
The time period is certainly debatable, I have no problem increasing it to 30 days or such if that helps. (Again, I'm talking time for an acknowledgment, fixes can take as long as needed).
Also let's realize that unpublishing a release isn't a death sentence. The module can always be revived.
Seems least controversial, most reasonable
This seems like a great first step. We can see how pissed people get about this before taking it further.
I like 14 days for a response. If someone can't at least respond in 14 days they are not serious about maintaining their module.
knaddison blog | Morris Animal Foundation
How about 60 days? And how about bug bounties?
Almost simultaneous with the new chromium bug bounty of 3,133ドル.7 we have an announcement of a responsible disclosure means 60 days to fix.
What do folks think? That's a bit longer than the 14 days. It makes me think:
That feels a little fast for some situations, but it would help keep us all on a schedule.
knaddison blog | Morris Animal Foundation
I generally think an upper
I generally think an upper bound on duration for a fix is the direction we should be going, but I think the current security team workflow, and the fact that many module maintainers are just doing it for fun makes it tricky to put in place now.
A broader question is whether we hold Drupal core and "big" modules to the same standards and time lines for fixes?
I think my ideal would be to
I think my ideal would be to eventually be able to apply a disclosure schedule to all stable releases. For those contributors who aren't willing or able to meet this standard, we'd provide the ability to opt-out of the security advisory process. The opt-out would be called "beta". :-) Combine this with some kind of peer review for stable releases, and there's your "golden contrib". Then the tricky part is figuring out what to do with all the "1.0" modules already out there.