When receiving an S/MIME mail that is encrypted, the successful log looks like:

clock returns CPU time on POSIX, wall clock time on Windows. For threads, I don't know.

Comparing the gpgol.log files in the case of OpenPGP decryption (successful) and S/MIME decryption in send folder (failing).

Here is the link to the wald report by John Mrkva:
https://wald.intevation.org/forum/forum.php?thread_id=1785&forum_id=21&group_id=11

D441 applied. Closed.

Applied.

Thanks for testing and proposing new patch.

Same here: I can confirm the bug. I can move an email, if i unselect it before an then use its context menu to move it.
This behaviour is already mentioned in the readme:
c:\Program Files (x86)\Gpg4win\share\gpg4win\README.en.txt

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))).

OK, the problem with D450 lies in the way the value obtained from clock_gettime(2) is used.

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.

Hi,
I have tried this on Windows 10 (1511,1703,1709&RS4TP)
Gpg4win Version 3.0.0
Regards

Hi,
I was using Windows 7 Professional.
The last version that worked was gpg4win 2.3.4 (I didn't try any beta or rc), and encryption/decryption works fine for single files.

It turns out I cannot reproduce the bug with a 4.13.2 kernel. Whatever happened to times in slightly older kernels when VIRT_CPU_ACCOUNTING_GEN was enabled seems to have been fixed in newer kernels.

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

Why I shouldn't do that? Sorry, but I can't see a reason to pin the installation directory to a predefined value ("well known location").
Then, why can I still change the installation directory for gpg4win?

You can't and you shall not.

Hi, thanks for the report.

I have also experience the same bug and reported it on:
https://bugs.kde.org/show_bug.cgi?id=385390

$ 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.

Oh I see you did the Right Thing which back then I was too lazy to do. Thanks.

1 - How that key pair was seeded ? For Instance.

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

The code can be changed like:

• ENTRY_LOCK for mutual exclusion for ENTRY_CTX and pinentry communication
• Add ENTRY_OWNER_LOCK for mutual exclusion for accessing ENTRY_OWNER and ENTRY_LEVEL.

I'm going to change the code a bit.

I got it working.. turns out I had to force a migration by doing an rm ~/.gnupg/.gpg-v21-migrated.

Thanks!

The Linux specific solution in /D450 looks like a good solution but it needs some testing.

I would consider this feature request. Right now you can do this by providing an empty keyring.

I am pretty sure that older cards required this behaviour. It might have been a workaround for a bug in scdaemon, though - I am not sure. So we should test this with all available card versions.

But how can I influence the target directory for GnuPG during an automatic installation? We are not using the default directories.

Right, this differs. GnuPG is now installed at a well known location. Actually the Gpg4win installer includes the standard GnuPG installer and it is possible to update just GnuPG without a need to update the entire gpg4win.
This avoid multiple installs of GnuPG with all its problems.

Hello all together,

I close this for now. If you run into problems with 2.2.2 again, please re-open this bug.

Thanks for the list

Using an npth function is not good because we want to come up with a reasonable iteration count. Allowing npth to switch threads would not be good. The Linux specific solution in /D450 looks like a good solution but it needs some testing.

Yesterday I could reproduce that emails in the "send" folder cannot be decrypted anymore.

How about D450: clock_gettime if CLOCK_THREAD_CPUTIME_ID is available.?

Here is the list:

• libgcrypt
• libassuan
• ntbtls
• gpgme : autogen.sh is ready
• npth

rG3b66a256e376: agent: Allow recursive use of pinentry. fixes the test case above.
I wish it doesn't cause any other issues.

OK, I can make reproducible error case:

Applied to 2.2 branch.

I fixed for master.
It will be into 2.2.

Verified that the fix works, I can create subkeys now.

This week I'm trying to make progress with this issue.

Confirmed, this is the exact same problem!

Thanks for the information.
Closing, as I pushed rC94b84360ca55: Add OID information for SM3..

CESI also publishes a complete white pager documenting OID assignment in details. See http://www.cesi.cn/201612/1688.html and download the pdf. Search "10197" and I see the following info:

OK, I found: http://www.oidchina.cn/oid/release/1.2.156.10197.
站点： 国家OID注册中心
数字OID： 10197
中文OID：
英文OID： sca10197
应用范围： 密码标准化技术委员会

I use: 1.2.156.10197.1.401

Thanks!

The obvious fix to unlock and relock the pinentry during the callback would have the problem that instead of the confirmation request a pinentry from another connection may pop up. That would be quite confusing.

I moved most of the output to the debug category. Everything elese does not make much sense. I also fixed the stats printed for each reordered/fixed key to be prefixed with the keyid so all info is on one line. -q should fully silence them.

The trust-model=direct does not care about signatures or user ids. It simply checks the user assigned _ownertrust_ to decide whether a key is valid: