This looks like the same problem I encountered in Gentoo's Portage. To unlock the binary package signing key, Portage will run the equivalent of gpg --homedir ... --digest-algo ... --local-user ... --output /dev/null /dev/null. If unlocking fails (due to e.g. wrong password), /dev/null is removed: https://bugs.gentoo.org/912808

Needs to be checked for 2.4 - no backport to 2.2, though.

Needs to be checked again with stable. No backport to 2..2, though.

Won't be backported to 2.2 once we got something in 2.4.

Ok. Thanks for testing. That confirms my suspicion. rOdd3ff8397aaf62e58fa9405ddc5397cb6bcfdc29 is to blame here with the setReadFlag line as the specific cause. Because it is intended to trigger a save back. The problem was that we had circumstances where other addins changed the mail and really wanted it to be saved back to the server. So we call "save" before decrypting the mail to ensure that these changes are saved and then we decrypt, put in our temporary plaintext and ensure that the plaintext never is saved.

I testet it with 4.10 and GggOL 2.5.6. The file isn't changed if I open it. So it seems the change happend in 4.2.0.

Do you know if this is something new that started to happen with 4.2.0 for the first time or did it happen with 4.1.0, too?

I'll swap us over to out of source build for this as well. I've been doing it gradually for the gpg suite. Thanks.

The following patch fixes this (for me):

diff --git a/lang/qt/tests/Makefile.am b/lang/qt/tests/Makefile.am
index 32ad6466..aedd3264 100644
--- a/lang/qt/tests/Makefile.am
+++ b/lang/qt/tests/Makefile.am
@@ -51,10 +51,10 @@ LDADD = ../../cpp/src/libgpgmepp.la ../src/libqgpgme.la \
         ../../../src/libgpgme.la @GPGME_QT5_LIBS@ @GPG_ERROR_LIBS@ \
         @GPGME_QT5TEST_LIBS@ @LDADD_FOR_TESTS_KLUDGE@ -lstdc++

This happens because you build in the source directory and therefore the wrong debug.h is found. While this should work in general we strongly suggest to use a separate build directory.

No problem ;) Sorry for my snarky reply. Hope it worked for you now.

Noticed this issue was still open. This was resolved.

OK, I'm sorry, please accept my apologies for not having read the dialog message carefully enough. It seems I ignore the second sentence, replacing it with the omnipresent "Do you want to continue?" in my mind. Maybe the excuse is that it was terribly hot and damp in my office, preventing me from thinking.

😂 Skandal! Ein BUG!: "Möchten Sie die Installation ohne Administrator-Rechte fortfahren?" und Sie sagen "Nein". Ja dann brechen wir ab weil sie eben *nicht* fortfahren wollen.

Strong objection to close: When answering the question with "no", installation aborts!

This could have something to do with our changes to g4wihelp.c to adapt to the new plugin API.

You can install Gpg4win without admin rights. It requests "Highest available" rights by default to be installed into the protected Program Files (x86) folder. When you are not in the Administrators group It will install into your home directory much like firefox does. Any maybe if you don't want to leave a footprint installing Gpg4win on the System (without admin rights) where you don't have admin rights is kind of beside the point. You either leave a footprint by the installation or you could just use the installed Gpg4win there.

Pushed the change to:

• libgpg-error
• libassuan master
• libgcrypt master
• ntbtls
• npth
• libksba
• gpgme
• scute

Yes, gpgtar emits a SUCCESS status. gpgme should probably check for this.

[For bug reports please don't refer to some other site - at least a brief but useful description should always be included]

I mostly used ed25519 keys and thus I do the avove command pretty often without problems. Can you please add

-v --debug lookup

to the command line show us the log (send privately to my standard mail address (wk@gnu...) if you feel that data is too sensitive for the public).

Thank you. that worked. A pitty gpgv can't read from fd using process substitution

7b7e16ae923d:/data/loglib# gpgv --keyring <(gpg -o - --dearmor ../ecs.keys) jul-ecs-formatter-1.5.0.jar.as
c jul-ecs-formatter-1.5.0.jar
gpg: WARNING: unsafe permissions on homedir '/root/.gnupg'
gpgv: Signature made Sun Aug 21 07:52:24 2022 UTC
gpgv:                using RSA key 46095ACC8548582C1A2699A9D27D666CD88E42B4
gpgv: Can't check signature: No public key

But I had two steps even before, so this could work.

7b7e16ae923d:/data/loglib# gpgv --keyring ../ecs.keys.gpg jul-ecs-formatter-1.5.0.jar.asc jul-ecs-formatte
r-1.5.0.jar
gpgv: Signature made Sun Aug 21 07:52:24 2022 UTC
gpgv:                using RSA key 46095ACC8548582C1A2699A9D27D666CD88E42B4
gpgv: Good signature from "Elasticsearch (Elasticsearch Signing Key) <dev_ops@elasticsearch.org>"

gpgv might not support ASCII armored key files. Try with a binary key file.

Hi, thanks for prompt response. I have just bunch of public keys I want to verify against. They have form of
-----BEGIN PGP PUBLIC KEY BLOCK-----. If I try using the key file as a keyring I get error.

I think you should simply use gpgv for verifying signatures. gpgv exists for exactly this use case. You don't even have to import anything because you can directly pass a keyring to gpgv.

without understanding more of your setup, which user starts it with which rights and when and so on we cannot really help you here. This is a classical support question. You might want to check the permissions on the lock file. Maybe they are created by a user with higher privileges e.g. to interactively manage the keys, and then the batch user comes along and does not have the permission to obtain or create the lock file. My suggestion would indeed be to use the --homedir parameter in the batch script and ensure that the user has full access rights to that folder and no "Adminstrator" messes with the files / permissions in there.

I pushed the commit: rE64532db11fcd: build: New configure option --with-libtool-modification.

Okay, will go into the next revision. Thanks.

Thanks for the reply!

The patch to the specs would be this:

        The three data items hashed for document signatures need to
-       mirror the values of the Literal Data packet.  For detached
-       and cleartext signatures 6 zero bytes are hashed instead.
+       mirror the values of the Literal Data packet.  Note that for a
+       detached signatures this means to hash 6 0x00 octets and for a
+       cleartext signature this means to hash a 't' followed by 5 0x00
+       octets.

Regading your first point: From gnupg (2.4) sign.c:hash_sigversion_to_magic

Oh wait. That shows a Problem in our side. We should include the full chain in our signature. I am renaming your task and will at least investigate if we do or if that maybe changed the last time we updated the certificate. Which might have been after 4.0.3

OK, had to install the intermediary CA certificate from https://support.globalsign.com/ca-certificates/intermediate-certificates/code-signing-standard-ev-intermediate-certificates . For some reason it was missing from my system.
After installing things look good.

Should be fixed.

This works on Linux with KMail and with Claws (although with Claws the attachment is added twice).

Pushed the change to libgpg-error.

That assumes that libtool won't change substantially as it did several times in the past and broke our cross compiling stuff. But as long as we keep the ltmain.sh in our repo and tarball the patch is okay because it better documents the chnages.

I learned that AC_CONFIG_COMMANDS macro can be used to improve the case of config.status.

How about the change like:

this is not true. Our installers are always signed, even the included binaries are mostly signed.

Other options would be

• to display a warning if there are inline images in the email.
• an option not to automatically sign emails if they contain an inline image.

works. Certificates are shown in alphabetical order to the user and expired subkeys are ignored for encryption even if they are newer.

Applied to 2.4.

I have built it according to the method described here.
(https://wiki.documentfoundation.org/Development/BuildingOnWindows)

I wonder why you mention Visual Studio and Cygwin? Either it is Cygwin or a native Windows build.

Fixed in: rP66abf7cb1e1b: Update GPL2 for new FSF address. Use URL for license.

works, tested with the provided example certs

information shows now up immediately, when the public key data is imported

Fixed in master.
Will backport into 2.4, after testing.

Thanks. Wouldn't that require OpenLDAP on every system with gnupg?

Actually it has been fixed for the PBES2 case in 2.2 and 2.4. PBES2 is used with AES128 and AES256. I doubt that there is any value in adding such support for the legacy RC2 and 3DES methods.

Same for the backport to 2.2 which uses the same test suite.

We should make building with LDAP mandatory.

Thank you for your report.

This was tested by me against the actual sample and the sample is now part of our internal regression test suite.

related to T6528

This works.

This works, when sign is selected and no standard OpenPGP key for the mail address exists.

Partly done for 2.4. The cram-octet-string stuff is missing, though.

Thanks for the suggested workaround, I am going to try that. And thanks for pointing out this could be related to something like a Yubikey attached. Having the same symptoms as those described in T4581 and here.

I have this regularly. Sometimes waiting helps and it loads after several minutes, sometimes shutting down Kleopatra is the only remedy (because after an hour and more it feels like it ended up in an infinite loop).

Add the check of digest algorithm for EdDSA in: rCd15fe6aac10b: cipher:ecc:fips: Only allow defined digest algo for EdDSA.

No, there are use cases in GnuPG, where we specify the hash algo for signing, and our own tests/benchmark.c.