>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #594704. --> Reported by: [dww](https://www.drupal.org/user/46549) >>> <h3>Problem/Motivation</h3> <p>Installation profiles contain stuff that's not GPL. Many of the issues here are addressed and being resolved here:<br> <a href="http://drupal.org/node/779452">http://drupal.org/node/779452</a></p> <p>The piece that isn't taken up on 779452 has to do with user friendliness. Install profiles should make things easy for people who want something that works out-of-the-box. (.make files aren't user friendly enough for this audience.) If d.o isn't going to host tarballs with third-party, [whitelisted] stuff, we should have a standard process or go-to place for this stuff.</p> <h3>Proposed resolution</h3> <p>[please add]</p> <h3>Remaining tasks</h3> <p>[please add]</p> <h3>User interface changes</h3> <p>[please add]</p> <h3>API changes</h3> <p>[please add]</p> <h3>Original report by [username]</h3> <p>// Text of original report here.<br> (for legacy issues whose initial post was not the issue summary)</p> <p>Note: I think this is a bad idea for a host of reasons, and strongly believe the proper status for this issue is "won't fix". However, some folks are asking about this, and I'd like the discussion to happen publicly instead of just via private emails and IRC chats...</p> <p>Real Soon Now(tm) we're going to package install profiles on d.o so that they contain all the code they require and depend on. There's an open question as to whether or not these packages should include core, too, but that's a separate story. Certainly, they should include all the themes and modules that the profile is going to try to enable and configure.</p> <p>Some folks are advocating that we use <a href="https://www.drupal.org/project/drush_make">Drush Make</a> to assemble the directory tree we're going to package up for any given release. There are some nice things this would allow us to do. However, drush_make currently has support for pulling code from all sorts of sources (multiple VCS backends, pulling tarballs and even patches (which are then applied automatically) from arbitrary URLs, setting up an external site to host update_status release history XML files and querying those, etc). So, if we use drush_make, we have two options:</p> <p>A) Allow d.o install profiles to be packaged with arbitrary code from anywhere on the internet.</p> <p>B) Lock down drush_make so that d.o install profiles are only packaged with code from d.o itself.</p> <p>Technically, (B) isn't that hard. See the following feature requests I already opened against drush_make:<br> <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-7"><a href="https://www.drupal.org/project/drush_make/issues/588486" title="Status: Closed (fixed)">#588486: Support necesarry limitations for drupal.org</a></span><br> <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-6"><a href="https://www.drupal.org/project/drush_make/issues/588488" title="Status: Closed (works as designed)">#588488: add a --allowed-download-types argument to limit the supported download types</a></span><br> <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-6"><a href="https://www.drupal.org/project/drush_make/issues/588490" title="Status: Closed (works as designed)">#588490: add a --default-download-type argument</a></span></p> <p>The question here is if (A) is even worth considering at all from a d.o legal and infrastructure standpoint. There <em>are</em> some nice things this would allow, for example, an install profile that installs its own 3rd party jQuery plugins for you, or other external libraries. Clearly, we don't want that stuff in our CVS repository, but maybe we're willing to have it in our tarballs? Of course, this opens a massive can of worms:<br> - If/how do we validate the .make files to ensure they're not doing anything stupid or malicious?<br> - How do we sandbox the packaging script so that we don't end up with any potential security problems?<br> - What are the versioning and notification implications for security problems in 3rd party code that's now hosted on d.o?<br> ...</p> <p>As I said at the beginning, I believe the answer is going to be an overwhelming and resounding 'no', but I'd like Crell and others to comment here explaining why, so we can have a single page to point people to when this topic comes up in the future.</p> <p>Thanks,<br> -Derek</p>