As already mentioned, you could decrypt the file to a ram disk -- the /dev/shm directory should already be there, but if you're trying to bypass creating an unnecessary file altogether, you need something else.
I actually wrote a GUI frontend for this purpose (among others) a while back. It's called pyrite and available at: https://github.com/ryran/pyrite It's extremely versatile and can do everything but manage keys -- basically you can do any kind of signing & verifying with or without any kind of encryption/decryption (including symmetric). Your workflow with it could look like this: 1.) Run pyrite /path/to/encrypted/file [GUI opens up with text-input populated by encrypted text] 2.) Decrypt text [Cipher-text is replaced with decrypted version; never saved to disk] 3.) Make your edits/changes 4.) Re-encrypt 5.) Click save-to-disk button On Sun, Jan 19, 2014 at 4:48 PM, Mr. Clif <c...@eugeneweb.com> wrote: > Hi Doug, > > Thanks for the comments. Yes the threat model is mostly the worry of having > old temp files or even the original cleartext files left behind on the HD, > or even worse having them backed up. ;-) At the very least I want something > that tries to protect me from stupid mistakes. Yep the RAM disk idea was > part of the solution I'm heading towards. > > So do you or does anyone know of a nice front end that helps with that? An > example of behavior that doesn't seem helpful is that when I use GPA to > decrypt a file it defaults to saving it on the HD. I'm not trying to knock > GPA here but wouldn't it be better to display the contents in a window? Well > I realize that might be just what I want, and others have use cases that it > works fine for. ;-) > > Clif > > > On 01/19/2014 01:23 PM, Doug Barton wrote: >> >> On 01/19/2014 08:56 AM, Mr. Clif wrote: >>> >>> So I'm trying to get a sense from the users here if they feel that the >>> process of using gpg for symmetric encryption is safe enough, and they >>> are not worried about leaving clear text behind. >> >> >> I think you're misunderstanding a few things. First, the problem of the >> plain text file is not exclusive to symmetric encryption. In fact there is >> no difference between that, and the plain text file that's left behind after >> public key encryption. >> >> Second, you haven't defined your threat model. You have given us a vague >> sense of wanting to have a "secure" system, but you haven't said what you're >> trying to secure it against. Thus it's hard to respond intelligently to your >> query. >> >> That said, I would suggest that you consider using a RAM disk to do your >> work on. It can be created to do the work, then deleted after you're done, >> with no risk of leaving a file behind on disk. Of course you'd want to make >> sure your RAM disk was not swap-backed. >> >> hope this helps, >> >> Doug >> > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
