Recently, otpclient started complaining to me about the memory limits.
if `~/.config/otpclient.cfg` does not contain:
```
show_memlock_warning=false
```
then i get a modal dialog when starting it up that says:
```
Warning: memlock value too low
------------------------------
Your operating system's memlock limit (8388608 bytes) may be too low.
This could cause the program to crash or, worse, use insecure
memeory.Please review the [secure memory wiki
page](https://github.com/paolostivanin/OTPClient/wiki/Secure-Memory-Limitations)
before using this software with the current settings.
[ ] I confirm that I want to use the current, possibly too low, memlock
value. Do not show this warning again.
[ Exit ] [ OK ]
```
Indeed, the limit for my user account is 8MiB:
```
0 dkg@bob:~$ ulimit -a | grep locked
max locked memory (kbytes, -l) 8192
0 dkg@bob:~$
```
I have not changed this recently, so i don't know why the warning would
start showing up now.
If an upgrade of some other part of the system might have changed this
default, feel free to reassign this bug report to the other package and
note that it affects otpclient.
Overall, i think warnings like this are harmful if they're not obviously
actionable -- they tell the user that maybe something scary is
happening, but not really what they should do about it.
Also, it's unclear to me why otpclient would need to lock up more than
8MiB of RAM; and it's not even clear to me what defense memory locking
provides in 2025 -- for example, when running within a VM i think the
hypervisor can still have access to even locked memory.
Can we make this friendier/less scary/more fixable for users?
There is some information as to why this is important in the upstream README. “Please note that the memlock value should be >= 64 MB. Any value less than this may cause issues when dealing with tens of tokens (especially when importing from third parties backups).” https://github.com/paolostivanin/OTPClient
Thanks for highlighting this section of upstream documentation, Soren. But this doesn't really answer my underlying question. First, it presumes that memory locking is meaningful and important for otpclient. But that's begging the question, i think. Are they concerned about data being written to swap? about other processes on the same system stealing underlying secret key material? some other risk? what about system hibernation? what about running in a VM where the full memory image is dumpable? Secondly, i get the scary, difficult-to-act-on warning *no matter what*, whether i'm dealing with one token or a hundred, whether i'm restoring from backup or just getting a token from one of my credentials. I continue to think that the "cure" here (a scary and difficult-to-act-on complaint) is worse than the disease. Perhaps we can have show_memlock_warning set to false by default, and only if the user explicitly sets it to true *and* the size of the capacity is low does the warning show up?
On Wednesday, April 2, 2025 11:18:36 AM Mountain Standard Time Daniel Kahn Gillmor wrote: Those are good points. My recommendation would be to take them up with upstream. Whatever resolution is warranted, it is something that should be done in the upstream code.
OK, i've forwarded the concern upstream. Thanks, Soren!
It looks like the otpclient package could change the default maximum memlock for all users by installing a config file in /etc/systemd/ user.conf.d. There are two memlock values, one for root and one for other users. The current value for root can be read from /proc/1/limits. On my system it is: Limit Soft Limit Hard Limit Units Max locked memory 8109957120 8109957120 bytes The current value for a non-root user can be read from /proc/2/limits. On my system it is: Limit Soft Limit Hard Limit Units Max locked memory 8388608 8388608 bytes The values for these can be changed in the files /etc/systemd/ system.conf and /etc/systemd/user.conf and in the directories /etc/ systemd/system.conf.d and /etc/systemd/user.conf.d. [Manager] #DefaultLimitMEMLOCK=8M This would change the value for all users on the system. Although as mentioned in the following bug report, there is probably no difficulty in doing so, it might be worth asking the systemd maintainer if they think there would be an issue with an override. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1103856 For the sake of completeness, this value is set by the Linux kernel, can be reset by systemd, and can also be overwritten by pam for particular groups using /etc/security/limits.conf, which is shipped in libpam-modules. In the past, pam used to override this value by default, but recently stopped doing so.
It looks like the otpclient package could change the default maximum memlock for all users by installing a config file in /etc/systemd/ user.conf.d. There are two memlock values, one for root and one for other users. The current value for root can be read from /proc/1/limits. On my system it is: Limit Soft Limit Hard Limit Units Max locked memory 8109957120 8109957120 bytes The current value for a non-root user can be read from /proc/2/limits. On my system it is: Limit Soft Limit Hard Limit Units Max locked memory 8388608 8388608 bytes The values for these can be changed in the files /etc/systemd/ system.conf and /etc/systemd/user.conf and in the directories /etc/ systemd/system.conf.d and /etc/systemd/user.conf.d. [Manager] #DefaultLimitMEMLOCK=8M This would change the value for all users on the system. Although as mentioned in the following bug report, there is probably no difficulty in doing so, it might be worth asking the systemd maintainer if they think there would be an issue with an override. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1103856 For the sake of completeness, this value is set by the Linux kernel, can be reset by systemd, and can also be overwritten by pam for particular groups using /etc/security/limits.conf, which is shipped in libpam-modules. In the past, pam used to override this value by default, but recently stopped doing so.
Thanks for this detective work, Soren! Do you have a pointer to the recent change in PAM? It would be interesting to know why they stopped overriding this, as well as why they started overriding it in the first place.
On Friday, April 25, 2025 2:53:56 PM Mountain Standard Time Daniel Kahn Gillmor wrote: It is mentioned here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976373#14 You would probably have to ask Sam Hartman <hartmans@debian.org> for more information as to why.
Hi, [...] Is there any news? I would have hoped this to be fixed for trixie. There actually seem to be 2 issues: 1. A warning is displayed even though the limit will not necessarily be reached. This has been fixed upstream; see upstream bug and commit: https://github.com/paolostivanin/OTPClient/commit/d5f1e4f3cf15cf2067d46a5ee1740f1a0f5b2544 Only show memlock warning dialog when secure memory is unavailable This change ensures that secure memory availability is checked on demand. The warning dialog with a link to the wiki is now only displayed if there isn't enough secure memory available, avoiding unnecessary interruptions when everything is correctly configured. 2. The limit may really be too low (I suppose that if a warning is displayed, this means that this limit is likely to be reached, at the point that it should be increased). Note that the upstream bug does not mention any memory improvement. So I suppose that the limit should also be increased.