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
