Discuss: downloading Windows packages from GH release assets

[asgrim]

Originally posted in php/pie#86 by @cmb69 :

https://github.com/ThePHPF/pie-design?tab=readme-ov-file#windows-binaries mentions that Windows packages should be downloaded from GH release assets. In my opinion, that is a bad idea for (a) security and (b) stability reasons.

Re (a): a malicious actor could register a useful extension via packagist, and then roll out Windows binaries as releases which may contain arbitrary malware (those binaries would not even need to be built from the GH repository sources). There is no way to verify the integrity of the binaries.

Re (b): even if we assume no malicious intententions, Windows binaries may be built against arbitrary dependendencies, and these may conflict with others. E.g. two different extensions might use the same dependency DLL and ship it; but the first one uses a newer version, and the second one an old version. The first one might rely on functions of the newer version, but if the second extension is installed after the first one, the DLL will be replaced, and the first extension will no longer work. Even if we assume that this won't happen, there may be subtle differences regarding the used Windows SDK etc.

I suggest to only download Windows binaries from PECL (i.e. from https://downloads.php.net/~windows/pecl/releases/). These are under the control of the PHP organization (particularly how they are built), and could be easily rebuilt in case of any conflicts (or withdrawn if need be).

cc @shivammathur

[asgrim]

My initial response, for ease of reading:

Firstly, thank you for your feedback, perhaps it could've come a little sooner though :) ... the design of PIE was discussed almost a year ago with public consultation, and the https://github.com/ThePHPF/pie-design repo has been worked on transparently and in public, with ample opportunity for much earlier feedback.

Both points (a) and (b), as far as I can tell, could equally apply to downloading from https://downloads.php.net/~windows/pecl/releases/ .

For example (a) less people have access, but that does not mean a bad actor could take advantage of a hypothetical vulnerability and place their own malicious binaries. This point also applies to any extension built from source, in practice, since (unfortunately) very few people using PECL (or PIE, eventually) will actually read the source before compiling anything.

(b) also applies because the extension binary is built against whatever libraries builds them... which may be different for each extension there. This issue doesn't seem any different when building for the official Windows binaries provided, versus any other way of providing binaries.

The recommended approach in PIE for building the Windows binaries is to use https://github.com/php/php-windows-builder ; which means the PHP organisation is already in control (as much as extension authors can opt in to using it) the stack on which extensions are built; but this gives extension authors the freedom to produce their own binaries, should they wish.

That said, there is scope in future for improvements, such as;

* building Windows exts from source with PIE (in the same way as Linux exts are built from source)

* uploading GH release assets to other repo hosts (such as Gitlab) etc.

[cmb69]

Let's leave the security aspect aside for now. :)

(b) also applies because the extension binary is built against whatever libraries builds them... which may be different for each extension there. This issue doesn't seem any different when building for the official Windows binaries provided, versus any other way of providing binaries.

See php/php-src#16794 for example. If the ext/ssh2 maintainers would already provide binaries for PHP 8.4 (what does not seem unreasonable, considering the ABI freeze happened with PHP 8.4.0RC1), a user then PIE installing ssh2 would get the old libssh2 1.10.0, being unable to use ext/curl. Now it may be argued that we shouldn't have updated to libssh2 1.11.1 that late in the release cycle, but that version has been released only four weeks ago, and only that version fixes the Terrapin vulnerability. If we had updated to libssh2 1.11.0 long ago (released May 30, 2023), that likely would not have been a problem, but nobody did the update.

Now consider extension maintainers who do not even use the officially provided libssh2 builds. They may get them from somewhere else instead, possibly resulting in an unscrutable mess. Linux users, on the other hand, likely don't face such problems, because the dependencies are managed by their distro, and when they build an extension, they get the right dependency versions.

building Windows exts from source with PIE (in the same way as Linux exts are built from source)

I don't think this will ever lift off. Even if it would be supported by PIE, most Windows will not install Visual Studio/MSBuild environements (these installations are huge), and even if they do, they might face quite some complexity; e.g. you install latest Visual Studio 2022 (what is recommended by MSFT) and you want to build an extension against PHP 8.3. Then you need to also install the v142 toolset, and possibly and older Windows SDK. Doing this is not hard, but many won't know how to do it. Then they read up build instructions, and are referred to installing Visual Studio 2017 …