On Mon, 25 Jan 2010 00:16:06 -0700 Chad Perrin <per...@apotheon.com> articulated:
> On Sat, Jan 23, 2010 at 06:19:58AM -0500, Jerry wrote: > > I posted this recently on the GnuPG forum; however, no one had ever > > seen it before. > > > > FreeBSD-7.2 > > > > gpg (GnuPG) 2.0.14 > > libgcrypt 1.4.4 > > > > gpa 0.9.0 > > > > I honestly have no idea what the problem is here. I recently > > installed GnuPG on my system. Everything appeared to go fine. For > > some reason, I have numerous keys listed that I have no knowledge > > of. > > > > This URL shows the keys: > > > > http://seibercom.net/gnupg/KeyListing.png > > > > These are not OpenPGP keys, but x.509 certificates. I have no idea > > why they are showing up in the listing, nor can I delete them. > > GnuPG no longer works with my MUA either.I have tried deleting > > GnuPG in its entirety and the "~/.gnupg" directory. That did not > > alleviate the problem. Once I reinstalled them, the problem > > resurfaced. > > I've never heard of anything like this with GnuPG either, and I'm > really not sure how you'd end up with a bunch of X.509 certificates > in a GnuPG keyring. I do have a hypothesis for you to investigate, > however: > > You're using a tool I don't know anything about from personal > experience. Specifically, I'm talking about GPA. I've always just > used the command line tools. Because what you describe doesn't seem > to make any sense for the functionality of GnuPG, and you have this > featureful GUI application for managing keys, I thought maybe that > was the place to look. > > The contents of the pkg-descr file for security/gpa say: > > The GNU Privacy Assistant is a graphical frontend to GnuPG and > may be used to manage the keys and encrypt/decrypt/sign/check > files. It is much like Seahorse. > > WWW: http://gpa.wald.intevation.org/ > > Checking the site didn't really give me any information at all, but > the pkg-descr file for Seahorse says: > > Seahorse is a Gnome front end for GnuPG - the Gnu Privacy > Guard program. > > It is a tool for secure communications and data storage. > Data encryption and digital signature creation can easily > be performed through a GUI and Key Management operations > can easily be carried out through an intuitive interface. > > WWW: http://seahorse.sourceforge.net/ > > Looking at the Seahorse site, it says it supports GnuPG keys *and* SSH > keys. It lists a few other things it does, including an ambiguous and > frustratingly undefined "More...". I hunted around a bit and, on the > developer wiki, found a short list labeled "To Do (Grand Plans and > Quackery)" that included "Support X.509 certificates" as its first > item. > > My thought is, if the GPA developers are following a similar path to > what the Seahorse developers are doing, they might even have gotten > to X.509 certs first. If that's the case, GPA may have just > automagically hunted up the X.509 certificates used by your browser > and added them to the list of managed keys. > > Given the notion that GPA may have a bunch of functionality and > features that aren't even known to the user, and that it may try to > magically do things its developers assume people want, it's possible > that it is interfering somehow in the proper operation of GnuPG with > regard to your MUA. Perhaps some configuration file(s) for GPA, > separate from the GnuPG configuration directory itself, are surviving > the uninstalls and reinstalls of your various OpenPGP related tools > -- and maybe that's the reason it isn't currently working with your > MUA. It could be worth investigating. Is the manpage for GPA any > help at all (since there doesn't appear to be any documentation at > all on the Website)? > > I'm curious about what's causing the problem, so if/when you get this > sorted out, I'd appreciate it if you'd let me know anything you learn > about the problem. I may try to help you investigate the matter > further as well if you keep me abreast of what you uncover about the > matter. Of course, I don't plan to install GPA anywhere, so my > ability to look into it is *somewhat* limited, but I might be able to > pitch in a little as time permits. > > > > > > Other than dumping the whole system, reformatting and re-installing > > the OS, has anyone ever heard of this happening before; and if so, > > how to correct it? > > I'm sure there's *something* you can do without nuking and paving -- > even if it's somewhat drastic, like selecting a different MUA (if, for > instance, a change in one of the tools or in the MUA itself has > introduced an incompatibility somewhere). > > Oh, that reminds me . . . is it possible that a change has been made > to some configuration for the MUA itself, without your knowledge? > > What *is* your MUA, anyway? > > Good luck. OK, I posted this on the 'GnuPG' list earlier; however, since you requested further info, here it is. This is the file that apparently GPA is loading that has those pesky 'certs': /usr/local/share/gnupg -r--r--r-- 1 root wheel 27K Jan 20 22:43 com-certs.pem I renamed the file, deleted those "~/.gnupg/*.kbx" files and restarted GPA and the problem went away. Apparently, GnuPG does have support for X.509 certificates. I have been reading through the documentation -- info gnupg -- to discover its full potential and usage. In any case, it apparently is configurable. I am not sure what that is, or if I inadvertently turned it on. I am still working on that phase of debugging. I have GnuPG working with 'claws-mail' now though. For whatever reason, the plug-in that claws-mail uses for GnuPG was unloaded. I don't know why; I certainly never did it. In any case, after reloading it, claws-mail works again with GnuPG. I wouldn't doubt that there is some sort of gnomish bug lurking around, though I doubt that I will ever discover its existence. -- Jerry ges...@yahoo.com |::::======= |::::======= |=========== |=========== | Consider a spherical bear, in simple harmonic motion... Professor in the UCB physics department
signature.asc
Description: PGP signature