Re: [EXTERNAL] Re: Can no longer receive short ASN1 messages

Ok, that did it, If I stream in data from a process that never closes
stdout, to stdin of the above program, I see the hang

It appears (at least in this case, but I presume in the socket case as
well, since TCP generally uses blocking sockets), we get stuck in the read
syscall, waiting for more bytes that never appear.

Unsure what to do about it.  Possibly just reduce the HEADER_SIZE to be two
bytes, which is the minimal size IIRC for an ASN1 object


On Mon, Mar 9, 2026 at 7:49 PM Sands, Daniel N. <[email protected]> wrote:

> Small correction:  Use fwrite instead of fprintf since there’s an embedded
> NULL.
>
>
>
> *From:* 'Sands, Daniel N.' via openssl-users <[email protected]>
> *Sent:* Monday, March 9, 2026 5:47 PM
> *To:* Neil Horman <[email protected]>
> *Cc:* [email protected]
> *Subject:* RE: [EXTERNAL] Re: Can no longer receive short ASN1 messages
>
>
>
> Do you have a reproducer available?
>
>
>
> I tried this quickly with the following code (need to link it statically
> since I'm hacking into internal interfaces)
>
>
>
> The problem with your reproducer is that you are not reading a socket.  So
> when you hit end of file, you get a definite end of file condition.  The
> same works for my case:  When the sender is killed after sending the
> message, it shuts down the socket, which allows the receiver to go ahead
> and try to use what it got.  Let’s have it receive through stdin or
> something like that, and then run the program with a separate program that
> writes those bytes to stdout and then does not exit.  Pipe this into the
> receiver program.
>
>
>
> Sender:  Something like,
>
>
>
> #include <stdio.h>
>
>
>
> int main() {
>
>     fprintf(stdout, “\001\002\000\001”);
>
>     sleep(1000);
>
> }
>
>
>
> Receiver:
>
>
>
> #include <stdlib.h>
> #include <stdio.h>
> #include <openssl/bio.h>
> #include <openssl/buffer.h>
> #include "internal/asn1.h"
>
>
>
> int main(int argc, char **argv)
> {
>     BIO *in = BIO_new_fd(stdin, 0);
>     BUF_MEM *membuf = NULL;
>
>     asn1_d2i_read_bio(in, &membuf);
> }
>
>
>
> Run as:  sender | receiver
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Mon, Mar 9, 2026 at 4:49 PM 'Sands, Daniel N.' via openssl-users <
> [email protected]> wrote:
>
> As of 3.5.x, after an issue having something to do with headers, I can no
> longer receive messages of less than 8 bytes.  As an example, if I only
> need to send a status code as a response, I will send 1 tag byte, 1 length
> byte, and possibly 1 byte indicating an integer status code.  Since this is
> a TCP socket, I keep the socket open for further communication.  The
> receiving side now insists on receiving at least HEADER_SIZE bytes (8)
> before it will do anything, so now both sides are at a stalemate—the
> receiver still waiting for its message, and the sender waiting for further
> communication from the sender.
>
>
>
> I saw in issue 21777 why this was done, but the strategy is not working
> for short messages.  I suggest an alternate strategy where you add a “need”
> variable, which is the very least amount of bytes necessary to decode the
> next part, and want will be some value higher than that.  If “want” bytes
> can be read, awesome.  If it’s stalled between “want” and “need” then just
> go ahead and process it.  If it’s less than “need”, then, and only then, do
> you continue the loop.  Obviously, “need” would only start at 2, since the
> smallest legal DER encoding is 2 bytes (the NULL type).  It would expand if
> the tag or length turn out to be multiple bytes.
>
>
>
> Anyway, is there a workaround for this, other than reducing HEADER_SIZE
> and recompiling, or attaching non-sequitur data just to reach the 8-byte
> minimum?
>
> --
> You received this message because you are subscribed to the Google Groups
> "openssl-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to openssl-users+unsubscribe-MCmKBN63+Bmbup2nOX2J7Q@public.gmane.org
> To view this discussion visit
> https://groups.google.com/a/openssl.org/d/msgid/openssl-users/SA9PR09MB5309355179862CB0C56F6C35DB79A%40SA9PR09MB5309.namprd09.prod.outlook.com
> <https://groups.google.com/a/openssl.org/d/msgid/openssl-users/SA9PR09MB5309355179862CB0C56F6C35DB79A%40SA9PR09MB5309.namprd09.prod.outlook.com?utm_medium=email&utm_source=footer>
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "openssl-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to openssl-users+unsubscribe-MCmKBN63+Bmbup2nOX2J7Q@public.gmane.org
> To view this discussion visit
> https://groups.google.com/a/openssl.org/d/msgid/openssl-users/SA9PR09MB5309D9A09EA8B5BBDA37E0DFDB79A%40SA9PR09MB5309.namprd09.prod.outlook.com
> <https://groups.google.com/a/openssl.org/d/msgid/openssl-users/SA9PR09MB5309D9A09EA8B5BBDA37E0DFDB79A%40SA9PR09MB5309.namprd09.prod.outlook.com?utm_medium=email&utm_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups "openssl-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openssl-users+unsubscribe-MCmKBN63+Bmbup2nOX2J7Q@public.gmane.org
To view this discussion visit https://groups.google.com/a/openssl.org/d/msgid/openssl-users/CAJbOq15ezA_FwzkMF0MGLZmfHGMmq-%3DHjBpZ7%3DxCrPAq%2B1hdZg%40mail.gmail.com.