Apparently epg runs temporary decryption through whatever the temporary-file-directory is set to. This is /tmp by default and that is not ideal, to say the least. This means that Emacs gpg decryptions litter the /tmp directory with plaintext copies of your gpg files (during a small window when opening or saving).
It does this with a predicatable pattern gpg-output or gpg-input since age.el is a port of epg functionality, it has the same weakness.
As a stopgap, age.el will run these operations through /dev/shm when and where it is available. I'll think about how we can do a buffer-only operation, since in our threat model limiting our plaintext exposure to emacs memory contents is the best we can hope for. While someone that has user privileges to monitor e.g. /dev/shm for file creations can obviously also dump memory from the emacs process, this would be a more annoying proposition than placing a filewatch and harvesting plaintext copies of decrypted files out of a temporary directory.
Making these intermediate writes at least remain memory resident as opposed to disk resident when /dev/shm is an option is a reasonable first step I reckon.
I'll note that memory contents can/will be flushed to disk in a variety of scenarios, but I don't like the idea of such a simple harvesting mechanism being available by default.
I think I should be able to just rework it such that everything runs over process stdio as opposed to intermediate plaintext files.
Apparently epg runs temporary decryption through whatever the temporary-file-directory is set to. This is /tmp by default and that is not ideal, to say the least. This means that Emacs gpg decryptions litter the /tmp directory with plaintext copies of your gpg files (during a small window when opening or saving).
It does this with a predicatable pattern gpg-output or gpg-input since age.el is a port of epg functionality, it has the same weakness.
As a stopgap, age.el will run these operations through /dev/shm when and where it is available. I'll think about how we can do a buffer-only operation, since in our threat model limiting our plaintext exposure to emacs memory contents is the best we can hope for. While someone that has user privileges to monitor e.g. /dev/shm for file creations can obviously also dump memory from the emacs process, this would be a more annoying proposition than placing a filewatch and harvesting plaintext copies of decrypted files out of a temporary directory.
Making these intermediate writes at least remain memory resident as opposed to disk resident when /dev/shm is an option is a reasonable first step I reckon.
I'll note that memory contents can/will be flushed to disk in a variety of scenarios, but I don't like the idea of such a simple harvesting mechanism being available by default.
I think I should be able to just rework it such that everything runs over process stdio as opposed to intermediate plaintext files.