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. |
||
---|---|---|
.. | ||
administration | ||
configuration | ||
development | ||
installation | ||
release-notes | ||
contributing-to-this-manual.chapter.xml | ||
README.md |
This directory is temporarily needed while we transition the manual to CommonMark. It stores the output of the ../md-to-db.sh script that converts CommonMark files back to DocBook.
We are choosing to convert the Markdown to DocBook at authoring time instead of manual building time, because we do not want the pandoc toolchain to become part of the NixOS closure.
Do not edit the DocBook files inside this directory or its subdirectories. Instead, edit the corresponding .md file in the normal manual directories, and run ../md-to-db.sh to update the file here.