Just tried this but can't replicate it:

$ ../g10/gpg -dv <1.msg --override-session-key 7:D6E1027D58A0CB047C41EA881A137197 --status-fd 2 
gpg: public key is 7F3B7ED4319BCCA8
[GNUPG:] ENC_TO 7F3B7ED4319BCCA8 18 0
gpg: encrypted with ECDH key, ID 7F3B7ED4319BCCA8
[GNUPG:] BEGIN_DECRYPTION
gpg: AES encrypted data
[GNUPG:] DECRYPTION_INFO 2 7
gpg: original file name=''
[GNUPG:] PLAINTEXT 62 1508859245 
[GNUPG:] PLAINTEXT_LENGTH 68
"Well hello there Charlie Brown, you blockhead."
                -- Lucy Van Pelt
[GNUPG:] DECRYPTION_OKAY
[GNUPG:] GOODMDC
[GNUPG:] END_DECRYPTION
$ echo $?
0
$ gpg -k 7F3B7ED4319BCCA8
gpg: error reading key: No public key

Unfortunately --batch option doesn't help, it only suppresses user input.

$ gpg2 --pinentry-mode loopback --batch --delete-secret-keys F4433F96910C9AC1FEF65A7299A5538C769B6150
gpg: deleting secret key failed: No pinentry
gpg: deleting secret subkey failed: No pinentry
gpg: F4433F96910C9AC1FEF65A7299A5538C769B6150: delete key failed: No pinentry

GPG pinentry works well on my Gnome desktop (wellformated form appear) but I have a problem when I need remove secret key (enter passphrase) on remote machine via SSH.
It can be handled with --export why not with --delete-secret-keys?
Is there some fix already? Or roadmap this will be fixed? Or some workaround how can I remove secret key remotely via SSH?

gpg-agent sometimes pops up confirmation dialogs. This can't yet be handled with the loopback pinentry. Try gpg option --batch.

I tried to melt it down to a specific beta release with which it isn't possible anymore to decrypt send emails.

Is this still a problem with 2.2.1? IIRC, we fixed a few DNS things.

Jochen, I am currently using Windows 10 version 1607 (OS Build 14393. 1230).

What I use to force the old keyring format is to export a public key to a file and rename that to pubring.gpg. And of course delete the pubring.kbx.

Won't we fixed for 1.4 and 2.0 (which is too close to EOL). Has been fixed for master; see T2359.

This can be triggered if --max-passphrase-days has been set.

In 2.2.2 you will see "Secret sibkeys are available" and commands which require the primary key are disabled.

Since this is a bug that is related to two different parts of the gpg4win package, this bug now only cares about the GpgOL Issue, that GpgOL crashes and cant decrypt messages from the sent folder that are encrypted with S/MIME. All File Based Issues are belonging to Kleopatra are documentet in the KDE Phabricator (https://phabricator.kde.org/T7310).

What Version of Windows do you use? If you use an older Windows (pre 7) please follow this guideline: https://wiki.gnupg.org/Gpg4win/releases/3.0/notes

1. Mails encrypted with S/MIME are stored with "No Data" in the sent EMail folder, but arrive properly at the recipients (you will recieve a readable copy, if you add yourself to the list of recipients). This Issue breaks the GpgOL Plugin after some time which is leading to the described Problem.

I am now examining OID allocation.
I'll add the OID of SM3 into sm3.c.

For this proposed change, it is merged.
I'll add OID thing.

We could signal an error. However, that would break existing behaviour and can only be done for 2.3.

The rest looks technically okay. My French is too limited to say anything about the translation, though.

Thanks for your great help! Once merged, I will continue the contributions to coreutils and gnulib in order to make sm3sum program eventually available.

gpgme does not known about return codes because it uses a double fork approach. However, certain staus lines could have the same effect.

In rD075b9032092e903a31374c20d9d6184083c0f175#49208, @aa wrote:

Nice tabulation, are you guys COBOL programmers now ?

I'm going to add your change except src/gcrypt.h.in.

Hm, perhaps this non-zero return code is due to not being able to write to the GNUPGHOME directory, actually. It goes away when GNUPGHOME is writable. That doesn't make sense either -- this operation doesn't actually depend on being able to write to GNUPGHOME, so it shouldn't return a different error code if GNUPGHOME is unwritable.

V2 Changelog:

In D449#3605, @gniibe wrote:

Thanks for your quick response.

It's good that we have the OID already.
I read the Chinese document briefly, I realized that its basically equivalent to the IETF draft.

Please update your sm.c so that it includes Example 2 in the document.
Then, I will merge the code into the master of libgcrypt git repo.

After that, I will add the code for OID, examining its status. Does it work for you?

In D449#3606, @gniibe wrote:

IIUC, it's defined by the agency in 2010, and then it was published as the national standard: GM/T 0004-2012 SM3密码杂凑算法

IIUC, it's defined by the agency in 2010, and then it was published as the national standard: GM/T 0004-2012 SM3密码杂凑算法

Thanks for your quick response.

In D449#3603, @gniibe wrote:

For the implementation, it looks good for me.
I have suggestions and some requests.

Suggestions:

• I think that the all test vectors in draft-shen-sm3-hash should be in sm3.c.
  
  If I read your code correctly, the "abc" in Example 1 is there. I think that the vector in Example 2 in the document should be also provided.

For the implementation, it looks good for me.
I have suggestions and some requests.

I am closing this bug report, as I can't get feedback to fix something.

Nice tabulation, are you guys COBOL programmers now ?

GnuPG 1.4 is only for old features. New features are only supported by GnuPG 2.2.

2. Files that are Signed and Encrypted to a S/MIME Certificate is broken. When you select a file and encrypt and sign it to a recipient, only a detached signature will be created and the Encrpyted file is missing. (Very similar to Issue 1, but file based).

https://phabricator.kde.org/D8368

Can you please try again with the standard shell (and not the power shell)?

Please look in the status bar of your desktop. You should see a (blinking) tab for the Pinentry. Unfortunately it is not always possible to get the Pinentry into the foreground and Windows will instead show it in the status bar.

Same issue exists in 2.2:

Same here on current stable (3.0.0):

DCO = Developer's Certificate of Origin. See gnupg/doc/HACKING under "** License Policy" .

The long term goal is to replace sshcontrol by aflag in the extended private key format. This would instantly solve the bug. Thus closing.

Let's move that to master.

We can't change that anymore. So the question is how and whether to fix it. Right now gpgconf --list-dirs has no need to ask gpg-agent for the actual socket and it would be a catch-22 anyway. Thus to fix this we need to parse the gpg-agent.conf in gpg.conf directly.

We can later decide whether to backport this to 2.2

A backport to 2.0 does not make anymore sense given EOF in 2 months.

No info received, similar to another fixed bug, and for 2.0 which will soon reach EOL.

I am preparing the patch I am using against 2.2.0. What is DCO?

gniibe: Can you check the status?

2.0 will reach EOL soon and we have received no response. Thus closing. If the problem persists with 2.2 (e.g. from gpg4win 3.0) please re-open this bug.

Won't be fixed for 1.4.

No, I used the standard Windows command line

2.0 reached eol in 2 months so need to check it. For 1.4 I assume it has been fixed ;-)

@perske, may I ask you to send a DCO and an possible updated patch against 2.2 to gnupg-devel@ ? I would like to add it to 2.2.2. Sorry for the delays.