Marking projects as unsupported / What is a Supported Project / Better policy needed.

Jose Reyero's picture

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:

  1. 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...

  1. 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..

  2. 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....

  3. 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

catch's picture

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:

  1. Three years pass with no release
  2. E-mail goes out to maintainer a couple of weeks before
    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.
dsnopek's picture

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.

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?

greggles's picture

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:

  1. Once every 12 months an issue is auto-created in the queue for every project saying "Is Project X still maintained?" The issue would have an issue label and be created by a "bot" user for this purpose so that it can be easily found in the future. The issue would have clear information in the body explaining what to do to indicate the project is actively maintained.
  2. A maintainer can mark the issue as "fixed" (or something) to indicate that yes it is being maintained.
  3. If the issue remains open for 4 weeks then the project status would automatically be moved to "Minimally maintained" or "Seeking co-maintainers" and development status would change to "No further development" (we could also introduce new values for that?
  4. Perhaps a while later a similar process could be followed (issue filed, email all maintainers, wait 4 weeks, that would remove the "Support" from each of the releases.

Looks like there's some work

Security

Group organizers

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds:

Hot content this week