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.

Ah, I understand. I currently have two keyrings (the default keyrings and
debian-keyring.gpg) in my user account. So I will export the keys from
debian-keyring.gpg and import them into my regular keyring.

But this is a different topic from the one described here:
This issue is about allowing gpgme to use exactly one different keyring (not an
additional keyring) that is different from the default keyring or other keyrings
configured in the user's gpg.conf.

So it is just about allowing in gpgme what is already possible via the command
line. Or maybe you would prefer to allow passing command line options to gpg via
gpgme to avoid the wrapper script mentioned below?

I have explained this several times over the last decade. The primary reason is
that it is not possible to keep a consistent vewi on the localally availabale
keys when a user is allowed to remove and add storage at will without gpg having
any control over it. You may end up with duplicated keys and gpg will only
update one of them. The next time the keyrings are "mounted" in a different
order and key is used for update. This leads to all kinds of problems. This is
not a distributed database with a 3 -phase commit system.

I have proposed a solution gor 2.3 based a on central key managing daemon, which
then has the chance to track changes. Interesting fact is that aheinecke has
strongly opposed that idea.

Besides the WKD scenario Andre describes, there are already many existing uses
of a separate keyring where having other keyrings configured via
~/.gnupg/gpg.conf already conflicts with the intended use, except when using
--no-options:

1. /etc/apt/trusted.gpg
2. /usr/share/keyrings/debian-keyring.gpg
3. our company's keyring with acceptable keys for encryption of certain

sensitive information

Basically everywhere where multiple users use a single keyring, often with
"--trust-model always", where you do not want additionally configured keyrings
to disturb the result and give a false sense of security.

Please explain why this a Bad Thing[tm] and what the correct workflow would be.

The keyring is a property of GnuPG and you should not mess around with it. Use
--export and --import to add keys. Extending the bad behaviour of using
multiple keyrings would be Bad Thing.

Fixed with commit df08a0c. Thanks.

This is resolved. we have WITH_TOFU_INFO now.

This is fixed in 3703a4723899d7563937b4b99f5bbe4dd8d3dfed. We will release a
minor update really soon now.

Fixed in 1e6073ff.

Fixed in 1.7 with gpgme_op_keysign.

I pushed Ueno's patches for gpgme. In particular
dee56820cabde60c43c9bf8281b8d411cb2ad644

I agree that this is a practical problem.

I think it would be the right thing.

I'm developing Schleuder, the OpenPGP-featuring mailing list manager.
If I'm receiving an empty list of public keys from GPGME I currently don't know
if there are no keys, or if the keyring couldn't be read. Thus I can't properly
decide what to do: try to fetch keys? I would run into the same problem when
trying to import them. Return an error message? Which one?

This has led repeatedly to confusion e.g. when people imported a key into a
schleuder-list's keyring in the shell as root, which results in changed
ownership of the keyring-files by gpg. Next Schleuder couldn't read the keyring
anymore and maybe refused operation because it couldn't verify any incoming
email any more — instead of giving a helpful error message that points to the
cause: lacking filesystem permissions.

Currently my only chance is to manually check the permissions of all files that
might be involved in an operation. That is working around a bug, in my eyes.