David, thank you so much for the thorough historical explanation, I'm learning a lot on this list! I'm just an OpenBSD newbie, but I've been using softraid crypto since my first installation. Just to be sure. As I tried to explain in my previous email, I've found a second solution that doesn't imply creating/destroying mfs on each "pass edit". It leaves /tmp permanently mounted as mfs in fstab (to reduce writes to my SSD). It involves root only for creating/deleting a symbolic link named /dev/shm to /tmp. Probably, all this might not even be necessary in my set-up, because pass, after the annoying warning, proceeds to write the file to /tmp anyway, which in my case is on mfs. If I understand it correctly, mfs is a sort of RAM disk and is therefore erased when the computer is shut down. Right? David
Ps Perhaps what I'm writing is all newbie nonsense. In which case, I apologize for my ignorance. Il mer 12 ago 2026, 00:01 David Dahlberg <[email protected]> ha scritto: > David, > > Thanks for your explanation. I will come back to experiment with it, when > I am back from holidays. > I have to have another try updating my ports anyways. > > A bit of history: > > A couple of years ago, we had tmpfs(8), which I used in the password-store > port as a substitute for /dev/shm. tmpfs(8) was removed in favour of > mfs(8), but mfs has the disadvantage (for the pass use-case) that it > requires root. So creating/destroying a mfs on each `pass edit` is not > really viable. > > Writing a ports readme about creating a mfs at /dev/shm is something that > could definitively be done, but lets try to recap at what Jason tried to > achieve with writing temp files in /dev/shm: > > Pass requires a temp file for editing, as it works with files and your > favourite $EDITOR, which also required files. Jason was not happy with just > and removing a file since flash memory might use wear levelling and rm > -P/shred might overwrite a different physical block. > > So if you have a privileged attacker, they can read your tempfile while it > is not yet deleted and you're screwed anyways. If you‘re working on ramdisk > or classic magnetic memory, youre probably okay. If your're on softraid > crypto, you're also okay, since the attacker would either need the key, or > get privileged access, but then we're back at 1. > > So if I got this right, mfs may help you exactly when you're working on > unencrypted ssd/flash and the attacker may get physical access to the > media. Correct? > > Honestly, if physical access is the threat, I'd recommend to encrypt your > disk, rather than using mfs just for deleted temporary password files. But > FDE would not silence the warning. Of course, I could patch this warning > out - but in some edge cases, there MIGHT indeed be a risk, and IMHO users > should know. > > What do you think? > > David >
