Package Details: cryptpad 5.7.0-1

Git Clone URL: (read-only, click to copy)
Package Base: cryptpad
Description: Realtime collaborative visual editor with zero knowlege server
Upstream URL:
Keywords: collaborative
Licenses: AGPL3
Submitter: anonfunc
Maintainer: buzo
Last Packager: buzo
Votes: 9
Popularity: 0.007570
First Submitted: 2019-06-08 16:40 (UTC)
Last Updated: 2024-02-07 16:20 (UTC)

Dependencies (6)

Required by (0)

Sources (4)

Latest Comments

1 2 3 Next › Last »

RoKoInfo commented on 2021-09-11 08:48 (UTC)

@buzo @ChrisTX I see the cryptpad:http combinations for e.g. blob, however, the combination cryptpad:cryptpad and 0750 still does not allow read access for nginx for e.g. blob, so login is still prohibited in the current situation. At least on my machine, so please recheck. Thanks.

RoKoInfo commented on 2021-07-22 18:54 (UTC)

@buzo @ChrisTX This approach only works for me, if /var/lib/cryptpad is world readable. Otherwise I can not log in, aka I receive a "Permission denied" from nginx, when trying to read a block. Please check from your side.

buzo commented on 2021-07-09 10:43 (UTC)

Thanks ChrisTX – I've adjusted the permissions in the package as suggested.

RoKoInfo commented on 2021-07-01 19:11 (UTC)

Sorry, misleading description: groups http = http cryptpad and groups cryptpad = cryptpad. Gives http the theoretical access to some unneeded folders, but it is very simple. I do not think that this is a security issue, however, as soon as it is implemented in the package, I would follow the approach of choice there.

ChrisTX commented on 2021-06-29 20:16 (UTC)

No, I mean, cryptpad shouldn't be part of http. That will allow it to read all files available to the web services, a permission which it doesn't need to have. Disregarding POSIX ACLs, the only 'proper' way of doing this is changing ownership to cryptpad:http and then setting the setgid bit on each of the subfolders nginx needs to access. I've done that right now in my own setup, but the package should do that.

RoKoInfo commented on 2021-06-29 19:55 (UTC)

@ChrisTX Yes, you are right. I replaced again the LTS version with nodejs, and it seems to work. It is the read access of http to the folders you mention. Currently, I added http to the group cryptpad, which then allows for it, and which I think is not part of the PKGBUILD right now, right?

ChrisTX commented on 2021-06-29 12:27 (UTC)

@RoKoInfo No you're not wrong. The way cryptpad handles /blob and /block is by using try_files with nginx - so the server needs to be able to access those folders. Cryptpad should run fine with nodejs, and not require the LTS variant.

This is a bit of a mess, but the only reasonable solution I can see is to make the blob, block and datastore (that's for debugging purposes only tho) readable by nginx, i.e. http. Additionally, this will need the setgid bit on the folder. It's not necessary to make data or logs readable by nginx, they'll only be accessed by the nodejs service.

There's no real beautiful solution for cryptpad overall, as the app is supposed to be run in its source folder, and not really the way you'd package it.

RoKoInfo commented on 2021-06-20 10:32 (UTC)

Ok, I caught the trick: Use nodejs-lts-erbium instead of nodejs. So forget about the comments below.

RoKoInfo commented on 2021-06-05 12:57 (UTC)

If I change the directory rights of /var/lib/cryptpad to 770 and extend the service with UMask=0007, the error message changes to Can't remove login block, which seems to be again a 404 issue. The file is there, and the user http can delete it.

General question: Does it make sense to access /var/lib/cryptpad as http (nginx) instead of cryptpad (node)?

RoKoInfo commented on 2021-06-05 10:47 (UTC) (edited on 2021-06-05 10:48 (UTC) by RoKoInfo)

Unfortunately, I can not make this work. @buzo @ChrisTX Is this operational on your machines?

If I do a /checkup/, I get the message »Unable to create, retrieve, or remove encrypted credentials from the server.«, and a Can't read login block in the console, which seems to be reasonable to me, since the folder /var/lib/cryptpad is not accessible for nginx.

If I try a /login/, I get a 404 for the same reason, since nginx tries to access a URL .../block/... (although, however, the requested file is there).

How to fix this and leave the security measures (which I am not understanding fully) of Arch in place? Thank you in advance.