Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.When you enable daily emailed "security updates only" notifications, you will also be e-mailed reports about "unsupported" modules.
These are not security updates:
- Unsupported modules don't necessarily have unfixed security holes.
- Being unsupported doesn't make a module any less usable or stable.
- It assumes that being "unsupported" is a bad thing; it presumes we need support.
In one particular case scenario, a site has been "done" for three or four months now. We are maintaining the site from a security standpoint only and we have developed code that integrates with certain modules. These modules are now "unsupported" due to newer major point versions being released. However, because the APIs have also changed, we can not just upgrade these modules without also redeveloping custom and integrated code. But, now, each and every day, we get an e-mail to our security@ address that implies there's a security update (because that's the only thing we checked off in the e-mailed notifications, not "unsupported modules"). It is noise clouding the signal.
In short: an unsupported module should not be considered a "security update".
Comments
Comment #1
merlinofchaos commentedI'm not entirely sure I agree. The fact that a module is unsupported means that, should there turn out to be a security flaw, there is no one to fix it. That is valuable information.
Comment #2
morbus iffI'm not sure that "no one to fix it" pans out in real life, though - if there's a /reported/ security flaw (and, really, we have to assume that it is reported), then someone from the security team either ends up fixing it, or unpublishes the release entirely (in the face of no-maintainer, I mean). Unpublishing the release would stop update_status from complaining about it too (I think, right? But, I suppose, that workflow actually breaks update_status entirely, since it'd have no way to report anything useful). Fixing the hole, on the other hand, means a valid hit from update_status.
Comment #3
morbus iffI guess there's a major theoretical difference between the two: a security release always means something - either it's an organized release from the security team, or it's some maintainer doing something wrong (i.e., creating a security release without going through the security team). But an unsupported release could mean any number of things: a module rewrite, an lazy maintainer who doesn't want to support D5 anymore (me, traditionally), a maintainer who will only ever support the latest latest version of a module (which is almost never friendly), et cetera, et cetera. One of the two is nearly always "official" and important - the other gives maintainers an unnatural and opinionated influence over what update_status reports.
Comment #4
dwwI have no time to debate this now, but this was an intentional decision in the design of update_status. Also, note that update_status complains even more bitterly and loudly if a release node (or project page) has been unpublished. Furthermore, you're welcome to tell update_status to start ignoring this project for you, which you can do directly in the UI in D5, or by installing Update status advanced settings in D6.