Operating system and version (e.g., Ubuntu 24.04):
Ubuntu 22.04.4 LTS
Web server and version (e.g, Apache 2.4.25):
Apache/2.4.52
PHP version (e.g, 8.3):
8.2.26
Is this the first time you’ve seen this error? (Yes / No):
It’s not an error
When did this problem seem to first start?
As soon as I started using the passwords app
Installation method (e.g. AlO, NCP, Bare Metal/Archive, etc.)
Cloudron
Summary of the issue you are facing:
Searching for passwords or opening the “All” or “Recent” shortcuts is very slow on my system. Also each time I unlock the browser plugin it takes a long time before passwords are displayed.
When looking at htop on the server I can see that there is one apache processes using around 100% cpu during the search operation (“All” and “Recent” are implemented as a search I guess?). The other apache processes don’t use any extra cpu at that time.
So the issue seems to be that the action being performed (decryption) is cpu intensive and for some reason only single threaded, even if there are multiple cpu cores available on the server.
I’m aware of this forum topic where @mdw suggests to enable e2e encryption because server side encryption is slow because it’s single threaded.
While I understand the reasoning, I’m very hesitant to disable server side encryption because e2e encryption gets disabled as soon as a password is being shared with others, putting the password in an unencrypted state!
So is there any way to make the passwords app faster without sacrificing security?
Unfortunately upgrading to more powerful hardware isn’t a solution since the decryption process won’t utilize the additional hardware anyway.
Steps to replicate it (hint: details matter!):
open htop on the server and notice that there are 3 apache2 processes, all using between 0% and 5% cpu
open the “All” or “Recent” shortcut in the passwords web interface
look at htop again and notice that there is an extra apache2 process that’s using around 100% of the cpu
I’ve noticed a bunch of stuff is slow in the passwords app. Even accessing favorites takes a while, and when you star/unstar items there is a noticeable delay. It appears to be working just fine but feels a bit broken.
The chrome extension also doesn’t seem to update very quickly. I noticed that a password had changed in Nextcloud was not available right away in chrome.
That’s incorrect, E2E encryption for that password is disabled making the app fall back to server side encryption.
In general PHP itself is not multi-threaded. So a single request will only run on a single thread. The app also configures itself to limit the amount of requests made to the server, especially for low end hardware like a raspberry pi.
Correct. The browser extension syncs periodically instead of querying the server for every interaction which makes the extension react much faster.
Thanks for the feedback.
However, how can the app fall back from e2e to server side encryption when a password is shared if server side encryption is disabled?
Server side encyption is not disabled. The app encrypts each item individually which also means the encryption method for each item can be decided individually. You can even configure this behavior in the expert settings in the app.
It’s currently not possible to share E2E encrypted passwords since the other person doesn’t have your encryption passphrase. So the app saves that password with server side encryption.
E2E can speed up the app, since less work is done on the server and more work is done on the client which can be faster especially when the client has a better single core performance.
Yes, but since server side encryption is the culprit you suggest (in the other topic) it should be disabled in favour of e2e.
But then, if a password is shared, e2e is disabled with a fall back to server side encryption but that fallback isn’t possible if I have to disable server side encryption, or is it?
I don’t get it.
If you use E2E, the app will by default not apply server side encryption to these E2E encrypted passwords. That means that these passwords don’t need to be decrypted on the server before being sent to the client.
If you then share a password, the client side will remove the E2E from that one password and save it. The server side sees that and applies server side encryption to that one password.
And as mentioned in my initial post this results in very slow loading times.
So although I do have e2e enabled, the system still seems to be very busy decrypting passwords on the server side each time I’m requesting a filtered list of passwords.
