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).

Thanks Werner.

I updated the rendered form of the English GPH with a warning and a link to the blog.

Thanks for the hint.

Will be in the next release.

man gpg has a WARNING section right below the RETURN Value section. The 3rd paragraph gives hints on how to use gpg with scripts etc:

https://www.gnupg.org/gph/en/manual/x135.html could benefit from the same treatment under "Clearsigned documents".

A quick fix would be to remove the link

That RFC is Experimental anyway

Ok, then this is only an issue in the VSD versions. (I confirmed with a quick test with Gpg4win-5.0.0-beta413)

That is on purpose. With a signed mail you have at least a way to tell who sent the mail. An unsigned but encrypted mail can be send by anyone and you netter don't use HTML links there.

Thanks for elaborating and the reference to rfc2440 - I now understand where that stray mail (between [RFC2822] and name-addr) in rfc4880 comes from...
Anyway, I'll treat it as if it says RFC 2822 mailbox and will treat angle brackets with bare addresses as optional.

I see, I had rfc2440 in mind which says:

By convention, it includes  an RFC 822 mail name, but there are no restrictions on its content.

thus 4880 refined it a bit. But in practice it is not the same because it is utf8 and not punycode or whatever. let's close this bug because they way it is used will work with all mail clients.

Thanks for the patch but I think it is better to fix this in yat2m. I created a new tag for bugs related to it.