Certain software stacks have no support for OpenSSL non-standard PEM format and will fail to use
our NixOS CA bundle.
For this, it is necessary to fallback on a 'compatibility' bundle which will contain no additional
trust rules.
Signed-off-by: Raito Bezarius <masterancpp@gmail.com>
Portals are global so we can just link them globally.
There might, in theory, be some unexpected system-path contamination
(e.g. when a portal package installs its executables to `/bin`)
but I think the risk is relatively minor compared to the added complexity.
While at it, let’s point the environment variable to system-path.
That will allow changes to installed portals to apply without having to re-log in.
x-d-p only looks for portal definitions in one of two places:
- datadir (which we cannot install anything to, since Nix packages are immutable)
- when `XDG_DESKTOP_PORTAL_DIR` environment variable is set, the path specified therein
(meant for tests, disables looking for portal configuration anywhere else)
Let’s introduce our own `NIX_XDG_DESKTOP_PORTAL_DIR` environment variable
that will only control the portal definitions lookup.
We will not use it for searching for configuration
because it would require looking in the parent directory
and `XDG_CONFIG_DIRS` variable is sufficient for us.
since this is no longer supported and we have a dedicated module for
forgejo for quite some time now.
Such warning is, however, becoming more and more important, since
forgejo is no longer a soft-fork of gitea, but rather a hard-fork.
And as such, it will slowly but surely no longer be a drop-in
replacement.
Additionally, I hope that this warning will prevent users from
reporting issues with forgejo to nixos/gitea maintainers.
The accompanying forgejo.md, from which the manual section is created,
will be updated over the next few weeks when forgejo officially
publishes their blog post about all this and the way forward, so we can
link to it.
PR #277382 didn't fix just an issue with .mjs files for the `forms` app,
but an underlying, more problematic issue: for `/nix-apps` &
`/store-apps`, the fcgi config for PHP and the block for assets were
never reached.
That meant that e.g. `/nix-apps/notes/lib/AppInfo/Application.php`
returned the PHP source code as text/plain. Considering that there was
never a fundamental change to how this config's structure, I'm pretty
sure that the issue was pretty much there since the module exists.
After consulting the NixOS security team we agreed that this is most
likely harmless because you'd have to use private apps with secrets in
the raw PHP code of said app. However, this is still problematic because
one important assumption - that PHP code is never sent to the browser -
is broken which is why we decided on not mentioning this impact in the
previous PR from December 2023.
To make sure that we don't regress our nginx config, I decided to add
the reproducer which fails on 8bbbb228b4
as testcase to our integration tests.
