To attach a file use the cloud-with-arrow icon in the edit toolbox.

1.11 features a set of extended encryption functions which may optionally take a string as key specifications. In contrast to the array of key objects this string is a linefeed delimited list of key specifications which are passed verbatim to gpg. For OpenPGP a keyword feature is supported. For example the string

A reason we did not touch it in the past is that Ideally we don't want users to have to mess with refresh keys but would rather have this done automatically in the background by dirmngr.

This may be related to T3515: Gpg4win: Gpgconf used to open "windows" and slows down kleo startup since it depends on data from gpgconf.

A work-around is now available for this in Python in the GPGME source. The relative path from the top of the GPGME source directory is here lang/python/examples/howto/groups.py. Like all the other scripts in the same directory, it also appears in the GPGME Python Bindings HOWTO, under the Miscellaneous heading near the end.

Fix was released with GPGME 1.10.0

There was a second person asking for a list-packets feature to verify if a file is encrypted correctly at gnupg-devel.

Here is the build log from unpatched gpgme https://www.zq1.de/~bernhard/temp/gpgme-build-log-2033.txt
it has some tracebacks from t-callbacks.py

Can you please show the output of these failing tests? I assume you are running on a 64 bit platform.

The error of testQuickUID is strange. In the test, it adds a UID and checks number of UIDs (3 + 1 = 4).
It is not reproducible for me (Debian with Qt 5.9.2, NetBSD 7.0.2 with Qt 5.5.1), gnupg 2.2.x from the repo.

(automake should flag non-portable Makefile features - after all it is there to avoid gmake features)

Thank you very much! This is working quite well now.

I believe that all BSD Makefile issues has been fixed (except python-tar-gz distribution thing for maintainer).
Please test again.

I located the problem. It's Makefile portability issue and it is fixed in: rMb5ec21b9baf0: tests: Makefile portability., rMba6e610baa13: tests: More Makefile portability., and rM3224d7f0ea83: tests: Fix previous commit
It was not your final invocation of "make check" (GNU or BSD), but the one before ("make all" by BSD make) which imported keys for tests.
The "export" directive doesn't work on BSD.

I don't think that -R is a good way to implement BCC - it would be better to encrypt it separately. But people may have different ideas on this.

OK. Then, it may be some bashi-ism in Makefile. I'll investigate with no bash installed.

No, I don't have a smartcard. Perhaps it misdetects one?

For other failures, I guess that you are connecting your card, aren't you?
Last year, I introduced a change for key selection to prefer existing card key. That may affect tests. Well, tests should have configure not to try to access card.

When disabling CRL checks, you expose the user to drawbacks by outdated or revoked certificates. While I agree that improving implementations to not check the validation information too often or even build proxies is a good idea, I have a tendency to keep crl checking enabled for CMS crypto operations because it seems to be a lesser drawback.

For scdaemon process(es), I created a ticket T3778: NetBSD: scdaemon should be killed when its parent (gpg-agent) is going to shutdown.

I'm confused. I've just now retested, and I get further with BSD make (there is another problem when importing the keys into the test keyring, where it the error is ignored with GNU make but the build fails with BSD make) but that is not what I want to focus on.

--use-tor does not avoid it because the CRL-DP can be made unique for each certificate. Depending on the verification model a CRL or OCSP lookup is necessary for correct evalution of a signature (shell model as used for qualified signature). This is why we in gpg honor-keyserver-url is not enabled by default; the keyserver URL take from the key is the OpenPGP counterpart of the CRL-DP.

it is the decision of the user to use such a certificate.

The implemented X.509 profiles require that the status of a certificate is to be checked. CRLs are also not looked up for each verification but only once during their lifetime. Some CA have unreasonable short lifetimes for their CRL but it is the decision of the user to use such a certificate.

Additionally, we might want some sort of delayed or batched CRL-checking that doesn't block signature verification with another network interaction, but would protect the user against future problems.

Thanks for your additional suggestion. I pushed the change.

For qt: adding /usr/pkg/qt5/bin to the path makes the build succeed. I think you should take a look at the build rules though, since it seems that it wants to execute the header file if "moc" is not found.

For BSD Make issue, please try:

Ah, yes. Will do. Thank you for reminder.

For the latter, I think it requires path to moc, which may be like /usr/pkg/qt5. Please add it to your PATH. Then, retry from configure

Using BSD make on git head of gpgme, I see

Thank you. I think you can update the comment below the implementation now ("/* FIXME: Implement this when we have the specification for it. */) and the #error line.

Fixed in rM37d62e9d0f68: core: Implement _gpgme_getenv for NetBSD..

Other problems are fixed. Please test. It works for me on NetBSD 7.0.2.

The actual problem is that justus quit his job to work for pEp. Thus we have no maintainer for the python port. There is one candidate for this job but don't expect any fast fixes because one of the near term goals will be to replace swig so that we can provide the bindings also for WIndows. Maybe that will also solve the problem with different Python versions.

it's too bad that this is not considered something worth fixing upstream -- at the moment, debian's python3-gpg will only work with one specific version of python3 because of this, which makes package transitions more complex than they should be.

1.10.0 released

I'd really like to understand what is going on. Thus keeping the report open.

Resolved with gpg4win-3.0.2

Pushed rM7b5182f28893

Frankly, I doubt that this belongs into gpgme.

Andre can you please apply this?

Prio low, as I noticed that Kleopatra already had some code in there to merge a secret with a public key in a keylisting. This can be used for me.

Normal priority as this should be looked into but is not dramatic.

In T3056#95172, @wiz wrote:

Oh, to make it clear - I was testing the pkgsrc version with the additional patches used by pkgsrc, see http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/security/gpgme/patches/

Testing it without patches does not work because:

get-env.c:57:2: error: #error Use of getenv_r not implemented.
 #error Use of getenv_r not implemented.

There are multiple problems. I fixed one Makefile portability issue today.

Fixed in 2.2.3, too. Closing.

data.gpg is fine and data2.gpg shows this wired behaviour. The difference is at the end of file last two bytes : 0040 vs. 0a40.
Initally i took data.gpg to create the base64 encoded version for the message.

I tried to reproduce this simply by creating an encrypted file with gpgme/test/run-encrypt and then running kleopatra on it "kleopatra /tmp/foo.gpg" kleopatra prints in debug output the decrypt / verify result from GpgMEpp. No error for me.

Shall we close this?

Add the tag of npth (forgotten).

Done for libassuan

I'm not sure why a special case should be needed -- failure to create
the .kbx should not be a failure for a decryption operation in general.

I built gnupg 2.2.1 with the patch from D450, but that didn't help.
I even got an additional error:

Yes, it will be in 2.2.3. It's too late for 2.2.2.

So is 380bce13d94f the correct fix? If so, I will update the OpenBSD port including this as a local patch.

I believe this is due to the bug of gpg-agent. So, I put this report as a sub task under T3276: the calibrate_get_time() function depends on a system that has a non-tickless kernel.

This is a bug in gpg-agent.

Could you please testing gpgme with D450: clock_gettime if CLOCK_THREAD_CPUTIME_ID is available. for GnuPG?

I confirm that applying the patch fixes the hang under a VM, and does not adversely affect running on a bare metal machine either.

Could you please try D450: clock_gettime if CLOCK_THREAD_CPUTIME_ID is available. patch of GnuPG?

What do you think about a special case for the homedir "/dev/null" ? We use this device as a specila value at other places too. I have often seen "/nonexistent" in /etc/passwd but there is no standard for this. However, /dev/null is well defined.

Oh sorry i mixed my explanation. I create a normal encrypted file with gpg --encrypt and this file can be decrypted successfully with "gpg -d".
But if I give that encrypted file to gpgme i get the described error, instead of GpgME::Error(0 (Success))).

Here are a couple of traces of the hanging t-protect test under the VM. I just let it run for a bit under gdb and pressed ctrl+c on a couple of occasions:

I've been experimenting.

agreed, generically changing this check to log_info doesn't make sense. However, in *this circumstance*, gpg actually has no error.

"gpg -d" decrypts data why do you think you can decrypt or verify it again?

$ gpg --homedir /notexistent -dv <1.msg --override-session-key 7:D6E1027D58A0CB047C41EA881A137197 --status-fd 2 
gpg: keyblock resource '/notexistent/pubring.kbx': No such file or directory
[GNUPG:] ERROR add_keyblock_resource 33587281
gpg: public key is 7F3B7ED4319BCCA8
[GNUPG:] ENC_TO 7F3B7ED4319BCCA8 18 0
[GNUPG:] ERROR keydb_search 33554445
gpg: encrypted with ECDH key, ID 7F3B7ED4319BCCA8

Indeed, this makes gpg return 2. The reason is that the first error message uses log_error which sets a flag to have gpg return 2. Now, changing this to log_info may produce problems for applications which expect that gpg errors out for a bad homedir.

can you try it with --homedir /does/not/exist

Thanks for the list