Hi Ryan,
Yes that is exactly the kind of front end I was looking for, and it
looks very nice. Thanks for writing it. :-) Though now I have finished
the stab I took at solving the problem myself, which is a much simpler
command line script. You can find the two versions of it here:
https://www.eugenemakerspace.com/wiki/Sites/Cryptsym
If folks have the time, I would appreciate any feed back on how they
like it.
Ciao!
Clif
On 01/21/2014 09:28 AM, Ryan Sawhill wrote:
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
