Version: 1.9.4 beta (using Devel) Installed from: Compiled sources OS: MS Windows Start signing an email if GnuPG protocol in GpgOL is set to "automatic": Kleo sign dialog shows two drop down lists (for OpenPGP and S/MIME). But you get no choice to set OpenPGP _or_ S/MIME (like in the Kleo encrypt dialog)! Kleo always set OpenPGP as default. Note: S/MIME is active in GpgOL options and works if set "automatic" to "X.509".
fixed by 856324
Still a problem with smime signed messages in "automatic" mode: Send a smime-sig message. Kleo shows OpenPGP signatures only. Sending a smime sig/enc mail (in auto mode) works fine.
kleopatra log, please.
Created attachment 27254 [details] kleo log file actions which are logged in file: 1. send smime signed messages in "auto" mode -> Kleo shows OpenPGP signatures only -> mail is sent as openpgp signed message => bug 2. send smime signed/encrypted messages in "auto" mode -> Kleo shows S/MIME signatures only -> mail is sent as smime signed/encrypted message => correct
The current behavior is correct, GpgOL sends --protocol=OpenPGP when in auto mode. Which it does as Kleo's SIGN implementation didn't yet allow to omit --protocol completely. I changed the code to allow missing --protocol and leave it to the user to select, but Werner's suggestion to inform GpgOL about the selected protocol on SENDER is too much effort to implement right now. And unless that is solved and GpgOL changed it's behavior, this bug won't be fixed from the user's POV.
It's still unclear to how to fix this, the returning protocol on SENDER way is too intrusive for 1.9.8.
Quoting from the log: DBG: <- SENDER -- Gpg4winUserA@test.hq DBG: -> # ok, parsed as "Gpg4winUserA@test.hq" DBG: -> # matching OpenPGP key B726CB6BD1BB45392621CD598B59AB93C6BF6664 DBG: -> # matching CMS key ED2A858A850E47977FF506638865DDBFEAF692B0 DBG: -> # pick freely DBG: -> OK There's no protocol spec for this case. We were told to "just pick one". I'll pop up a message box, but that's all we're going to do here.
SVN commit 868400 by mutz: Pop up a message box in case there are S/MIME as well as OpenPGP certificates that match a given SENDER address. Helps mitigating a hole in the protocol spec. CCBUG:166732 M +40 -6 assuanserverconnection.cpp
done-cbb, reopen if solution is unacceptable...
Background: A real fix requires a protocol change. The problem is that we're not able to tell the "automatic" mode from the non-automatic one at SENDER time. So we have to return a PROTOCOL status line "just in case" (to not break automatic mode). However, we have no way to report back "both are ok", so we need to pick one. GpgOL will, however, send whatever --protocol was configured, so for the user there will be this sequence: GpgOL: set to OpenPGP Kleo: asks for OpenPGP vs. CMS Kleo: if CMS was answered, ignores it and uses OpenPGP anyway.
Format choice dialog comes up in background.
see wiki
$ svn ci -m "Hack to support SENDER --protocol. We really need to make SENDER a command some time in the future... Also, try to make the message box not appear in the background." uiserver Sending uiserver/assuanserverconnection.cpp Transmitting file data . Committed revision 875183.
- Format dialog doesn't comes up in foreground. -> please fix Tests: + Format dialog comes up only if you sign a mail in gpgol auto mode -> correct. + sign+encr mail (auto mode): No sig format dialog. -> correct. Format is set with radio buttons in enc dialog. + select protocol (NO gpgol auto mode) -> no sig format dialog -> correct. tested with Kleo 2.0.1.
new tests with Kleo 2.0.1 shows correct behavior: Format dialog now in foreground.
Verified and closed.
Format message box comes _not_ in foreground if you do no crypto operation before. After some crypto operations the dialog comes correctly in foreground.
On startup kleo pints an error that allowsetforegroundwindow for one component fails with the error code 5 (access denied) maybe this is related to the issues that dialogs are not opened correctly in the foreground.
I'll check again this issue with current Kleoaptra and Gpg4win.
I've tested this stuff a lot in the current development iteration of GpgOL and have seen no Problems so I'm resolving this.