Will be updated eventually. Thanks for reporting.

Updates for projects' scripts related to GnuPG for building from source may be needed; So it is at least for libgcrypt; illustration (output filtered):

Because a user in https://mstdn.social/deck/@GnuPG/113011825339406300 did read the documentation, I had a look in the documentation and in other public definitions (e.g. https://www.gnu.org/software/tar/manual/html_node/Formats.html#Formats) and I can understand the questions of the user.

gpgtar is compatible to PGP Desktop's format which they call ZIP. This is technically ustar with the most common extensions. Don't let us go into yet another TAR format discussion.

Well, my hope for this was some kind of Format where we keep the keys + the signature together with encrypted files. Because I think it is an extremely common usecase to decrypt a file, modify it and then to reencrypt it to the recipients that it was encrypted to before and I think it would be a good usability improvement if after decryption, when a file is then encrypted again Kleopatra would have the recipient dialog prefilled with the original recipients. T6564: Kleopatra: Re-encrypt an encrypted folder to the original recpients And for Gpgpass this could be used in exactly the same manner just with a diffrent UI and focused on folders with multiple files.

I am not sure I like every aspect of passtore.sh (e.g. the YAML configuration files and yet another group concept where we probably could reuse Kleopatra groups), but it's good to know that there is already a solution for this issue :)

Using signed files would have been my suggestion, too. For me I would say that "allowed to sign" depends on the ownertrust of the signature certificate. If the ownertrust of the certificate is Ultimate then you can accept the recipient list. Ultimate ownertrust is given for your own keys or for the ones marked with trusted-key in the GnuPG configuration.

Is a solution to this problem by an organization using pass for a log time with quite some users.

Interesting. i'm also not sure this is a good feature. I also still don't think the gpgv man page explains this clearly, but if you don't want to clarify it, i won't bother re-opening this issue.

All given data files are concatenated; not sure whether this is a good feature but iirc pgp 2 did it the same way.

Thanks for this prompt fix! but they're still not aligned. with this fix, the Synopsis is:

For the certificate list it might make sense to have column-specific tool tips, e.g. to give details on "not certified" in the "User IDs" column. For the fingerprint column (just to pick one example) a tool tip makes little sense.

In general, I question the usefulness of the tool tip for the certificate list. The information in the table is already very detailed and for more details there's the details view. Important information that's missing in the table shouldn't be hidden in the tool tip.

Done in 1.11.0.

Back in the ancient days we allowed to dlopen algorithms so to avoid patent problems in certain countries.

Fixed in gpgme 1.21.0.

Fixed in 2.4.4.

No, I am not aware. I can't remember whether PGP once had such a bug because @dshaw did most cross-testing and fixing for PGP bugs. I would suggest to remove any such checks. IIRC, this was introduced by PGP 2 to speed up signature checking. 30 years ago RSA operations were quite expensive.

VS-NfD is not a standard but a classification for restricted data. Software used to convey such material needs an official approval and is bound to certain organizational requirements. That is what "VS-NfD konform" says. The community version of gpg4win does not have this approval despite that it is technically the same code as the approved GnuPG VS-Desktop.

Unfortunately there are real world applications which make use of this option in special environments. Thus we can't remove it. I improved the warning in the man page.

In 2.4, a user need to specify disable-ccid in scdaemon.conf when scdaemon is built with integrated CCID driver (using libusb) but the user wants to use PC/SC driver instead.

To align the documentation of GnuPG, we should not use GNUPGHOME in FILES section.
It may be controlled by --homedir as well as GNUPGHOME.
GNUPGHOME is addressed in the ENVIRONMENT section, so, I don't think it makes sense using $GNUPGHOME}/trustedkeys.kbx.

Thank you. Applied and pushed in: rG260004747016: gpgv: Update used keyrings in doc FILES section

Your tools don't use the chain validation model which is required for QES (at least according to German laws). A signature is still valid even if the certificate has been revoked. You need to consider the context and the time the certificate was revoked.

Here's another data point.

Okay, will go into the next revision. Thanks.

Thanks for the reply!

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

Thanks. I think that it was the oldest one: FSF used to be there in Cambridge, then moved to Tremont St. in Boston, and now it's in Franklin St.

FYI, while going through the licenses again I noticed one of the pinentry files have even older address that so if you would do sed, this would not be matched: