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

On Mon, 2026-03-09 at 20:28 -0400, Neil Horman wrote:
> 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

No, that won't work (alone). We would have to examine the two bytes and
read further if the header is not complete yet before calling
ASN1_get_object().

Tomas

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

-- 
Tomáš Mráz, Chief Technology Officer, OpenSSL Foundation
Join the Code Protectors or support us on Github Sponsors
https://openssl-foundation.org/donate/

-- 
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/f80b31550e5e0df8de03d116229093521ae85c85.camel%40openssl.foundation.