Upon testing the change itself I realized that it doesn't build properly
because
* the `pname` of a php extension is `php-<name>`, not `<name>`.
* calling the extension `openssl-legacy` resulted in PHP trying to compile
`ext/openssl-legacy` which broke since it doesn't exist:
source root is php-8.1.12
setting SOURCE_DATE_EPOCH to timestamp 1666719000 of file php-8.1.12/win32/wsyslog.c
patching sources
cdToExtensionRootPhase
/nix/store/48mnkga4kh84xyiqwzx8v7iv090i7z66-stdenv-linux/setup: line 1399: cd: ext/openssl-legacy: No such file or directory
I didn't encounter that one before because I was mostly interested in
having a sane behavior for everyone not using this "feature" and the
documentation around this. My findings about the behavior with turning
openssl1.1 on/off are still valid because I tested this on `master` with
manually replacing `openssl` by `openssl_1_1` in `php-packages.nix`.
To work around the issue I had to slightly modify the extension
build-system for PHP:
* The attribute `extensionName` is now relevant to determine the output
paths (e.g. `lib/openssl.so`). This is not a behavioral change for
existing extensions because then `extensionName==name`.
However when specifying `extName` in `php-packages.nix` this value is
overridden and it is made sure that the extension called `extName` NOT
`name` (i.e. `openssl` vs `openssl-legacy`) is built and installed.
The `name` still has to be kept to keep the legacy openssl available
as `php.extensions.openssl-legacy`.
Additionally I implemented a small VM test to check the behavior with
server-side encryption:
* For `stateVersion` below 22.11, OpenSSL 1.1 is used (in `basic.nix`
it's checked that OpenSSL 3 is used). With that the "default"
behavior of the module is checked.
* It is ensured that the PHP interpreter for Nextcloud's php-fpm
actually loads the correct openssl extension.
* It is tested that (encrypted) files remain usable when (temporarily)
installing OpenSSL3 (of course then they're not decryptable, but on a
rollback that should still be possible).
Finally, a few more documentation changes:
* I also mentioned the issue in `nextcloud.xml` to make sure the issue
is at least mentioned in the manual section about Nextcloud. Not too
much detail here, but the relevant option `enableBrokenCiphersForSSE`
is referenced.
* I fixed a few minor wording issues to also give the full context
(we're talking about Nextcloud; we're talking about the PHP extension
**only**; please check if you really need this even though it's
enabled by default).
This is because I felt that sometimes it might be hard to understand
what's going on when e.g. an eval-warning appears without telling where
exactly it comes from.
Building readline extension would say:
checking for libedit readline replacement... yes, shared
even when configuring `--without-libedit`. This is because `PHP_ARG_WITH(libedit, …)`, internally calls `PHP_ALWAYS_SHARED`, which in `phpize`-generated `configure.ac` is defined as always forcing the value to shared. This will prevent `PHP_ARG_WITH(readline, …)` from being invoked so `READLINE_DIR` variable will never be defined.
This was not an issue before we split the extension out of php.unwrapped in 282337799b, as `PHP_ALWAYS_SHARED` is empty there.
-----
Additionally, because the build script passed `-L$READLINE_DIR/lib` as a flag to the compiler on PHP < 7.4 (built by the nix-phps repository), this ended up with a FHS-like path being passed to the linker. And once we bumped GCC to 11 in 52f8cf58a4, the linker would fail:
gcc -shared .libs/readline.o .libs/readline_cli.o -Wl,--rpath -Wl,/lib -L/lib -ledit -lncurses -Wl,-soname -Wl,readline.so -o .libs/readline.so
impure path `/lib' used in link
collect2: error: ld returned 1 exit status
This no longer happens with PHP ≥ 7.4, since they switched to getting the linker flags from pkg-config in b537203d20.
----
As a compromise, let’s make the `PHP_ALWAYS_SHARED` function force `shared` status but only for flags that are not disabled. That will allow us to remove the libedit dependency and also the nasty patch for configure script due to `--with-libedit` not being passed (which would be required for PHP < 7.4 to be able to find readline.h from libedit).
Thanks to Pol Dellaiera for both bisections.
PHP obtained from Git contains files directly in the top-level directory,
which will be placed in Nix store. The generic builder will then copy it
to the /build sandbox as its basename with hash stripped (e.g. source/).
This breaks the assumption of `mkExtension`, which expects that PHP’s
source will be extracted into `php-«version»/` directory, since that
is what the release tarballs contain.
Let’s unset the `sourceRoot`, leaving it to `unpackPhase` to find
the source directory. Then, we will be able go to the extension
directory from there.
We use custom pre-configure phase so that both `postPatch` and
`preConfigure` is available to consumers.
