Bundle PIE with PHP by default

[asgrim]

Adds --with-pie by default (or --with-pie=/pie/path) options to ./configure; this downloads PIE into the given path (defaults to $$prefix/lib/php/pie). To build PHP without PIE, supply the --without-pie flag.

Fixes php/pie#564

[asgrim]

General question to reviewers; what is the earliest version of PHP we could get this into? PIE supports PHP 8.1+, so ideally that, but obviously it is out of support, so won't actually get any new releases. I suppose it would be PHP 8.4+?

[TimWolla]

General question to reviewers; what is the earliest version of PHP we could get this into?

It's a feature, thus master.

[henderkes]

While I'm all in for shipping pie with installations by default, I don't think build time is the place to start a download of a separate project. This seems more of a distribution issue than being related to php itself.

Also a bit weird to depend on pie, which has php as a dependency, when building php. Especially in versions that can't even run the phar.

[asgrim]

While I'm all in for shipping pie with installations by default, I don't think build time is the place to start a download of a separate project. This seems more of a distribution issue than being related to php itself.

This approach is the same already taken by PEAR, so there's already a precedence for this. Note that this isn't (yet) bundled by default, you must specify --with-pie to actually get this target to do its thing. There is a slight ulterior motive here; Docker's PHP images seem unwilling to ship PIE with their images unless PIE is bundled with PHP (like PEAR/PECL was); so I'm trying to take steps towards fulfilling that goal.

Also a bit weird to depend on pie, which has php as a dependency, when building php.

This target happens after PHP is already built :)

Especially in versions that can't even run the phar.

This is actually an interesting issue; I already encountered this since PIE does not advertise compatibility with PHP 8.6 yet. The built in Box "requirements checker" will cause the pie --version to fail; I'm wondering if we can handle this a bit more gracefully, but I'm not sure if it should non-zero the whole install, or still exit 0 just with a warning that we couldn't install PIE automatically or something.

[henderkes]

This approach is the same already taken by PEAR, so there's already a precedence for this.

Doesn't necessarily means it was or is the right decision :P

Docker's PHP images seem unwilling to ship PIE with their images unless PIE is bundled with PHP (like PEAR/PECL was);

Ah... yeah. That makes this make more sense. But I don't necessarily think it's necessary. The extension installer isn't currently bundled either, right?

COPY --from php/pie:latest /usr/local/bin/pie /usr/local/bin/pie
-> pie install imagick

should be acceptable.

And it won't have any issues in regards to old/new php versions because it could use a boxed binary.

[asgrim]

Changed this to default ship with PIE, now you would have to use --without-pie to not build with it

[asgrim]

This issue warrants discussion; at the moment, since PIE doesn't (yet) support PHP 8.6 (fails at the Box requirements checker), this would cause a non-zero exit code. Same scenario would happen if PHP is installed without the minimum required extensions.

I'd suggest we capture these kind of errors, print out a warning that PIE was not installed, but still return a zero exit code. Any other suggestions welcome :)

Another option: install the experimental PIE executable coming in PIE 1.4.0 (if possible), since there is no dependency on the installed PHP version; if PIE executable can't be installed, fall back to PHAR (but still have the question about should we exit zero or non-zero if PIE won't work?)

[asgrim]

Example:

  Box Requirements Checker
  ========================
  
  > Using PHP 8.6.0-dev
  > PHP is not using any php.ini file.
  
  > Checking Box requirements:
    E..........
  
                                                                                  
  Error: ] Your system is not ready to run the application.                       
                                                                                  
  
  Fix the following mandatory requirements:
  =========================================
  
   * This application requires a PHP version matching
     "8.1.*||8.2.*||8.3.*||8.4.*||8.5.*".

https://github.com/php/php-src/actions/runs/23794236419/job/69337306073?pr=21524#step:3:2548

[asgrim]

Build failure:

/usr/bin/wget: unrecognized option: no-directories

https://github.com/php/php-src/actions/runs/23794236419/job/69337305959?pr=21524#step:9:37

[asgrim]

Build failure:

To get started with GitHub CLI, please run:  gh auth login
Alternatively, populate the GH_TOKEN environment variable with a GitHub API authentication token.

https://github.com/php/php-src/actions/runs/23794236419/job/69337306006?pr=21524#step:11:39

[asgrim]

Likely similar issue:

Installing PIE:                   /usr/bin/pie
Created directory: /var/lib/snmp/cert_indexes
🥧 PHP Installer for Extensions (PIE) 1.3.10, from The PHP Foundation

In AuthHelper.php line 132:
                                             
  Could not authenticate against github.com  
                                             

self-verify [--with-php-config WITH-PHP-CONFIG] [--with-php-path WITH-PHP-PATH] [--with-phpize-path WITH-PHPIZE-PATH] [--no-cache]

make: *** [Makefile:497: /usr/bin/pie] Error 255

https://app.circleci.com/pipelines/gh/php/php-src/26637/workflows/15956446-015b-4414-8e74-b5341f2214e2/jobs/26328

[TimWolla]

After thinking about this a little, I don't believe that this proposal is reasonable from a supply-chain perspective and from user expectations:

• As a user I expect a “self-contained” release. Downloading files from the Internet, particularly without a “fixed version” is at odds with that. Linux distros commonly perform their build in a VM without Internet access and thus cannot use this target at all.
• Release verification must be a hard requirement for an automated process, because there's no “human in the loop” that can make an educated decision on whether or not the risk of running an unverified binary is acceptable.
• PIE is not usable with a minimal build of PHP and requires additional dependencies on top of PHP (namely ext-zip or a unzip binary).

And with regard to Docker specifically, I believe it is in the best interest of Docker users not to have “build time” binaries sitting around in the final image. The usage instructions provided in the PIE repository are a best practice there: https://github.com/php/pie/blob/1.4.x/docs/usage.md#example-of-pie-working-in-a-dockerfile

[asgrim]

After thinking about this a little, I don't believe that this proposal is reasonable from a supply-chain perspective and from user expectations

There is definitely demand for it; I have been asked numerous times if PIE will be bundled with or part of PHP, and it is logical.

To mitigate the above issues, perhaps, instead of downloading the latest executable or PHAR, we ship the latest version(s) at the time, and have a separate process to automatically and periodically update the latest version of PIE in php-src?

[TimWolla]

There is definitely demand for it; I have been asked numerous times if PIE will be bundled with or part of PHP, and it is logical.

Is there a “demand” or are there “requests”? I believe it's a maintainer’s responsibility to figure out what the user actually needs. While I don’t doubt there are “requests” to bundle PIE with PHP, I’m doubtful this is actually the best solution for the problem these users are having.

Linux Distributions / BSDs are going to package PIE separately as a policy either way. They are separate software projects that are separately versioned and thus will need separate packages. Also users of distro packages are not the target audience of PIE, they are used to just installing the appropriate distro package.

Docker users are very interested in having “small images” with a minimal attack surface and all useless fluff removed. The Debian-based php:8.5-cli image is roughly 571 MB in size, the Alpine-based php:8.5-cli-alpine is 138 MB in size. pie.phar is roughly 11 MB in size. This would be ~10% of an alpine image and still ~2% of the Debian image for something that is only temporarily needed - and not needed at all by some users who rely on bundled extensions only. Furthermore “just bundle PIE” is not sufficient, because PIE is not functional by itself without installing additional packages. At the minimum unzip is required and then you also need to figure out which system packages your favorite extension requires. At that point you are doing so much manual work that “temporarily installing pie.phar” is the easiest part of it all.

That only really leaves the users that compile PHP on their own. I expect these to be sufficiently rare that they'll figure things out themselves, particularly since they are likely to be opinionated with regard to how they want their setup to work.

To mitigate the above issues, perhaps, instead of downloading the latest executable or PHAR, we ship the latest version(s) at the time, and have a separate process to automatically and periodically update the latest version of PIE in php-src?

While that would solve the supply-chain issues, it would bloat both the php-src repositories as well as the official release archives with a 11 MB binary (2.4 MB gzipped). Notably php-8.5.4.tar.gz is just ~23 MB in size, this would also add 10% to the size there for something that most users are just going to ignore.