Discuss involving ecosystem maintainers in security support degradation process

Thanks for bringing up this discussion.

The first option is a reasonable idea, though it's often difficult to determine this. With something like Colorbox how would you suggest guessing how far to throw out the metaphorical net?

The second idea would be difficult to determine - how do you tell what may be "indirectly affected"?

The third option is a no-go - we don't have any way of knowing who currently uses a module, and just because someone has posted in an issue queue doesn't mean they have any active interest in the module.

In general we leave the process in place because maintainers can always add more maintainers if they so choose, so they have the ability to deal with the problem ahead of time.

It might be useful to classify these differently. There were security advisories with fixes implemented in updates mixed in with these "unsupported" module notices. The "critical" status also is equally jarring and confusing when there is no path forward supplied, and I imagine in these cases a lot of users using these modules are in a holding pattern for the next 30 days to see if anyone takes over the project and fixes the vulnerability. I.e., I feel these SA's could have been communicated better and more clearly.

The documentation link supplied also had a broken anchor link, so it didn't take you to the right section of the documentation.

Just to clarify,

Is this being proposed that this process be done before the module is announced as having a security vulnerability or is it being proposed for after the fact a vulnerability is announce (unsupported SA issued) but before the module itself has its releases tagged unsupported and SA coverage is formally removed?

Does that sort of make sense?

Yep perfect sense. I suspected this is what you meant however I just wanted to be sure before commenting.

The drawback of course is that the new status quo would be less secure than the current process.

That is the big part. This would in my mind trigger the following points of concerns (no particular order just numbered for easier reference later):

1. Increase the number of individuals who are in a position to silently exploit a vulnerability.
2. Create a process that permits disclosure to (random/select) individuals prior to others sites receiving such notice.
3. Possibly increase the length of time sites are vulnerable for.

Point 1 isn't really quantifiable on exactly how risky it is considered to be. I would assume it be limited to (as you suggested) maintainers with the vetted role as a minimum. Possibly also add on the impacted project needs to be SA covered as well on the grounds that it shows that particular project views its association as needing to be secure..

Point 3 is going to very based on the vulnerability and timeline of bringing in individuals, however as proposed this could increase the period by 2 weeks that a module is available with a known hidden vulnerability. Personally I think the length of time the security team holds on to issues may actually already be too long in some cases, and this could be an additional 2 weeks that an exploit could be ongoing. Unless Drupal.org has a really good honeypot network to deploy signatures to privately it isn't really known if an exploit is occurring.

Colorbox this past week shown that users may be slow to remove a module since its a core part of their user experience, however after the announcement it was their choice to continue running it while other sites may have chosen to completely remove the module and deal with recovering after the fact.

Point 3 possibly raises the question of should such a policy to perhaps be limited to CVE's of only a certain impact (Below a points score, or excluding specific types of flaws)

Point 2 is where ethics discussions start to occur. It is not unheard of for larger projects to have such information sharing agreements in place, however in my experience usually controlled under previously established non-disclosure agreements (where you know the lawsuits will be filed if you breach and significant monetary damages obtained) and only usually with larger partners(presumption of increased trust/increased need to know.) However in my experience such processes of limited disclosure are often viewed negatively as being denied an equal chance to protect one self.

it almost seems like there should be a mandatory maintainer check-in from time to time. If there's a periodic email that asks maintainers to re-affirm that they're still able to maintain their end of the security advisory agreement, I think that could work.

+1 to trying to find a way to deal with unresponsive maintainers BEFORE a security flaw is reported.

The semi-automatic Drupal 8 project degrading that we've seen could be used as an example of a similar process. It also seems a lot more honest.

A method based off the private notice and if no response open a public issue actually seems quite good IMHO.

Of course all this is making the assumption that the majority of the time it is a maintainer who doesn't respond at all. Two other scenarios that I'm not sure this will fix are:

• When a maintainer is responsive but fails to fix the issue because it is on a branch they do not personally work with/do not have the knowledge to work with. (I was recently in this spot to patch a D7 issue while I'm primarily a D9 dev.)
• Cases where the maintainer is disagreeing with the security team on an issue actually being a vulnerability (I've seen this at least once in a 2012 thread but no clue how common it may be)

Only the security team can opine on if those are frequent enough concerns to render this discussion of limited use (in other words are we suggesting to fix the wrong problem because we do not know all the details)

it almost seems like there should be a mandatory maintainer check-in from time to time. If there's a periodic email that asks maintainers to re-affirm that they're still able to maintain their end of the security advisory agreement, I think that could work.

+1

I think this would solve the real problem. Colorbox had five maintainers listed (paulmckibben and jenlampton were only recently added). Apparently all of those five were unresponsive. One of them stated in an issue after the SA: "One of the original maintainers here, I stoped using Drupal a few years ago and handed over all my modules." He's still listed.

Suppose you were using, or wanted to use, colorbox. The project page looked fine, security team coverage, five maintainers. On the surface this appeared to be a safe choice.

Interesting data point:

Two of the modules that went unsupported had the auto-open for adoption issues.
#3234025: media_entity_flickr project open to new maintainer applications on 30 Sep, 2021
#3238081: image_export_import project open to new maintainer applications on 5 Oct, 2021

These are not the only security supported modules that still have these open for adoption issues open. Some have no volunteers, some have only non-vetted volunteers and as such couldn't be transferred.

Copied from 3280775#16

Maybe there could be a way to have a "frequent contributor" role or something on modules, and give those people the ability to see pending security issues after a certain amount of times passes following a reported security issue, or if the module maintainer can't be reached regarding a security issue. The people given "frequent contributor" or "temporary security issue access" could be automatically or manually determined as desired. I think having more people in the loop would be helpful for arriving at a solution, rather than just marking the module unmaintained (though perhaps in the example situation that would still need to happen).