Note for mails with 2 attachments, where the warning is displayed: Those mails can't be moved in Outlook/GpgOL

Regarding 8. encrypted/signed vcard attachment:

I came from it with stuffing the vector into a QByteArrayView - and then comparing it with the same string being roundtripped thru a copy/paste operation by the user.

I explicitly keep the null byte so that you can simply pass the (pointer to the data of the) vector of bytes to the std::string c'tor. Meh! The c'tor wants const char *, but the vector is const unsigned char * so that one has to reinterpret_cast.

I don't think the trailing zero-byte should survive the conversion to c++ datastructures.

I have documented the function. The documentation is essentially a copy of the documentation of gpgme_op_random_bytes which should make clear that the function essentially behaves like gpgme_op_random_bytes (except that the gpgmepp function creates a buffer instead of taking one).

I guess it would have been better gpgmepp API to add an additional function for getting 30 zbase32 bytes and to omit the mode flag in the generateRandomBytes function instead of mirroring the API of gpgme.

I don't consider this a bug in gpgmepp's code. gpgmepp behaves exactly like gpgme (because it simply calls gpgme_op_random_bytes after creating a buffer of the requested size). With zbase32 you get 30 bytes zbase32 code and, if you requested more bytes, you get uninitialized additional bytes (which happen to be nullbytes, but that's more accidental than intentional). If anything then the problem is that gpgmepp's API is in general un(der)documented.

Looks like this spot was missed when T5037: dn.cpp:181: suspicious loop was fixed. In libkleo's copy of the DN parser I applied the fix in 2023. Too many copies!

Yeah. It's a gpgmepp bug.

I found a possible leak and a possible access of freed memory.

FWIW: Okay, gmime is still a wrapper around gpgme. After decryption it has the ability to get the used session key from the gpgme result structure. Thus, I have been on the wrong trail. The actual problem is not gpgme but more GnuPG's use of Libgcrypt or an actual regression in Libgcrypt. Well, Friday 13th.

This has been specified in 1997 by PGP 5 for a good reason. We talked often enough about this and it does not help to repeat your ideas over and over again. RFC9580 specifies a different protocol than OpenPGP as specified by RFC2440 and RFC4880 but alas grabbed the name OpenPGP for this.

I can't speak for gpgmpp but for gpgme. And the gpgme manual says: