STDIN behaviour change ( 2.2.44/2.4.5)
Werner Koch
wk at gnupg.org
Thu Dec 12 12:08:42 CET 2024
Hi!
On Wed, 11 Dec 2024 19:58, Dirk-Willem van Gulik said:
> After an update to 2.4.5 - we’re seeing an odd behaviour change (not sure it is regression) - where GPG seems to wait for an EOF as opposed to the end of message.
I am not sure what you mean by EOF vs. end of message. How should gpg
distinguish your two use cases - it reads the input and acts upon it.
There might have been changes in the input buffering but that can't
be the problem.
On Unix we use read(2) until it returns 0 to indicate EOF or until we
see an error and the errno is EPIPE. All other errors will print an
error message.
For reference the code in 2.2 is:
do
{
n = read (f, buf, size);
}
while (n == -1 && errno == EINTR);
if (n == -1)
{ /* error */
if (errno != EPIPE)
{
rc = gpg_error_from_syserror ();
log_error ("%s: read error: %s\n",
a->fname, strerror (errno));
}
}
else if (!n)
{ /* eof */
a->eof_seen = 1;
rc = -1;
}
else
{
nbytes = n;
}
and in 2.4:
read_more:
do
{
n = read (f, buf + nbytes, size - nbytes);
}
while (n == -1 && errno == EINTR);
if (n > 0)
{
nbytes += n;
if (nbytes < size)
goto read_more;
}
else if (!n) /* eof */
{
if (nbytes)
a->delayed_rc = -1;
else
{
a->eof_seen = 1;
rc = -1;
}
}
else /* error */
{
rc = gpg_error_from_syserror ();
if (gpg_err_code (rc) != GPG_ERR_EPIPE)
log_error ("%s: read error: %s\n", a->fname, gpg_strerror (rc));
if (nbytes)
{
a->delayed_rc = rc;
rc = 0;
}
}
The change in 2.4 (from 2018) is due to
https://dev.gnupg.org/rGbfc11816444512b4ebcc6617d3c3b5988e753de3
which tries to utilize larger buffers.
Shalom-Salam,
Werner
--
The pioneers of a warless world are the youth that
refuse military service. - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 247 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20241212/635b8888/attachment.sig>
More information about the Gnupg-devel
mailing list