OpenPGP / GnuPG notepad recommendations?

GnuPG notepad recommendations?

1. I’m not trying to dismiss a powerful editor / IDE like emacs, vi or even VS Code and the other Electron behemoths, but think of giving such an editor to a non-technical family member… How would that work out?

   With regard to setting it up, I think it’s simpler if I just write a bash script and tie that to the xdg-open, then just decrypt to a temporary file, open a simple editor, wait for it to exit, and if the file was changed, just re-encrypt it.

   However, this is such a simple use-case, I can’t believe there isn’t more easier tooling than all these… It should be implemented right into the gpg tool like gpg --edit-file ./secret.asc.

   1. x64k

      1 hour ago

      | link

      I’m not trying to dismiss a powerful editor / IDE like emacs, vi or even VS Code and the other Electron behemoths, but think of giving such an editor to a non-technical family member… How would that work out?

      In my experience, and I know I’m going to get flak for it, if you’re giving them a Linux machine, it’s already going to work out rather poorly :-D.

      My experience with non-technical people trying to use Emacs is that, as long as they stay away from anything other than Open File, Save, Save As, Undo/Redo and the like, it works okay. But, yeah, something simpler would definitely be ideal.

      I’m not surprised simpler tools aren’t easily available tbh. Anyone who’s tech-savvy and patient enough to put up with GPG is probably tech-savvy and patient enough to write their own editor if need be. In ASM. For their own processor. Which they made from scratch by sculpting grains of sand. GPG is really horrifying. I wouldn’t use it if it weren’t for Emacs.

      With regard to setting it up, I think it’s simpler if I just write a bash script and tie that to the xdg-open, then just decrypt to a temporary file, open a simple editor, wait for it to exit, and if the file was changed, just re-encrypt it.

      Oh, absolutely, if having a temporary, unencrypted copy of the file isn’t a problem, this is 100% okay. IMHO this is okay for pretty much any “normal person who’s not on the FBI watchlist and wants to keep a diary” kind of threat model. The unencrypted copy is trivial to retrieve but if you’re mainly concerned about things like laptops getting stolen, it’s probably enough.

      1. I’m not surprised simpler tools aren’t easily available tbh. Anyone who’s tech-savvy and patient enough to put up with GPG is probably tech-savvy and patient enough to write their own editor if need be.

         Now that you’ve mentioned it, I do have my own editor sce. :) So, at least I’m another data-point for your conjecture. :)

         ---

         Oh, absolutely, if having a temporary, unencrypted copy of the file isn’t a problem, this is 100% okay. IMHO this is okay for pretty much any “normal person who’s not on the FBI watchlist and wants to keep a diary” kind of threat model. The unencrypted copy is trivial to retrieve but if you’re mainly concerned about things like laptops getting stolen, it’s probably enough.

         Indeed, the threat-model here is having the laptop stolen, but you don’t have so much important data that it warrants full-disk-encryption. (Although it should still hold to a full disk dump and searching for strings.)

         Now about the recoverability of my proposed approach:

         • if one uses tmpfs without swap (or encrypted swap), it might be quite safe;
         • in Linux, there is also ramfs, a non-swappable variant of tmpfs (actually this was the first implementation, tmpfs came later), which doesn’t leak contents outside of the memory; (it’s also used by systemd to store “credentials” given to the various services;)

         However, and this is something else that made me wonder, why don’t editors allow reading from stdin, and on exiting writing on stdout what was edited? This is such a useful feature that would make temporary files needless for such a use-case. (For example, my own sce linked above, has this feature: if it detects that stdin / stdout are pipes, it reads / writes the “buffer”.)

         Which also brings me to the last point: general purpose editors are completely unsuited to handle “secret” data. They can leak it to disk by having their memory swapped, the console emulator / X11 can leak it to swap, etc. In fact, even the kernel can leak your data as it’s stored and passed through various buffers. (Does the kernel zero-out pages when mapping them to another process?)