Re: GnuPG and Windows XP Home

2009-03-17 Thread Alf Wernersson
John Clizbe skrev: > Alf Wernersson wrote: >> I'm trying to install GPG on my Laptop running XP Home. After the >> install process I run CMD and write "GPG --version". This seems to be >> OK. After that I write "GPG --list-keys and receive following message: > >> Does not GPG4win support Windows X

Using GPG in embedded applications?

2009-03-17 Thread Bo Berglund
Is it possible to use GPG encryption in embedded applications? I would like to protect data passing from a PC over to an embedded computer unit via an unsecure channel (TCP/IP or USB) such that when it passes in the transfer line it will be GPG encrypted. The idea is to have the PC program encry

Re: GnuPG and Windows XP Home

2009-03-17 Thread Werner Koch
On Tue, 17 Mar 2009 09:14, awer...@glocalnet.net said: > "Fatal Error in GPGME library > (invoked from file > /home/wk/src/gpg4win11/build/gpg4win-1.1.4/src/playground/build/gpa-0.8.0/srd/confdialog.c, > line 1447): > Unsupported protocol Please re-install and also select the "gnupg2" component.

OT: file operations atomicity (was: Re: Re: gpg doesn't fail on target file existing when decrypting)

2009-03-17 Thread Sven Radde
Hi! Andrew Flerchinger schrieb: >> 1. Use mktemp to safely create a new, unique file >> 2. Send the decryption output to that file >> 3. Test if the "real" file exists, and if so unlink it >> 4. mv $newfile $realfilename >> > You're right, I could do that to make my work-around act atomic. Be

Re: Using GPG in embedded applications?

2009-03-17 Thread David Shaw
On Mar 17, 2009, at 8:24 AM, Bo Berglund wrote: Is it possible to use GPG encryption in embedded applications? I would like to protect data passing from a PC over to an embedded computer unit via an unsecure channel (TCP/IP or USB) such that when it passes in the transfer line it will be GP

Re: gpg doesn't fail on target file existing when decrypting

2009-03-17 Thread Andrew Flerchinger
On Mon, Mar 16, 2009 at 5:59 PM, Doug Barton wrote: > You're approaching this problem from the standpoint of unattended > usage, which is not how the current command line behavior was intended. > > > Doug > Okay, I can work around it in a satisfactory fashion. My personal problem is solved. Now,