Index > Scribe > GnuPG Plug-In: Didn't get any private keys ... | |
---|---|
Author/Date | GnuPG Plug-In: Didn't get any private keys ... |
Hopper 04/05/2005 4:14pm | Hi.
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. |
fret 04/05/2005 11:41pm | Have you set the home directory in the plugin's settings? |
Hopper 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. |
fret 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. |
Hopper 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.
|
smlee 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. |
fret 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. |
SMLee 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 |
fret 21/06/2005 1:46am | Oh.
Um. 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. |
smlee 23/06/2005 9:37am | Hi, I think the download link for plugin GnuPG 0.52 is missing. Thanks. |
fret 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': /home/kquinn/stick/Data/gnupg/secring.gpg ----------------------------------------- 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) ssb::1024:16:CA68445B0DA98122:2005-02-15::::::: sec::1024:17:65F34B48E52BA74B:2005-05-29:2005-11-25:::Kevin F. Quinn (Portage Manifest Signing Key) ssb::1024:16:03A4CB50BD902C2B:2005-05-29::::::: (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. |
Reply | |