Guarantees of gpg_strerror_r may not hold

[John Scott]

Hi,

From inspecting the gpgrt source code, it seems that for system error
codes and on systems with POSIX-conforming strerror_r, gpg_strerror_r
calls out to strerror_r and, since strerror_r is not guaranteed to, null
terminates the buffer.

However, POSIX doesn't say that a partial error message will have been
written if strerror_r fails with ERANGE, and strerror_r is also allowed
to fail with other errors besides EINVAL and ERANGE. That means that if
the caller didn't initialize their buffer, there is a risk of their
buffer starting with uninitialized memory, something the GPGME docs say
won't happen.

I propose that if strerror_r fails, we should do the equivalent of
	snprintf(buf, bufsize, "GPG error %u\n", errcode);
to populate the caller's buffer.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: This is a digitally signed message part
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20221121/d4701848/attachment.sig>