Problem/Motivation
The method for packaging install profiles into distributions on Drupal.org is very dated and being used by just a handful of projects. Maintaining it is both a drain on limited resources and a potential security issue. While D7 has been given yet another EoL extension, a shift of resources to the current version of Drupal and a modern approach to packaging is long overdue.
The current D7 install profile/distribution packaging relies on drush make. The last version of Drush to support the make command was version 8. Drush 8 is still listed as being EoL in Nov 2022 on https://www.drush.org/latest/install/#drupal-compatibility.
While the team managing Drush may or may not extend that project's EoL, the regex the Licensing Working Group (LWG) maintains in
https://www.drupal.org/packaging-whitelist →
is also problematic. The volunteers (before the LWG was formed) and the LWG members have only been checking these projects for licensing compliance at the time of the request. In the decade since some of these libraries were approved, the project's licensing or Drupal.org policy has changed.
Our approach of checking specific paths to project repositories/downloads and not the licensing and security of each version also allows projects on Drupal.org to continue to include libraries with known licensing and security issues.
While using regex to manage which libraries could be included was an "innovative" approach when it was
launched a decade ago →
, it has some serious shortcomings. Looking to the future, commands like composer outdated and composer licenses give us a structure to build packaging solutions that solve many of the short comings of the drush make approach.
The way the distribution packaging works now, we have several D8 distributions appear to be supported. Users aren’t warned of the problem until after the install.
With CKEditor in core, the security issues in the older versions of the library are well known.
https://www.drupal.org/node/1403548 →
allows these older versions to be included with a secure version of Drupal core with no warning to the user even after install.
We also have projects with libraries using licenses that should have never been approved like
https://www.drupal.org/node/1597494 →
LGPL-3.0 or
https://www.drupal.org/node/1695056 →
AGPL-3.0.
If you look at the top 25 D7 distributions by reported installs, only 3 have been updated using the drush make packaging in the last 6 months; Panopoly, Opigno LMS and farmOS.
Beyond the top 25, the percentage of active D7 projects in the other ~300 projects is even less.
Proposed resolution
We should start phasing out the packaging of install profiles on Drupal.org now and no longer create packaged, downloadable D7 distributions as releases on Drupal.org after the previous D7 EoL date in November 2022.
Some steps in this process might include;
- Communicate the timeline for ending support for packaging on Drupal.org with Install Profile maintainers giving them an opportunity to transition to another process if they want to continue distributing a downloadable package. (ie. FarmOS already has a packaged install available on GitHub)
- Officially make
https://www.drupal.org/packaging-whitelist →
read only
- Remove releases from install profile projects that include a version of Drupal core that is unsupported or has known security issues (80-90% of distribution projects with downloadable releases including D8 projects like
https://www.drupal.org/project/brainstorm_profile →
)
- Stop running drush make on Drupal.org in November 2022.
- Remove releases from remaining install profile projects with the first D7 security update after November 2022.