On Wednesday, April 2, 2025 11:18:36 AM Mountain Standard Time Daniel Kahn Gillmor wrote: > 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?
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. -- Soren Stoutner so...@debian.org
signature.asc
Description: This is a digitally signed message part.
