I addressed this for GPGME in 60273e8b2c11d42215a5707bc55e3e0d8f350e07 but
apparently forgot to mention that here.

I'll keep the bug open until I fixed this in all packages.

Thank you very much. Straightforward fix. Applied the patch.

Delegating to our resident C++ expert.

Merged in 9291ebaa4151a1f6c8c0601095ec45809b963383.

Fixed in 6f02133bb07726afa6950e5b4685e75621276e60 by backporting a fix from
gpg-error.

After testing on Windows this problem is not resolved for Windows (I agree that
it's resolved for posix).

The issue there that I see now is not that it's a race between changing the
setting and immediately reading it again but that sometimes the communication
between gpgme and gpgconf fails.

See attached file no-read.txt for some debugging on this. GPGME writes a changed
option to gpgconf but gpgconf does not read it. I've used OutputDebugString and
DbgView to have syncronized debug output over process borders.

Not 100% reproducible but on my test system it fails very often.

FWIW: In GnuPG we have for example this in the configure script

*-*-hpux*)
    if test -z "$GCC" ; then
        CFLAGS="-Ae -D_HPUX_SOURCE $CFLAGS"
    fi

IF it makes things easier we may add a simlar case for macOS. But we need to do
this for many packages, I think.

Fixed in 0e242278dfaa64ce31a45b72f5fa0806a3dba898.

We configure the build with -D_DARWIN_C_SOURCE=900000L on our macOs box. Not
sure if this is the proper thing to do, and/or if we should just always set that
when we build on Darwin in configure.

It seems like indeed it should have been resolved. I have also resolved the issue
by moving the old headers from KDEPIMLibs 4 to a private location, and KF5
projects have apparently been updated to work with gpgme++ installed in
$prefix/include/gpgme++ .

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.

We don't see that on our Sierra box.

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,

The patch works. There's 1 more issue that's been standing for a bit longer already,
and that you might want to tackle at the same time: there's no argp.h header on Mac.

On Linux it is only a problem with the headers (e.g. the -dev) Package as the

That's actually an orthogonal issue, and one that's probably easier to rectify as any
changes only become apparent when dependent software is being built.

libraries have different soversions

This is also the case on Mac, but the link library doesn't have a soversion. It's
called libqgpgme.so or libqgpgme.dylib .
There is of course the option to rename just that symlink. A bit of a hack, but one
that's relevant only during the link step, when dependent software is being rebuilt.

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.

MacPorts does many things like they're done on more traditional *n*x desktops, i.e.
install libraries in a central, shared location (--prefix=/opt/local by default).
There is nothing specific it does to handle ABI breaks; they can hold up an upgrade,
or a patch is applied at some level, or a conflict is registered. Sadly there is no
central way to create -dev packages, which doesn't help here.

E.g. when we
break the ABI in QGpgME libqt5qgpgme.dylib may be incompatible and we would need
a new name.

That I don't see. The problem here isn't so much the ABI break compared to the
version shipped by kdepimlibs4, but the fact that an incompatible Qt version is used.
So no, a SOVERSION=8 upgrade doesn't impose a library name change. Cf. Poppler and
its Qt backends; they're called libpoppler-qt4 and libpoppler-qt5 .
An alternative would be to do like QCA: install the library wherever Qt's own
libraries are installed. That automatically resolves the conflict with the old
version included with kdepimlibs4, and might be less disruptive for existing
distribution packages.

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

What I had in mind was a build system that refuses to do a mismatching build of QpgME
X.Y.Z against GpgME++ that's not X.Y.Z . If you don't do runtime checks there's no
guarantee anyway beyond what the dynamic linker can give, I think. Distributions can
build QpgME and only bundle the QpgME bits, and then install that against any GpgME
install. I've done that for a bit with QpgME 1.7.x against QpgME++ 1.8.0, and didn't
run into any issues.
You could probably even argue that people would be less likely to try this kind of
things if the build system gave off a big hint that they really shouldn't be doing
that. It's not like it's particularly difficult to install only QpgME, after all.

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

Aside from the required build system changes we wil run into problems evaluating
bug reports.

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 just a bit a pity that you have to build all of the cpp bindings again if
you just want to build the Qt bindings.

On Windows we copy the new file; on Unix we link-rename it. It might be worth
to change that old code to use estream and the same method for file updates as
we use elsewhere.

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.

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

Released with 1.8.0

Thanks for your patch. Due to the planned gpgme releases I also added the
override feature and hacked tests/run-decrypt to test these two features.

Regarding the original issue discussed here:
What about an option in gpg/gpgme to limit all operations to keys contained in a
"whitelist" file?

(accept --recipient keys only if they are contained in the file, --list-keys
shows only keys listed in this file, --refresh-keys only refreshes keys listed
here, etc.)

Reported the problem mentioned here in T2835
("keyid-format none" ignored for --verify and other commands)

(repost, I just noticed that neal is not in the nosy list. I'll unlink the old
entry afterwards)

neal: Interesting idea, this (or for a non-gui version: a signed list of
fingerprints available from a central source and retrieving those keys) would
solve 2 (iterating over all keys) and 3 (regularly update).

For the non-gui variant I wondered about how to use --verify and check that the
file was signed by the authority key (--verify only prints the keyid,
"--keyid-format none" does not allow --verify to print fingerprints in 2.1.15,
I'll file a separate issue). I was a bit disappointed when I saw that gpg sync
just calls the command line with --keyid-format 0xlong and does screen scraping
to verify the verification.

But still, how to solve 1 with gpg itself? Of course I could "manually" verify
in the application that only the intended keys have been used, but as shown with
gpg sync's code above: This is not always easily possible.

@thomas: You may want to look at gpg sync, which I think makes at least some of
what you want to do easier.
https://firstlook.org/code/2016/10/12/introducing-gpg-sync-an-open-source-tool-for-organizations-that-encrypt-email/

Sign the keys and set the signing key to fully trusted.

does not solve 1.:

Encrypt a file to any of those key (but no others!),

(because people may trust other keys)

and it does not solve 2. without keeping a separate list of keys/fingerprints:

Iterate over all keys

additionally _all_ users have to regularly update _all_ these keys, otherwise
things like expired subkeys will lead to failing encryption. (This is no theory:
We've been there and don't want to have this again)

Sign the keys and set the signing key to fully trusted.

I don't think there is an issue anymore.

Still in issue after we figured out that select could have been the reason for
this? The explict check for a valid FD number was added in June so before that
a segv could have been the outcome.

With the soon to be released gnupg 2.1.16 and gpgme 1.8 this will work.

If a keyring is non-readable (e.g. chmod 000 pubring.bkx), gpgme_op_keylist_next
will return GPG_ERR_OPENKEYRING instead of GPG_ERR_EOF.

Please tell me how I should model my workflows in this case:

• There is a a centrally managed set of public keys (currently in a keyring

file, but I'm open to suggestions)

• Different users should be able to use this set of keys (and no others) for

certain tasks:

1. Encrypt a file to any of those key (but no others!), but also decrypt the

file with their secret key (which is not centrally managed)

2. Iterate over all keys and do something with them (here: publish them in the

WKD after having made changes to the set of keys)

We try to deprecate the use of the --keyring option because that is too
troublesome for many reasons. We can't remove that option from gpg proper for
compatibilty reasons. But not adding a new feature to GPGME won't raise any
compatibility problem and thus we can fortunately reject this request.