Version: 2.0.9 (using KDE 4.3.5) OS: Linux Installed from: Ubuntu Packages When kwatchgnupg opens, it seems to append somethings unexpected to ~/.gnupg/gpg.conf (while making a backup ~/.gnupg/gpg.conf.gpgconf.bak). The appended stuff turns to be the content of ~/.gnupg/gpg-agent.conf. casper@CasperVector:~/.gnupg$ diff gpg.conf gpg.conf.gpgconf.bak 240,248d239 < < ###+++--- GPGConf ---+++### < utf8-strings < debug-level basic < log-file socket:///home/casper/.gnupg/log-socket < ###+++--- GPGConf ---+++### Sat 13 Feb 2010 11:45:32 CST < # GPGConf edited this configuration file. < # It will disable options before this marked block, but it will < # never change anything below these lines. casper@CasperVector:~/.gnupg$ cat gpg-agent.conf ###+++--- GPGConf ---+++### debug-level basic log-file socket:///home/casper/.gnupg/log-socket ###+++--- GPGConf ---+++### Sat 13 Feb 2010 11:45:32 CST # GPGConf edited this configuration file. # It will disable options before this marked block, but it will # never change anything below these lines. casper@CasperVector:~/.gnupg$ This causes gpg to report an error and exit while being expected to work normally, and further causes seahorse (GNOME) and kleopatra to wrongly show that the gpg keys in the user's database "disappeared". casper@CasperVector:~/.gnupg$ gpg --list-keys gpg: /home/casper/.gnupg/gpg.conf:243: invalid option gpg: /home/casper/.gnupg/gpg.conf:244: invalid option casper@CasperVector:~/.gnupg$
Hello, yes, this is an extremly annoying bug. Please fix ASAP! My workaround is writing a cronjob: */5 * * * * sed -i '/debug-level/d' ~/.gnupg/gpg.conf */5 * * * * sed -i '/log-file/d' ~/.gnupg/gpg.conf Using ubuntu 10.04 ii gnupg 1.4.10-2ubuntu1 # Bugfixed version below, but still won't accept passphrases for S/MIME ii gnupg-agent 2.0.14-1ubuntu2~joke2 ii gnupg-curl 1.4.10-2ubuntu1 ii gnupg2 2.0.14-1ubuntu1 ii gpgsm 2.0.14-1ubuntu1 ii gpgv 1.4.10-2ubuntu1 ii kleopatra 4:4.4.2-0ubuntu5 ii kmail 4:4.4.2-0ubuntu5 Regards
Experienced exactly the same: These generated lines in gpg.conf make Kleopatra disappearing several keys. They are in consequence not available to kmail anymore. gpg: /path/to/.gnupg/gpg.conf:247: invalid option For Kubuntu 10.04 (gnupg 1.4.10), the option "debug-level basic" (here in line 247) seems not be known to this gnupg-version.
I found out that kwatchgnupg makes changes in the files gpg.conf, gpgsm.conf and gpg-agent.conf. It adds lines like log-file socket:///path/to/.gnupg/log-socket debug-level basic who seem not to be understood by gpg. Really annoying, as Kleopatra and depending programs like KMail are rather frequently used in KDE in these days.
Those are valid options for GPG2, but not GPG. Developer should either upgrade Kleopatra and Kgpg to gnupg2. Or downgrade kwatchgnupg which isn't a good idea. In my opinion GPG and GPG2 should be mutually exclusive which is GPG developers failure. This is not a kwatchgnupg bug, but indeed should be fixed.
(In reply to comment #4) > Those are valid options for GPG2, but not GPG. Developer should either upgrade > Kleopatra and Kgpg to gnupg2. Or downgrade kwatchgnupg which isn't a good idea. > > In my opinion GPG and GPG2 should be mutually exclusive which is GPG developers > failure. > > This is not a kwatchgnupg bug, but indeed should be fixed. Well, gpg2 command is gpgv2, while kdepim hardcodes "gpg": https://bugzilla.redhat.com/show_bug.cgi?id=630249#c8 Is this fixed in newer versions?
*** Bug 283343 has been marked as a duplicate of this bug. ***
This is from the gpg2 man page: "If you need to use different configuration files, you should make use of something like ‘gpg.conf-2’ instead of just ‘gpg.conf’." Maybe we should do that?
Yupp! Simply creating a file (empty file is enough) ~/.gnupg/gpg.conf-2 fixes this problem here. Now gpgconf throws those lines into that file and leaves the gpg.conf file alone.
*** Bug 246808 has been marked as a duplicate of this bug. ***
*** This bug has been confirmed by popular vote. ***
Ok someone can resume problem please ? We must use gpg2 ? or not ? option is not valid for which version etc.
(In reply to comment #11) > Ok someone can resume problem please ? > We must use gpg2 ? or not ? > option is not valid for which version etc. gpg2 is not the problem. But the lack of a separate config file by default is.
> gpg2 is not the problem. But the lack of a separate config file by default is. I would argue that the bug is in gpgconf (KWatchGnuPG does not touch the configfile itself): It should not write options to configfiles which are later read by programs not understanding these options. This problem is tracked upstream as https://bugs.g10code.com/gnupg/issue1448 .
(In reply to Ralf Jung from comment #13) > > gpg2 is not the problem. But the lack of a separate config file by default is. > I would argue that the bug is in gpgconf (KWatchGnuPG does not touch the > configfile itself): It should not write options to configfiles which are > later read by programs not understanding these options. This problem is > tracked upstream as https://bugs.g10code.com/gnupg/issue1448 . Except GPG has denied that bug report, and instead says that it is not recommended to install both gpg1 and gpg2 on the same system during normal operation. So now the ball is back in our court. We can either continue complaining about it, or come up with a workaround. In the mean time, I will consult with the Debian project about trying to resolve the gpg1 dependencies and declare the packages in conflict with each other.