It looks like the failure to update core to > 7.32 will finally be the push needed to unpublish distributions that include forks of core vs. using a .make.
#2153139: Unpublish Distributions with Forks of Core < 7.32 →
But these should have never been packaged. They violate the "do not branch/fork Drupal modules/themes" clause of the Git Usage Policy → . Doing this also circumvents the security warning added for 📌 Should supported releases be shown on downloads table even if it contains insecure modules? If so, how? Closed: won't fix
To prevent this from happening again, it would be great if the packaging could include a check for a fork of Drupal core. Not sure how best to do that. Ideally that code would never get committed, but this check would save time trying to get maintainers to correct this and keep what users are downloading from Drupal.org more secure.
Closed: outdated
Packaging
It makes Drupal less vulnerable to abuse or misuse. Note, this is the preferred tag, though the Security tag has a large body of issues tagged to it. Do NOT publicly disclose security vulnerabilities; contact the security team instead. Anyone (whether security team or not) can apply this tag to security improvements that do not directly present a vulnerability e.g. hardening an API to add filtering to reduce a common mistake in contributed modules.
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
Not sure how relevant this still is anno 2023 and the composer based approach we're long using now.
@BramDriesen You are correct. This is no longer relevant. #3266927: End Install Profile Packaging on Drupal.org in August 2023 → forced the handful of D7 distributions still active to shift to using their own packaging process somewhere other than Drupal.org.