I edited this task a bit: For compression we have T6332
For Archives passed to Gpgtar we have: T6342

Yes I am an admin on the https://pypi.org/project/gpg/ package.

No more logs. My understaning is that the pypi ownershipof the project has been transferred to @bernhard

I am changing the priority here to high as the parent task has high prio. Maybe we should close this as a duplicate of T5478

Since the issue T6328 described an issue with high pirority which would be fixed by this issue I am raising the prio here.

We have discussed this and what we think would be the best solution would be to have an extension in the engine-gpg of GpgME either through a flag or through a new API to use gpgtar directly with --encrypt and decrypt. This should behave exactly like the gpg encrypt / decrypt / verify functions but would avoid the need of Piping in Kleopatra. It is a fairly recent development that gpgtar can do the crypto operations by itself so this is why this was not done initially.

@justus: Please talk to @kuwv on how to transfer the package to him.

I do not consider the whole PyPi thing a secure solution and thus we do not want to engage us there. However, if you need small patches to GPGME, please go ahead post them to the ML or upload them here.

For testing I have created a Gpg4win installer and only selected minimal installation and gpgme-json was there. Both in /bin and /bin_64.

works: the process is canceled without any notification.

The problem with expired keys may still happen for GpgSignKeyEditInteractor, but Kleopatra doesn't allow certifying expired keys or user IDs. Therefore, I don't look into this.

OK I can confirm that with ae9258fb and f1802682 commits I was ble to update my rpm packages to 1.18.0.

In T6305#165907, @ebo wrote:

With GnuPG VSD 3.1.25 the Certify action is not disabled for me. Neither on Windows nor on Linux system.

With GnuPG VSD 3.1.25 the Certify action is not disabled for me. Neither on Windows nor on Linux system.

How did you manage to certify an expired key? For me the Certify action is always disabled for an expired key or user ID.

Ok. So after further discussion. It is good that you kept a WKDRefreshJob copy :)

In T6285#165459, @gniibe wrote:

Now, the use of AM_PATH_GPGME_PTHREAD shows warning. Also I update the documentation.

Now, the use of AM_PATH_GPGME_PTHREAD shows warning. Also I update the documentation.

Thank you for the bug report and your suggestion.

Actually we have two gpgme versions in gpg4win because gnupg is a "sub"-installer inside of gpg4win and it comes with its own gpgme. That gpgme is the release version but the one used by gpg4win's kleopatra is often a newer snapshot.

thank you, works for me.

Thank you, looks good to me.

Please use gpgme.pc to configure your build. Your options are:
(1) With Autoconf:
(1-1) Use pkg.m4 and PKG_CHECK_MODULES (which uses pkg-config to access gpgme.pc)
(1-2) Use gpgme.m4 and AM_PATH_GPGME (which uses gpgrt-config to access gpgme.pc)
(2) Or... use pkg-config to access gpgme.pc.

I updated gpgme.m4 to include configuration of GPGRT_CONFIG.
Using this new gpgme.m4, it should work.
Using this new gpgme.m4 plus old gpg-error.m4, checking GPGRT_CONFIG is duplicated.
Using this new gpgme.m4 plus new gpg-error.me, no problem.

I overlooked the use case of gpgme programming not using libgpg-error. This use case should be supported.

ready for testing

Note the relationship to T4195, T4826, and T4766

In QGPGME which is used by GpgOL and Kleopatra we have solved this by loading the configuration only once and then reusing it. I see no need to change something in gpgconf here.

@gniibe - Thanks for the quick response. It now works for me.
cu Andreas

@ametzler1 Thank you. That was because of my bad fix.
Fixed in rMf1802682c3c8: python: Fix configure generating setup.py.

the pushed fix breaks when libgpg-error does not require special CFLAGS, i.e. when @GPG_ERROR_CFLAGS@ expands to an empty string:

FWIW: I am not anymore very convinced of our tofu code. it leaks too many information because it tracks and stored all signature verification. The model is further way too complicated and the SQL used will eventually lead to a resource problem. Maybe doing Tofu stuff in the frontend is a better idea and get rid of all the history processing which works only for fresh mails and not for data verification.

Yes it is set to tofu+pgp. Is it now possible to change the trust-model on context based?

Thanks for the report, since you are using it on the command line and it works I assume that trust-model is set to tofu+pgp? Because in the Test code there is no context flag for tofu+pgp trust model.

Thanks for the report, since you are using it on the command line and it works I assume that trust-model is set to tofu+pgp? Because in the Test code there is no context flag for tofu+pgp trust model.

Let's don't forget that we need to have a sig_class replacement.

This is not easy to fix because it would break the GPGME API. Here
are the values we can expect:

I assume this is gpgme master. Please write proper bug reports.

Pushed the fix.
Note that non-in-tree build never been reliable (using the result of the configure, in tree).
So, I basically don't consider the use case of non-in-tree build.

Reviewing the build process, it's just better to use @...VAR...@ by configure (instead of invoke pkg-config again in setup.py).

The export/backup of the secret part of S/MIME certificates has been fixed with T6189: Secret key backup of S/MIME certificate creates bad result. An exported certificate should now be imported without problems.

Now "BER error" is reported, if the user tries to import a .p8 certificate. (The certificate exported by Kleopatra wasn't stored as PKCS#12, but presumably as PKCS#8 which gpgsm cannot import. See T6189: Secret key backup of S/MIME certificate creates bad result.)

BTW, gnupg/doc/DETAILS tells that the fingerprint is optional:

Pushed the fix for GPG_ERR_INV_ENGINE.

gpgsm may emit S IMPORT_PROBLEM 1 (with no fingerprint information) when it cannot find valid fingerprint.
I think that this case should be handled correctly by GPGME, not returning GPG_ERR_INV_ENGINE.

Ok. That is about the Invalid Crypto Engine. But this does not explain why a .p12 export via Kleopatra leads to this error when we export a valid certificate. The same thing I do with Kleopatra on the Command Line works:

The error is generated in parse_import in gpgme/src/import.c:

if (errno || args == tail || *tail != ' ')
  {
    /* The crypto backend does not behave.  */
    free (import);
    return trace_gpg_error (GPG_ERR_INV_ENGINE);
  }

Thanks, I really appreciate having this fixed in gpgrt-config! I backported the commit to gentoo and can confirm that fixes the build issue with slibtool.

GnuPG requires threads but not gpgme.
We already had the same discussion about threads and libgpg-error more than one year ago: https://dev.gnupg.org/T5296

Thank you for your report. Next time, please include information of your target and configuration in the report.

I pushed the changes. It also cares about the case for --cflags.

@orbea Thank you for your suggestions.

For the original issue I'd prefer to silence the error/warning with -Wno-narrowing because I think it's a non-issue. Or does changing the enum declarations to enum : unsigned int make clang happy?