While reviewing this I got bit by the fact that

services.cryptpad = {
enable = true;
settings = { /* foo */ };
}

ignores the specified settings.

I wonder if we should do the following:

• make the default value of configFile null (the example config file can be an example)
• add an assertion that exactly one of configFile and settings is set to a non default value.

Otherwise I tested it and it works.

I noticed while reviewing that I had the following warning:

juin 16 21:46:22 blitiri cryptpad[23293]: FRESH MODE ENABLED
juin 16 21:46:22 blitiri cryptpad[23293]:     m     m   mm   mmmmm  mm   m mmmmm  mm   m   mmm    m
juin 16 21:46:22 blitiri cryptpad[23293]:     #  #  #   ##   #   "# #"m  #   #    #"m  # m"   "   #
juin 16 21:46:22 blitiri cryptpad[23293]:     " #"# #  #  #  #mmmm" # #m #   #    # #m # #   mm   #
juin 16 21:46:22 blitiri cryptpad[23293]:      ## ##"  #mm#  #   "m #  # #   #    #  # # #    #
juin 16 21:46:22 blitiri cryptpad[23293]:      #   #  #    # #    " #   ## mm#mm  #   ##  "mmm"   #
juin 16 21:46:22 blitiri cryptpad[23293]: No 'httpSafeOrigin' provided.
juin 16 21:46:22 blitiri cryptpad[23293]: Your configuration probably isn't taking advantage of all of CryptPad's security features!
juin 16 21:46:22 blitiri cryptpad[23293]: This is acceptable for development, otherwise your users may be at risk.
juin 16 21:46:22 blitiri cryptpad[23293]: Serving sandboxed content via port 3001.
juin 16 21:46:22 blitiri cryptpad[23293]: This is probably not what you want for a production instance!
juin 16 21:46:22 blitiri cryptpad[23293]: Cryptpad is customizable, see customize.dist/readme.md for details

and yet I did provide 'httpSafeOrigin'.
i think this is fixed by cryptpad/cryptpad@9b30132
It looks like the warning is harmless.

It looks like cryptpad should be updated. (but not in this PR, I just mention this for potential reviewers).

The only problem with using null by default is that the [new] defaults have to pulled in manually each release (if there are any new options).

We would have to do this as well for the default value of the settings option...

I see settings being used when the user probably knows exactly what options to set/enable. Ideally settings would pull in the new defaults if there were any, which should probably happen but not guaranteed, so using the bundled config file is probably still better.

This distinction does not strike me as obvious, but ok.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/cryptpad-is-this-a-bug-or-must-i-configure-something/9100/2

How about making settings nullable rather than configFile, and use settings if it is not null.

Functions as expected, but does require a significant nginx config get full function. See http://cgit.notk.org/asmadeus/nixos-config.git/tree/machines/jormungand

@eadwu is there still interest in this? Or would want to use an RFC42-style approach?

Well I can fix it up, but it probably doesn't matter since there doesn't seem to much interest anyway.

@eadwu Oh, thanks for starting this! I am very much interested!

@eadwu @tomberek
I have tried it out, and it works as expected (although setting up nginx is quite a pain).

I have made some minor adjustments, that could be integrated to this PR:
https://github.com/Pamplemousse/nixpkgs/commits/PR_89384

I marked this as stale due to inactivity. → More info

I am also interested, since this would allow more programmatic nginx configuration.

For some reason that I can't find, cryptpad has been removed from nixpkgs.

Therefore, closing this PR.

We could restore it if we want to, cryptpad is now using NodeJS 16... but NodeJS 16 is EOL in 3 months. Maybe we should revisit this as soon as they switched to NodeJS 18.

We could restore it if we want to, cryptpad is now using NodeJS 16

I remember that the main painpoint in packaging cryptpad was that they use bower to bundle their front-end dependencies. As far as I can remember, bower was introducing the dependency on node 12...

And so far, no hints on their part in getting rid of it: cryptpad/cryptpad#295 (comment) .