ezyang / htmlpurifier

Standards compliant HTML filter written in PHP
http://htmlpurifier.org
GNU Lesser General Public License v2.1
3.09k stars 330 forks source link

Generate Standalone maintenance script is missing in the latest release #263

Open jonruttan opened 4 years ago

jonruttan commented 4 years ago

The standalone version can no longer be generated as of release v4.13.0. The maintainance script which generates the standalone version has been removed:

php vendor/ezyang/htmlpurifier/maintenance/generate-standalone.php
# Could not open input file: vendor/ezyang/htmlpurifier/maintenance/generate-standalone.php

ls -l vendor/ezyang/htmlpurifier/maintenance/generate-standalone.php
# ls: cannot access 'vendor/ezyang/htmlpurifier/maintenance/generate-standalone.php': No such file or directory

ls -l vendor/ezyang/htmlpurifier
# total 48
# -rw-rw-r-- 1 user group   792 Jun 28 20:56 composer.json
# -rw-rw-r-- 1 user group   341 Jun 28 20:56 CREDITS
# drwxrwxr-x 3 user group  4096 Jun 28 20:56 library
# -rw-rw-r-- 1 user group 26456 Jun 28 20:56 LICENSE
# -rw-rw-r-- 1 user group  1227 Jun 28 20:56 README.md
# -rw-rw-r-- 1 user group     6 Jun 28 20:56 VERSION

cat vendor/ezyang/htmlpurifier/VERSION
# 4.13.0
ezyang commented 4 years ago

This was removed on purpose in https://github.com/ezyang/htmlpurifier/commit/d148edbcf1c477e7df9392bf87c96c49295d3333

cc @morozov

ezyang commented 4 years ago

as a workaround you can check out the tag from git

jonruttan commented 4 years ago

Okay, thanks for the response.

I did see that it was removed with that commit, but I assumed that removing that particular script was in error.

I'd considered checking out the tag from git, but then the project would be hardcoded to use that version and never get updates through Composer.

ezyang commented 4 years ago

OK, I'll give some time for @morozov to respond, and if there's no response I'll revert the commit and issue a point release

morozov commented 4 years ago

I believe the standalone script should be either built by the maintainer and distributed as a different composer package (e.g. ezyang/htmlpurifier-standalone) or sourced from Git and built by the consumer.

In any event, the build script should not be part of the distribution package because it's not used in production and may impose security risk.

jonruttan commented 4 years ago

Yeah, I can see your point about the build script in a distribution package as a possible security risk.

I suspect a second Composer package might be the best solution, but I don't know how much extra work that entails.

The issue with sourcing from Git is that it breaks the Semantic Versioning upgrade process. Composer will lock it to a particular version and stop checking for upgrades.

morozov commented 4 years ago

I cannot currently check it but doing composer install --prefer-source may work as well. It will check out the desired version from Git and will ignore the entries excluded by .gitattributes.

As an offtopic: what's the benefit of using the standalone build? As far as I understand, it was a thing in the pre-PHP7 era but with the introduction of PHAR and Opcache, nobody does that anymore.

jonruttan commented 4 years ago

Good question. No, I don't know whether there is currently a benefit to using the standalone build. Perhaps it's not needed any more.

I am upgrading to PHP7 a legacy library which uses this package and is running on PHP5.6 right now, so (unfortunately) it is still being done. What I've done for now is to use the autoload package.