That was obvious. rG6fc5df1e10129f3171d80cf731f310b9e8d97c26 fixes this.

When doing a "gpgsm --with-validation -k foo" (assuming you have a cert foo) gpgsm now goes into a loop and prints the certficates that match "foo" over and over again. I have not tested if it was caused by this change but I think it is likely.

Smartcard support is a big advantage of using the GnuPG backend and it should work of course.

Fixed in amster and 2.2:

This requires too much changes and does not reflect the reality. It actually makes debugging harder for us.

I pulled that branch with the commit w/o problems. However, as noted on your commit I won't apply that because it does not make any sense to change boilerplate blurbs for just an additional 's'. Nobody really uses that and browser can try to use https first. Sorry, there are more important things around.

Helo and forgive me for the ignorance, Iam a new.
I subscribed to this topic because I need a fix like that, I have 2 yubikeys with same subkeys...
Now how is possible to install from master; It's about a debian based distro. Also, when this will be pushed for updates via apt-get;
Thank you.

I imported 39 certificate files at once with Kleopatra with about 700 certificates and it worked. Took a long time though so It would be nice if Kleopatra would show a progess indicator or some indication that the import is running. But this is a different issue.

Feature supported in master.

The change is adopted. To close this patch, I take over.

Great :-)
This was a change (fixing file descriptor leaks in iconv.m4) that I needed to do for building fuzzing
https://github.com/google/oss-fuzz/blob/master/projects/gnupg/fuzzgnupg.diff#L178

I patched version 1.13.0 with that commit and installed the patched version on Monday. It appears to have fixed the problem.

Or a better tl;dr; When you send mails without "inline" option everything is fine and standardized. The problem is that the old version of GpgOL that your college uses is too stupid to handle this ;-)

Yes your colleague should or basically needs to upgrade. 2.2.3 is very outdated. There are security issues that were fixed by then etc.

In T4515#125651, @aheinecke wrote:

Hi,

What client does your colleague use so that you have to use PGP/Inline?

That format where the attachment is it's own PGP Encrypted file is very problematic. You basically have mutliple signature and encryption states. An attacker can easily remove or add attachments to the message. The attachment name is leaked. etc. Also see: https://wiki.gnupg.org/PgpPartitioned

Our opinion is that if you really _have_ to use PGP/Inline that you must do so manually using Kleopatra's notepad and Encrypted files.

I am a bit unsure if I just close this as "Wontfix" or move it to Wishlist. I think for now I go with Wishlist but do not expect that feature soon. At least until maybe some really important use case comes up.

Anyway, thanks for your feedback. It is always valuable to know what users would like to have.

Best Regards,
Andre

It's complicated to have a good solution, because we need to change assumption (serial number identifies keys).

Will give you more detailed info about your certificate. For even more details use --dump-chain instead of --list-chain.

Thanks

Applied to master and 2.2. Thanks.

Right, that was missing. Fixed for master and 2.2. Noet that for kill and reload we added this already in 2016.

What client does your colleague use so that you have to use PGP/Inline?

No, that is excessive. If the license blurb will ever be change this can be done but not just because of changing a single letter.

Sorry, I will revert this.

Attacks always get better and thus mitigation based on uncommon jpeg UATs would help only for a short time.
Maybe having a SHA-1 warning in 2.2 is also needed.

Sorry, I have read the short paper wrongly. I misunderstood as if a forged key could be made using existing key.

While I think that building with GCC 4 on Solaris 11/12 is minor issue, requirement of newer POSIX API (on GNU/Linux) would be a bit serious issue.
I pushed my change to fix this.

(hm, i'm pushing apparently successfully to playfair.gnupg.org:/git/libgcrypt.git but it is not showing up here. if you want to fetch this patch, you can also find it on the http-to-https branch at https://gitlab.com/dkg/libgcrypt.git

I would prefer not to fix that. I did some experiments on replacing all the runtime parsed ECC constants by static data. Adding the other constants will then be simple.

I've prepared patch for statically defining mpiutil contants, but I can leave it out and not push to master.

I think you are saying that dirmngr receives the query term as escaped data in the assuan connection from the dirmngr client (typically, gpg, which itself decides how to percent-escape what it feeds into libassuan).

Oh, ah. Ok. I do not read c't no more since about 2005. They are busy people and lead into the right direction.

There is actually a problem with --use-embedded-filename. Given that the option his highly dangerous to use we have not tested this for ages. We will see what you we can about it.

The last lines that the process currently holding wrote in the log: