As we've just seen recently with References project SA followed by the module being marked as unsupported, though this is just an example of many, this may be a major issue for thousands of sites using a module. May be you cannot disable it right away, there may be available replacements or not, but in any case this way of doing things (Unspecified SA, then Unsupported) is putting thousands of sites at risk.
I believe there should be better ways to handle these cases and though I don't know how exactly, it will need some discussion, here are just some ideas about it:
- What does it mean a module release is 'Supported'? That it will be marked so until a security problem is found then just left abandoned? Then it was not supported in the first place, was it?
We do need stronger policies about what is marked as supported and what is not. Maybe a module that didn't get any new maintenance release in 3 years should have already have been marked as unsupported long time ago...
-
It doesn't help anyone to just put out a SA marking the module as unsupported at the same time. I think maybe if the Security Team don't get a response from the maintainer within 2 weeks, and even before confirming the issue, the module should be just marked as unsupported -but maybe not by the security team-. Or maybe some polling method would be better, like polling the maintainers of the top 100 modules once a year, or something similar.... I don't know how exactly but there should be a better way..
-
Then if a module is marked as unsupported because the maintainer/s didn't reply to the security team or they were not willing to fix the issue, ALL the modules maintained by the same people maybe should be just marked as unsupported.... just wondering....
-
If we put out an SA about a module, it should at least clarify what is the security risk so I can decide whether I should put the full site offline until a solution is found or I just can live with it for a while. These vague SAs we see sometimes only can help the bad guys with enough spare time to do further research...
In any case I think if we want to help Drupal code quality and security, some really stronger policies should be put in place about what is supported and what is not. Because this "supported until it's not supported" is not helping anyone.
Really I'd like to see an scenario where modules are timely marked as unsupported, before any security issue is found, maybe taken over by someone else that will be there to fix the future issues. Then we could really prevent many of these situations. Because when we learn some module has a security issue + is not maintained, then it is possibly too late for anyone to take it over and fix it....
As I've said the References module is just the latest example. Also cases like Media module that had a "supported" branch (7.x-1.x) that looked like supported and even had a tagged release, but actually was not, and another one (7.x-2.x) that had no stable release but turned out to be the only one really supported..... Note: it is not a trivial upgrade.
I'd really ask module maintainers not to take this personally because I am just one of the many module maintainers that has some old modules that really would need some better maintenance... but also has many other things to do... And for the same reason I am grateful to all of them, even if they cannot find the time to do that security patches...
I just think we have some important opportunity for improvement here and that small policy improvements could produce huge security benefits for everybody.
(Btw I coudn't find a better place to post this one, since the security tracker is private and this one is for public discussion, also I didn't find a project where it would fit, I tried....)
Comments
A really useful thing on the
A really useful thing on the unsupported SAs would be severity level/mitigation. A lot of security issues require a specific permission, only affect a sub-module etc. It gives someone maybe a bit more of an idea on where to look if they wanted to figure out the vulnerability, but probably better than people getting overwhelmed/ignoring.
I check SAs every Wednesday for D6LTS support, and usually try to get ahead of things, but the flurry of releases did take me by surprise a bit - in this case no sites we provide LTS for were affected so in practice it was manageable, but could have been different.
On automatically marking modules unsupported, that seems theoretically OK at three years but there should be some way to override it if the module is actually just stable and doing OK.
For example I wrote agrcache before 7.x was released iirc, it's had 7 releases and has three open bug reports now, two are contrib module conflicts, one is only an issue in maintenance mode with two comments. If nothing else happens, I doubt there'll ever be another version of it. This is just because it's very old, very single use, doesn't expose any features etc.
On the other hand, if we leave a manual override for unsupported, maybe that's fine:
3a. Update the project node or something and avoid having it unsupported
3b. If you do nothing, marked unsupported - you can still edit the project node later to make it supported again.
My worry with making unsupported SAs too specific is...
My worry with making unsupported SAs too specific is that it's only describing the one security issue that's known now. There may be other security issues in the module that haven't been found yet!
So, someone might see that SA and say, "oh, I don't have that permission enabled, so I can just keep using this module ... forever." :-)
Being unsupported means that no SAs will be issued for any future security vulnerabilities that may be discovered later. It also means that those future issues will be reported in the public queue, that will make it waaay easier for attackers to discover them.
So, staying on an unsupported module is risky, and I don't want us to do anything that could lead people to believe that they can safely keep using that module.
That said, I think we could be a lot better with how we modify SAs and messaging after the module becomes supported again! But that's maybe a topic for another thread.
periodically re-indicate project support?
One of the problems I think we face is that a maintainer marks their project as "supported" when they create it because it always is on that day. It is less likely that a while later they will update the status to "not maintained" when they stop using that project or stop working with Drupal or stop being employed by the company that needed that project.
A potential solution is that any project that is marked as "actively supported" will require a re-commitment of that status from the maintainer once per year. Perhaps it could work like this:
knaddison blog | Morris Animal Foundation
Looks like there's some work
Looks like there's some work toward this idea in Automatically degrade Maintenance & Development status of projects over time..
knaddison blog | Morris Animal Foundation