I'm not joking.

All past distribution builds prior to 7.32 should be automatically repackaged with at least 7.32 or destroy all versions prior to the current stable releases for distributions prior to this or come up with some way to do it. There's no reason to propagate additional copies of a fundamentally flawed version of Drupal.

Or, less destructive.

Put into the make packaging mechanism to automatically rebuild all past builds of 7.x distributions ensuring that the Drupalgeddon patch has been applied at run-time if it is a reported version in the make file prior to 7.32.

It's all well and good that /drupal is the latest release (i'd actually destroy everything prior to 7.32 in there too, lol) but every distribution is vulnerable for download if it's not actively maintained (I'm sure I've got a few in there somewhere too so not pointing fingers).

Comments

aitala’s picture

Good idea.

E

kreynen’s picture

Not sure if this is actually a duplicate, but definitely related #2153139: Unpublish Distributions with Forks of Core < 7.32

I bumped the fork issue to critical > 2 months ago, but there was still no response.

I think the issue is no one knows whose job it is to deal with this.

kreynen’s picture

Title: Destroy all 7.x distributions packaged with Drupalgeddon » Unpublish all 7.x distributions packaged with < 7.32

It's also worth noting that a large number of the these projects fall outside of the scope of the security team since they are not "supported releases" (1.0 or >), so I'm not sure who has this authority to even unpublished them... let alone "destroy" them. I updated the issue title. Hope you don't mind.

If a 1.0 or > release of a module had this type of flaw, it would have been unpublished long ago. I tried getting OpenPublish's abandoned, insecure releases unpublished last year with no luck https://www.drupal.org/node/2088157#comment-8268501 because it was < 1.0.

That led to #2152637: Make it obvious to end-users what to do if a packaged release contains insecure code

Of course even that warning doesn't work when the maintainer violates git policy and commits a fork of core instead of using a .make like the Theme Brain distributions.

I don't think forcing an update to 7.32 makes sense. Who is going to deal with core patches that fail in an abandoned distribution?

Assuming we can agree that distributions are different than modules, following the normal security issue process to unpublish distributions with known security issues in core regardless of version # of the distribution that includes the release seems like a much more manageable approach. We are talking about < 500 projects.. but this includes half of the most popular Distributions listed on the first page of https://www.drupal.org/project/project_distribution... including https://www.drupal.org/project/spark.

While the version # of the distribution could be < 1.0, if the version > 1.0 module, theme, or core has a security issue the distribution should be forced to adhere to the same process as a supported release.

Because the security team has the authority to manage the specific policies within their charter (http://cgit.drupalcode.org/governance/tree/charters/security-working-gro...) and this clearly falls within developing "guidelines and/or recommendations regarding the introduction of new tools, technologies, and processes for the benefit of security", I believe the security team could move after "broad consensus from the Security Team members".

Without that, I'm not sure how this gets done.

btopro’s picture

agree w/ #3 and title change to be less cryptic.
RE

I don't think forcing an update to 7.32 makes sense. Who is going to deal with core patches that fail in an abandoned distribution?

I think version of drush make on server could ensure D7.32 patch could be applied if not applied and distro builds prior to 7.32. that or retag all previous versions of core to have that patch. This would prevent anything building off of anything from having that issue going forward. I know we're not talking typical procedure but this isn't a typical security issue by any means.

mlhess’s picture

Status: Active » Fixed

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.