Oops wrong, 251 did not yet have it, 253 will have it. Forgot to push the change.

I've added the option. It's in the latest beta (251) from files.gpg4win.org
A beta installer containing this version will be published likely this or next week.

We are aiming for a stable release middle of march.

While this f.e. for my wife will not work, not user friendly enough :(

I'm really really sad to hear that. I was hoping this was acceptable to
"non-technical" users just one of the quirks users eventually get used too :-(

I tried to think about this more but I don't see another solution then:
a) Prevent Outlook from saving any changes after a message was decrypted

• This is the current behavior and leads to the problem.

b) When Outlook want's to save a mail remove the plaintext, restore the
encrypted contents and save the changes to the encrypted mail.

• This has a serious downside that it does trigger a full resync of the mail

because outlook thinks the attachments have changed. When closing Outlook this
also somehow brought Outlook in a state that it kept indefitely syncing a single
mail :-/. It also broke the signatures on singed only mails because the MIME
boundarys could not be restored. In general I found it much more unstable and
buggy then a clear "Sorry you can't do that". :-/

Ok, I found the problem, as we handle the selection changed event in the
messagelist we were trying to decrypt messages even if they were not loaded /
visible in the preview window. That caused a weird state and several errors.

I've fixed it now so that we only decrypt items when a selection changes in an
Explorer that has a visible preview pane. I'll let you know once a beta with
that fix is released.

Thanks again,
Andre

Note that each of these outputs is preceded by a KEY_CONSIDERED lined (for the
same key). Since the TOFU conflict information is per key, I'd expect an
implementation to say: Oh, there is already some conflict information for key X.
This must be a more up to date version, so I'll delete that first instead of
appending to it. Is this an unreasonable expectation?

In my Opinion it is. There is a technical, (i guess) unintentional, reason for
the multiple outputs, they
don't convey useful information. So I would consider this Output a Bug and
implementations
working like you describe it to be a workaround for that bug.

Getting firs wrong information and later updating it with the correct
information makes implementations
more complicated and error prone and currently is not handled in GPGME.

Also in GPGME we just want to figure out the TOFU Info for all the UID's of the
key used
to check the signature. We don't want information about conflicting keys. We need
a reliable way to filter this out. So I have a patch that ignores all TOFU_USER
lines
that don't match the fingerprint of the signature but still that breaks because
the "Update"
is not handled.

Done now

Thanks for testing the beta and your report. I can reproduce some weird crashes
when the preview pane is disabled, too. It's not 100% for me but some times
after sending a crypto mail sometimes later it crashes, sometimes when switching
folders it crashes, very weird. Sometimes the decrypted contents of a mail are
not shown after opening it.

And with preview everything is fine.

Looking into it.

Yes, We fixed that. Sorry I didn't see your bugreport then.

Btw. You can also send such E-Mails encrypted with GpgOL nowadays :-)

http://files.intevation.de/users/aheinecke/gpgol-kitten.png

As a user are these workarounds acceptable to you. < This should have been a
question ;-)

Hi,

Again thanks for your feedback on the GpgOL-Beta. You might want to give the
latest one from http://files.gpg4win.org/Beta/gpgol/ (beta-246 currently) a try
it's much improved and there were several potential crashes fixed. I'm currently
working on an improved certificate selection and certificate details dialog and
then we will release a new gpg4win beta with that.

To your problem: Yes this is a serious problem, but we currently don't have a
solution for this, only a workaround. The workaround is to do the Copy / Move /
Modify while the mail is not shown decrypted. In the current beta:

If you unselect the crypto mail you can move / copy / modify (e.g. flag) the
message through right clicking it.

To save the message as .msg you can drag & drop it (even when opened) to a
target windows explorer folder.

An opened messaage can still be moved to trash. Any other moves will sadly
result in an "File name or directory name is not valid" error.

We inform the user about this only when he tries to modify a mail (see attached
screenshot) we should probably also do that for other things.

The underlying problem is pretty complicated and we spent a lot of time
struggling with that, but basically we must prevent outlook from saving the
decrypted content. Otherwise the mail will break and can no longer be shown in
other MUAs. And worse the Plaintext may be resynced to the server. One
workaround we had was to restore the crypto contents before outlook saved the
mail then decrypt it again. But this caused several other problems. E.g. Outlook
resynced the mail to imap and Signatures might be broken, and if we did this at
the wrong time outlook would do into an indefinite sync loop. So we decided
better to have clear workarounds and be otherwise stable then to have buggy /
strange behavior.

As a user are these workarounds acceptable to you.

Hi,

Thanks for feedback on the beta!

This was actually a feature request and I consider this a feature. Because it's
a security usability problem if someone replies to an encrypted mail in plain
text with a full quote of the originally encrypted mail. KMail for example does
the same preselection.

But I see your usecase. I'll make it optional (a config setting) but the default
will be "enabled".

For what it's worth i think WKD checks should be done even more regularly then
when they are explicitly triggered thorugh locate keys because we need to see
updates on key rollover / revocation of keys or uids. Something like the
parcimonie style auto-key-refesh that is currently planned.

But yes re fetching on locate-keys if the key / uid for key-locate is expired
would be a first step.

I currently know of no more problems so lets resolve this.

I think this was already resolved by:

https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgme.git;a=commitdiff;h=7302791c0d308c3284ac24a743035d27a0c0b6ba

Please let me know if it still does not work for you.

I am very sorry for this problem, was a bad mistake.

This was fixed immediately after the release but we need a new release to roll
it out.

Thanks, applied!

Forgot to give you credit / mention this bug in the commit message. Apologies
for that.

I think this is a dup of T2819

That issue also contains a possible implementation. I'm not sure anymore why we
didn't push it I think it was because we were under release pressure and wanted
do look into this later.

Hi,

thanks for your feedback.

Regarding library suffix in the cmake config files, sorry about that I forgot
MacOS ;-) can you please test the attached patch (macos-cmake-config-fix.diff)
that reintroduces libsuffix to distinguish between macos and linux?

QGpgME builds libqgpme, preserving the same name as the library that used to
be built by kdepimlibs4.

There was a discussion after the 1.7.0 release about this. In summary: I agree
that we should have changed the name to avoid this conflicts, but we think that
it's now too late to do that as we want to avoid additional hassle for packages.
On Linux it is only a problem with the headers (e.g. the -dev) Package as the
libraries have different soversions. On Windows it's not a problem at all as the
Application ships the library it requires.

Is this something that might be considered upstream, e.g. for 1.8.1, possibly as
a build option? I realise this may not be something that has already come up on
Linux desktops but it's likely to do so in other distribution systems; it is
blocking us in MacPorts at this moment, for instance.

How does MacPorts handle this in general? IMO this is not a (q)gpgme(++)
specific problem as you will have this problem with each ABI break. E.g. when we
break the ABI in QGpgME libqt5qgpgme.dylib may be incompatible and we would need
a new name.

On Linux we have soversion and on Windows and MacOS imo usally the libraries are
shipped with the Application. But on MacPorts how does this work?

It will probably a bit more complex to maintain the buildsystem because you'd
want to exclude builds against mismatching qgpgme versions, but when done that
should be all, no?

It's not only the build system but the code using QGpgME / GpgME++ will be more
complex as they would need to have feature checks for both the QGpgME version
and the GPGME version to determine which features are available. This was a huge
hassle in the old days and one of the reasons we wanted to move them closer
together so that you can rely on the API once you have a minimum required version.

See e.g.:
https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgme.git;a=commitdiff;h=433bb8e84b2d1e50b5c5b9f7f2006b60cd7d7785
That removed lots of these feature checks.

D403: 936_macos-cmake-config-fix.diff

D401: 931_0001-qt-Add-test-for-CryptoConfig.patch

Can you repeat this also with GPA, which uses the gpgconf for ages?

Yes, It's even more visible in GPA because according to the gpgme log GPA does a
list options right after the change. So e.g. If you check "quiet" in the gpg
options then hit apply the check box gets unselected after apply although the
config is changed. Log is similar to the ones attached. Change options is
visible but afterwards the list-options still returns the old value.

On Linux I could not reproduce it with gpa, but as I think it's a timing issue
that might be expected. Attached is a patch that adds a Qt test which exposes
the problem on Linux. I can translate that to plain C if it helps. But I think
the attached Logs are already obvious that there is an issue.

Ok profiles are now there and look workable, but it looks like they are only
supporting configuration values that are currently accessible through gpgconf:

[gpg]
trust-model tofu+pgp
keyserver-options auto-key-retrieve
auto-key-locate local,wkd,pka,cert,dane

Leads to:

gpgconf: /opt/gnupg/etc/gnupg/automated.profile:7:0: error: unknown option
'trust-model' in section 'gpg'
gpgconf: /opt/gnupg/etc/gnupg/automated.profile:8:0: error: unknown option
'keyserver-options' in section 'gpg'

So we need more options promoted to gpgconf. Which I think is ok, we can just
mark them as Expert / Invisible and GUI's should respect that.

Thank you for your excellent bug report!

I can reproduce the problem with current git master. Using my regular homedir /
certificates. I was having that for some time now but did not notice as I
thought it was a bug in using old kmail with 2.1 and I rarely use S/MIME. For me
KMail always showed "encryption failed" for S/MIME but the pinentry came up. I
entered my pin and hit sent again and it worked because the agent had cached my
passphrase and pinentry would not come up ;-)

Backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x000000000040fc65 in gpgsm_proxy_pinentry_notify (ctrl=ctrl@entry=0x1,

line=line@entry=0x68f548 "PINENTRY_LAUNCHED 14400 unknown 0.9.8-beta24") at

../../sm/server.c:1492
1492 if (!ctrl || !ctrl->server_local
(gdb) bt
#0 0x000000000040fc65 in gpgsm_proxy_pinentry_notify (ctrl=ctrl@entry=0x1,

line=line@entry=0x68f548 "PINENTRY_LAUNCHED 14400 unknown 0.9.8-beta24") at

../../sm/server.c:1492
#1 0x00000000004102da in default_inq_cb (opaque=0x7fffffffd990, line=0x68f548
"PINENTRY_LAUNCHED 14400 unknown 0.9.8-beta24")

at ../../sm/call-agent.c:197

#2 0x00007ffff747663c in assuan_transact (ctx=0x68f3f0, command=<optimized
out>, data_cb=0x443080 <put_membuf_cb>,

data_cb_arg=0x7fffffffd9a0, inquire_cb=0x4102b0 <default_inq_cb>,

inquire_cb_arg=0x7fffffffd990, status_cb=0x0,

status_cb_arg=0x0) at client.c:291

#3 0x0000000000410882 in gpgsm_agent_pksign (ctrl=0x1, keygrip=0x68bffc "",
desc=0x7fffffffd9f2 "", digest=0x68bffc "",

digestlen=20, digestalgo=2, r_buf=0x7fffffffdec8, r_buflen=0x7fffffffde18)

at ../../sm/call-agent.c:269
#4 0x00000000004179c2 in gpgsm_create_cms_signature (ctrl=0x7fffffffe0a0,
cert=0x6b2e20, md=0x69d650, mdalgo=2,

r_sigval=0x7fffffffdec8) at ../../sm/certcheck.c:430

#5 0x00000000004203e5 in gpgsm_sign (ctrl=0x7fffffffe0a0, signerlist=0x68f548,
data_fd=0, detached=1, detached@entry=0, out_fp=0x0)

at ../../sm/sign.c:707

#6 0x000000000040aa65 in main (argc=1, argv=0x7fffffffe230) at
../../sm/gpgsm.c:1798

I can easily provide more debug output.

Regarding a return code as text lines: Do you need this due to the double-fork
we use in gpgme?

I think so, at least I did not find a way to return an exit code from
gpgme_op_spawn.

If we provide this we should resort to the GnuPG standard
which is to required --status-fd N to print
[GNUPG:] ERROR ....
okay?

Yes. In that case i could use op_spawn with status-fd 2 and would get the error
I think.

Hi,

I think that your assumption is that the local keyring is somehow trusted. In

that case, I think it make sense that deleted keys would clear conflicts.

No, not really I don't think trust plays a role here. It's just a way I think
users may resolve conflicts when they don't know about policies or how things
work internally.

I'm curious when you think people delete keys. My intuition is that it is not

a very common pattern. Do you have any thoughts on this?

As an example: You get a new lock in your front door. Would you remove the key
for the old lock from your keyring or would you paint the old one red as a
marker not to use the old key.

I know that this is not totally applicable because the old key can still be used
for verification etc. But I think that this is the intuitive behavior if a key
changes.

Maybe if GUI offers conflict resolution better this might not be such a big deal
but currently (Kleopatra does not yet have conflict resolution) but for me
during tofu testing I thought I could resolve a the conflict by deleting one of
the keys and found the behavior unexpected.

I encourage you to first try and find a consensus before implementing a

different policy at the higher level.

Indeed. Let's try :-)

Sorry for the duplicated bug. Although the other issue is older I got more
response here so I keep the discussion here.

In my Optionion it's completely natural for a User to think (I thought this):

• Oh I have two keys that are in conflict: I'll delete the bad one then I don't

have a conflict anymore.

This is very intuitive behavior.

I'm not looking for a solution that works for me but for a solution that I think
would work for other users.

So for me your response ("what you should do") would mean that in Kleopatra on
Key deletion I would need to check for conflicting keys and change their policy
to auto again. Maybe even mark the deleted key as bad before deletion. I would
much prefer it if GnuPG handled this. For me it seems just like an unhandled
state as the error messages also indicate. "Key not found" etc so It's a bug or
maybe missing feature / functionality.

Fwiw I don't see how this can be consistent with WoT behavior as I don't think
WoT has a comparable problem. Can you explain what a comparable problem in WoT is?

If you meant hat the validity of all keys is not updated immediately after key
deletion, and you had some ownertrust to the deleted key ok yes thats probably
also another issue. :-)

While testing with tofu enabled I sometimes see that some actions take very
long. (>1minute)

Like importing a key in Kleopatra where Kleopatra does an import and starts a
keylist afterwards / in parallel.

I'll try to reproduce this on the command line. Just doing a simple import on
the command line is quick.

Do you have any hint what can take so long?
Like a trigger that would cause a rechecks for cross signatures?

On Windows especially the initial keylist is very slow, subsequent keylists are
okish (less then 10 seconds) I don't think it's as big a problem anymore.
Listing a specific key is ~100ms. And that is with a large keyring (~18mb) on a
VM with a fairly slow harddisk.

For me this would be good enough to use tofu on windows. So it can be resolved
if you do not think the performance (especially of the initial listing) can be
improved or should have been better.

PS C:\Users\aheinecke> Measure-Command -Expression { gpg --no-auto-check-trustdb
--with-colons --trust-model tofu --list-keys --with-colons > $null }
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: please do a --check-trustdb
gpg: public key 60041E4EC03449C4 is 39 seconds newer than the signature
gpg: public key 60041E4EC03449C4 is 39 seconds newer than the signature

Days : 0
Hours : 0
Minutes : 1
Seconds : 14
Milliseconds : 785
Ticks : 747854659
TotalDays : 0.000865572521990741
TotalHours : 0.0207737405277778
TotalMinutes : 1.24642443166667
TotalSeconds : 74.7854659
TotalMilliseconds : 74785.4659

PS C:\Users\aheinecke> Measure-Command -Expression { gpg --no-auto-check-trustdb
--with-colons --trust-model tofu --list-keys --with-colons > $null }
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: please do a --check-trustdb
gpg: public key 60041E4EC03449C4 is 39 seconds newer than the signature

Days : 0
Hours : 0
Minutes : 0
Seconds : 7
Milliseconds : 812
Ticks : 78128420
TotalDays : 9.0426412037037E-05
TotalHours : 0.00217023388888889
TotalMinutes : 0.130214033333333
TotalSeconds : 7.812842
TotalMilliseconds : 7812.842

PS C:\Users\aheinecke> Measure-Command -Expression { gpg --no-auto-check-trustdb
--with-colons --trust-model pgp --list-keys --with-colons > $null }
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: public key 60041E4EC03449C4 is 39 seconds newer than the signature

Days : 0
Hours : 0
Minutes : 0
Seconds : 1
Milliseconds : 369
Ticks : 13697177
TotalDays : 1.58532141203704E-05
TotalHours : 0.000380477138888889
TotalMinutes : 0.0228286283333333
TotalSeconds : 1.3697177
TotalMilliseconds : 1369.7177

PS C:\Users\aheinecke> gpg --version
gpg (GnuPG) 2.1.17-beta30
libgcrypt 1.7.3

Home: C:/Users/aheinecke/AppData/Roaming/gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,

CAMELLIA128, CAMELLIA192, CAMELLIA256

Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2

I could reproduce this by opening two crypto mails in multiple windows this
reliably triggered the crash.

I have not fully understood the crash as it crashed in the close invocation in
outlook. After various trys and improvements to our code (there were some fishy
cleanups) i was able to fix this by closing the inspector of the mailobject
before closing the mail. Outlook apprarently did not like it if I closed a mail
that was active in an inspector but that is a bit speculation.

Just for the record:
It's gpg.conf-1 or gpg.conf-2 and not gpg.conf.1

My workaround for this problem also was to have a gpg.conf-2 which is then used
by gpgconf and a gpg.conf that is used by gpg 1.

I've just announced a new 3.0 beta that contains the updated GpgOL

http://lists.wald.intevation.org/pipermail/gpg4win-devel/2016-November/001659.html

Please let me know if it still crashes for you with that version.

When using a script you should not parse the human readable output.

gpg2 --status-fd 2 --verify /tmp/msg

[GNUPG:] VALIDSIG 94A5C9A03C2FE5CA3B095D8E1FDF723CF462B6B1 2016-11-14 1479138285
0 4 0 1 8 00 94A5C9A03C2FE5CA3B095D8E1FDF723CF462B6B1

See https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=doc/DETAILS
for the meaning of these fields

In gpg2.1.16 the fingerprint is also used instead of the keyid if you do:

/opt/gnupg/bin/gpg --keyid-format none --verify foo.sig

Where do you take it from that keyid-format none should result in the full
fingerprint being shown?

Hi,

Thanks for testing gpg4win This issue was already reported in T2335 and has
been resolved (but not yet released).

I'll upload a new beta next week.

Regards,
Andre

gpgol 2.0 won't change the messages on the server anymore there might be code
paths leading to that under error conditions but i'm not aware of any. And the
fallback is first to try to revert them.

Still true for sending but for sending we don't have a choice. But decryption is
now done in a different thread.

I've tried this again with the current development version after a very large
refactoring how we handle mails. The bug appears to be gone. I've tested 10
times to send a file with closed / open outlook and with and without encryption
active.

If I install gpg4win-2.3.3 on the same system / setup the crash is reliably
reproducible.

It's still likely that we made a reference counting error internally in code
that was changed / fixed now. And Outlook released the Mail object too early and
crashed.

Kaspersky probably had some similar error in their code.

I'll upload a new Gpg4win beta with the new gpgol next. I'll ping in this issue
once thats done so you could ideally confirm that its fixed now.

I don't think there is an issue anymore.