Index > Scribe > GnuPG Plug-In: Didn't get any private keys ...
Author/Date GnuPG Plug-In: Didn't get any private keys ...
04/05/2005 4:14pm
My problem is that i couldn't use the latest GnuPG/AutoPG 0.51 PlugIn with I.Scribe 1.87. There's always an error message: "Didn't get any private keys. Exe: c:\GnuPG\gpg.exe".
My GnuPG 1.41 installation incl. keys is located in c:\gnupg.
The system path variable includes c:\gnupg.
The registry keys are ... gpgProgramm = c:\gnupg\pgp.exe, homedir = c:\gnupg, InstallDirectory = c:\gnupg.
Even if i specify the Home Dir variable in the plugin like "c:\gnupg" the error appears.
I don't know any further solutions.
Could you please help? I read the whole forum without finding a solution.

Besides: I won't miss this great program anymore. Many thanks for this one.
04/05/2005 11:41pm
Have you set the home directory in the plugin's settings?
04/05/2005 11:49pm
Yes, i have.
Under e.g. File/PlugIn/GnuPG/config/HomeDir c:\Gnupg.
Unfortunately anytime the same result: Didn't get... I'm desperate. ;-)
Kevin F. Quinn
19/05/2005 3:04pm
I get this error, "Didn't get any private keys. Exe: F:\Apps\GnuPG\gpg.exe", as well. Happens both on Windows and Linux (InScribe 1.88rc3, GnuPG plugin 0.51 win, 0.41 linux, gpg 1.4.0).

I've tried with the home dir empty, and with it set to path relative to the InScribe executable, and with a fully specified path to gpg.

It worked before on Linux by setting the GNUPGHOME environment variable before launching Scribe (something I added to the run-scribe script).

On windows I cooked up a batch script to set the registry key [HKEY_CURRENT_USER\Software\GNU\GnuPG] value "HomeDir" to help gpg find the home directory; I've tried this with forward slashes (as suggested by the win32 gpg docs), backslashes, but no luck (again, although I didn't use it much on win32 I think this worked before). gpg runs fine on its own in a command prompt so I'm confident the registry is being set ok.
19/05/2005 11:59pm
I found when looking at this that after you set the home directory (full path) in the gnupg plugin's options you have to close the plugin's config dialog (which saves the home directory option) and then reopen it and then it'll list the private keys in the user field.

The plugin is called gpg to list the keys like this:
gpg --homedir "some_path" --list-secret-keys

So you could try that at the command prompt and see what it outputs. If there are no keys listed then you'll need to adjust that first before the plugin will see them.
Kevin F. Quinn
20/05/2005 9:14am
The following work from the command prompt in Windows:

F:\Apps\GnuPG\gpg.exe --homedir F:\Data\gnupg --list-secret-keys
F:\Apps\GnuPG\gpg.exe --homedir ..\..\Data\gnupg --list-secret-keys
F:\Apps\GnuPG\gpg.exe --list-secret-keys

(the latter shows that the homedir entry in the registry is correct)

Behaviour in Linux is pretty much the same, i.e. absolute & relative paths work in the shell, omitting homedir uses the GNUPGHOME environment variable which is set correctly.

In all cases, scribe pops up the error dialog saying it can't get the private keys (including after closing the dialog with the path set correctly, then re-opened).

It's as if the launch of gpg is failing, rather than gpg running ok but displaying no keys.
20/05/2005 11:12am
Yeah, same result here.
In windows xp command prompt the keys are shown correct. But even when quiting the plug-in dialog after changing the variable won't work.
I suppose this is a matter of finding the gpg.exe - not the keys. Strange especially when the variables in registry and system-path are working/correct.
Kevin F. Quinn
20/05/2005 8:40pm
Hmm; one thing occurs to me. Since the keys are held on a FAT removable drive, on Linux at least the permissions cause a gpg warning:

gpg: WARNING: unsafe permissions on homedir `/mnt/partitions/KEV_DATA-30C1-CF67/Data/gnupg'

sent to stderr. I don't suppose this might be confusing the plugin?
Kevin F. Quinn
21/05/2005 8:47am
It appears not. Transpires I could set the permissions on the stick (even though in reality it's meaningless to do so) and gpg accepts it. The warning no longer occurs on the command line, but the plugin still can't find the keys.
20/06/2005 11:44am
Has this problem been resolved?

I have the same prob (cannot get private key) with 1.87 too. Tried with 1.88 RC4, it is the same.
20/06/2005 11:54am
No this issue is still outstanding.

I did add some more debugging code to the gnupg plugin that outputs to the file 'scribe.txt' in the same folder as scribe.exe but I don't know whether that has been released or not. I suspect it's in rc4.

In any case if you want to delete scribe.txt, get the error to happen again and send me your scribe.txt I'll have a look at it.
20/06/2005 12:35pm
wow.. really fast response! Thanks!
The debug text is:
C:\Code\Scribe\Scribe_GnuPG\Code\GpgTools.cpp:137 - No private keys, u is 300 bytes
21/06/2005 1:46am


Yeah ok now my install is doing this too.

The problem is that the name of the key used to be on the same line, and now it's on the next line and the plugin doesn't know to look there.

So I've made it a bit smarter and I'll release the fix shortly.
23/06/2005 9:37am
Hi, I think the download link for plugin GnuPG 0.52 is missing. Thanks.
23/06/2005 12:46pm
It's not missing, it just hasn't been released yet.
Kevin F. Quinn
17/07/2005 10:26am
fret, any chance you could publish a linux version of the GnuPG plugin 0.52? I currently have InScribe version 1.88 rc3 (linux) and GnuPG plugin v0.51; the dialog doesn't complain about 'no private keys' once I set the directory properly, but presents a empty with just one entry '(null) <(null)>'.

Here's the output from 'gpg --list-secret-keys':

sec 1024D/D7A4706D 2005-02-15
uid Kevin F. Quinn (kevquinn)
uid Kevin F. Quinn (mailing lists)
uid Kevin F. Quinn (Gentoo)
ssb 1024g/0DA98122 2005-02-15

sec 1024D/E52BA74B 2005-05-29 [expires: 2005-11-25]
uid Kevin F. Quinn (Portage Manifest Signing Key)
ssb 1024g/BD902C2B 2005-05-29

Kevin F. Quinn
17/07/2005 10:43am
ok; forum post process deleted the email addresses and spacing.
Format of the output of gpg --list-secret-keys is:

1st line - keyring file path & name
2nd line - separator (string of -)
3rd line - 'sec' followed by 3 spaces, 17 char key id, one more space and date
4th-6th lines - 'uid' followed by 18 spaces, then 'name (description) email'
7th line - 'ssb' followed by 3 spaces, 17 char key id, one more space and date
8th line - blank
other keys follow in the same style.

Of note, however is that the gpg info warns agains using the output of '-list-keys' et. al. in programs and scripts, as it is likely to change between gpg versions. The info pages suggest using '--with-colons' to get a machine-parseable key listing, for example:

$ gpg --with-colons --list-secret-keys
sec::1024:17:F46D92F1D7A4706D:2005-02-15::::Kevin F. Quinn (kevquinn) :::
uid:::::::A4D54B2C366771FD6B035903090F05BF9A81B52E::Kevin F. Quinn (mailing lists) :
uid:::::::C35BF425E5E5DC72387DA3EACE072AD5332EEC58::Kevin F. Quinn (Gentoo) :
sec::1024:17:65F34B48E52BA74B:2005-05-29:2005-11-25:::Kevin F. Quinn (Portage Manifest Signing Key) :::

(6 lines)

Note this supplies the full-length 16-digit key id, not just the abbreviated 8-digit one. That big long string in the 'uid' lines is a local hash, to identify precisely the key (for example if the name/address field is not unique). Documentation for the -with-colons style is in doc/DETAILS in the gpg source distribution.