-
-
Notifications
You must be signed in to change notification settings - Fork 14.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
nextcloud25: use openssl 1.1 as a PHP extension to fix RC4 encryption #198470
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM but I'll let the seniors approve it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I hate this, but we probably don't really have another choice. Or rather, I don't see how using openssl_3
and enabling legacy ciphers is better. Let's just hope upstream manages to fix this sometime soon.
What we could do is make this an option and add it to the release notes. That's probably not a better solution either.
I'd love to get some more opinions from some nixos nextcloud and php people.
We can get this behind a flag to be fair and let people enable it when they need it plus letting people who really want server side encryption complain. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👎 from me. I'm pretty sure that this is not the only occurrence in the codebase where PHP's openssl extension is used. If that's the case I don't want to disable OpenSSL 3 for everyone using Nextcloud (just because some people have that security theatre enabled).
I'm fine with merging that, but only if the behavior is hidden behind a flag that's called e.g. enableBrokenCiphersForSSE
(and yes, the option's name should reflect the fact that you're using broken ciphers IMHO).
ae0d256
to
fb174fc
Compare
Totally agreed and asked for some opinions in Matrix chat beforehand regarding this, and I was open to this precise solution. :) (just took the easiest way to not do useless work). This is now done, I may have been a bit aggressive with the message, let me know your thoughts on them. |
@mweinelt do you think I should add more notes in the release notes? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Beautiful!
Question for my own information: Shouldn't enableBrokenCiphersForSSE
be a global flag in nixpkgs
?
We enable the OpenSSL 1.x replacement only for this very NixOS module, therefore, it does not prevent anyone from using a NextCloud using OpenSSL 3.x locally, does not prevent anyone from replacing our module with a smarter module for anything I cannot even imagine, etc. I think very local replacements like this one are ideal, esp. to let advanced users be able to do whatever they want and keep composability. If a user want to port our mechanism to patch, I provide for a fake OpenSSL PHP Extension called |
fb174fc
to
3d833c5
Compare
OK, found another small thing to be fixed before merging, please don't do that right now. I guess to be safe, I should implement a VM test for that. |
* 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.
Rebased onto Considering that this now touches PHP stuff and I contributed quite a bunch of stuff in here, I'd like to have more reviewers. |
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.
@ajs124 fixed :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As for the changes to the php packages I think this looks fine
cc @NixOS/release-engineers @NixOS/nixos-release-managers this should really land in 22.11. Would be cool to get a few more reviewers here first, though. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wow, that's some thorough testing.
{ | ||
name = "openssl-legacy"; | ||
extName = "openssl"; | ||
buildInputs = [ openssl_1_1 ]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With #202126, this can probably be replaced with openssl_legacy
. Doesn't make a big difference, but might be useful, depending on how long we need to keep this around.
A fix for the root issue is coming up in Nextcloud 26 : nextcloud/server#32003 (comment) Tagging maintainers of Nextcloud so that they be notified about this coming change : I guess this fix needs a tweak so that it can only be used on Should I be trying my hand at making a PR to adapt the Nextcloud module to take into account that fix should be allowed to run only on NC25 and lower versions. And ignore the fix for NC26 by using the function I'd guess some testing would be needed to make sure nothing breaks down on NC26, there are only beta version of the server, so testing will have to wait and will be possible when NC26 stable or a release candidate is out. tl;dr : |
I wouldn't call it a fix for the root issue though, rather working around the root cause ;-)
We don't have nc26 yet, so I guess, no action needed here until the release is out. Thanks for the heads-up, I'll adapt the module then accordingly. Of course, if you're faster when it's out, I won't stop you from filing a PR. |
nc26 is released now (with this patch nextcloud/server#36173 merged) |
We already adapted NC26 IIRC. We still need our workaround for NC25 as long as it is a supported version. |
I think it still uses openssl-legacy with NC26, at least I couldn't find anything for that in
it should probably be an assertion (assert NC < 26 or !enableBrokenCiphersForSSE) |
I want to upgrade from NixOS 22.11 to 23.05 with Nextcloud installed. I get the output:
Unfortunately there is no mention at all of Nextcloud, even though it seems to be the problem. I only found it with an invocation from #210452 (comment) cd /etc/nixos
NIXPKGS_ALLOW_INSECURE=1 nix-instantiate --strict "<nixpkgs/nixos>" -A system which prints:
It would be good if |
This isn't a problem with Nextcloud's packaging, but with how warnings currently work in nixpkgs (the problem appears with every dependant of openssl 1.1.1 on 23.05 and later), this might be subject to change with https://github.com/NixOS/rfcs/pull/127/files though. In other words, this is IMHO the wrong place to report the issue because it's not a problem with this package and this is effectively necro-bumping an old PR (this wasn't a problem when this change was merged). In other words, please file a new issue for that :) |
Description of changes
NextCloud encryption is RC4-based, when moving to NextCloud 25 and OpenSSL3, NC cannot decrypt the files anymore, see #197726.
This adds a
openssl-legacy
PHP extension that can be used for these scenarios where OpenSSL 1.1 is easier to use.Another solution is to provide a custom
openssl.cnf
file to re-enable RC4 encryption to OpenSSL 3, I will open such a PR soon, but it will might be a bit uglier than this one.cc @mweinelt @Ma27 @AkechiShiro
Things done
sandbox = true
set innix.conf
? (See Nix manual)nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD"
. Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/
)nixos/doc/manual/md-to-db.sh
to update generated release notes