On Sat 2025-03-22 17:06:12 -0700, Soren Stoutner wrote: > 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).”
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?
--dkg
signature.asc
Description: PGP signature
