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.
* s/NextCloud/Nextcloud/g
* `enableBrokenCiphersForSSE` should be enabled by default for any NixOS
installation from before 22.11 to make sure existing installations
don't run into the issue. Not the other way round.
* Update release notes to reflect on that.
* Improve wording of the warning a bit: explain which option to change
to get rid of it.
* Ensure that basic tests w/o `enableBrokenCiphersForSSE` run with
OpenSSL 3.
conversions were done using https://github.com/pennae/nix-doc-munge
using (probably) rev f34e145 running
nix-doc-munge nixos/**/*.nix
nix-doc-munge --import nixos/**/*.nix
the tool ensures that only changes that could affect the generated
manual *but don't* are committed, other changes require manual review
and are discarded.
mostly no rendering changes. some lists (like simplelist) don't have an
exact translation to markdown, so we use a comma-separated list of
literals instead.
make (almost) all links appear on only a single line, with no
unnecessary whitespace, using double quotes for attributes. this lets us
automatically convert them to markdown easily.
the few remaining links are extremely long link in a gnome module, we'll
come back to those at a later date.
markdown can't represent the difference without another extension and
both the html manual and the manpage render them the same, so keeping the
distinction is not very useful on its own. with the distinction removed
we can automatically convert many options that use <code> tags to markdown.
the manpage remains unchanged, html manual does not render
differently (but class names on code tags do change from "code" to "literal").
the conversion procedure is simple:
- find all things that look like options, ie calls to either `mkOption`
or `lib.mkOption` that take an attrset. remember the attrset as the
option
- for all options, find a `description` attribute who's value is not a
call to `mdDoc` or `lib.mdDoc`
- textually convert the entire value of the attribute to MD with a few
simple regexes (the set from mdize-module.sh)
- if the change produced a change in the manual output, discard
- if the change kept the manual unchanged, add some text to the
description to make sure we've actually found an option. if the
manual changes this time, keep the converted description
this procedure converts 80% of nixos options to markdown. around 2000
options remain to be inspected, but most of those fail the "does not
change the manual output check": currently the MD conversion process
does not faithfully convert docbook tags like <code> and <package>, so
any option using such tags will not be converted at all.
There is a comment above the invocation of 'nextcloud-occ app:enable', stating
that the script should not fail if any of the apps cannot be enabled, but there
is nothing in place to suppress errors. The app:enable command already
continues installing the remaining apps when one fails to install, and we do not
want to suppress errors in the setup script, so this just removes the comment
about not failing.
* Add an option services.nextcloud.nginx.hstsMaxAge for setting the max-age
directive of the Strict-Transport-Security HTTP header.
* Make the Strict-Transport-Security HTTP header in the Nginx virtualhost block
dependant upon the option services.nextcloud.https instead of
services.nextcloud.nginx.recommendedHttpHeaders, as this header makes no sense
when not using HTTPS. (Closes#169465)
Added Nextcloud 23 and set it as the default Nextcloud version for the
NixOS module. Added PHP 8.1 as an option for phpPackage and default for
Nextcloud ≥ 24.
I recently learned that Nextcloud 23's new profile feature — basically a
way for users to share personal contact details — has a problematic
default setting, profile data is shared with **everyone** by default.
This means that an unauthenticated user can access personal information
by accessing `nextcloud.tld/u/user.name`.
The announcement of v23 states[1]:
> We go a step further and introduce a profile page. Here you can put a
> description of yourself, show links to, for example, social media, what
> department you are in and information on how to contact you. All these
> are of course entirely optional and you can choose what is visible to who!
> The profile and user status are accessible also from our mobile and desktop clients.
It's not mentioned that by default you share personal information[3] with
everyone and personally I think that's somewhat problematic.
To work around that, I decided to add an option for the recently added[2]
and even set it to `false` by default to make an explicit opt-in for
that feature.
[1] https://nextcloud.com/blog/nextcloud-hub-2-brings-major-overhaul-introducing-nextcloud-office-p2p-backup-and-more/
[2] https://github.com/nextcloud/server/pull/31624/files
[3] By default, this affects the following properties:
* About
* Full name
* Headline
* Organisation
* Profile picture
* Role
* Twitter
* Website
Phone, Address and Email are not affected and only shown to
authenticated users by default.
