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