From: Job Snijders <job@bsd.nl>
Subject: Re: rpki-client: in filemode read concatenated sequence of objects
To: Theo Buehler <tb@theobuehler.org>, tech@openbsd.org
Date: Mon, 13 Jul 2026 07:11:39 +0000

On Mon, Jul 13, 2026 at 09:06:56AM +0200, Claudio Jeker wrote:
> On Mon, Jul 13, 2026 at 08:53:44AM +0200, Theo Buehler wrote:
> > > There is an XXX to also add support to be able to read concatenated gzip
> > > streams. Later on I'd also like to add the ability to read from stdin
> > > ('rpki-client -f -'). Man page will also need a slight tweak.
> > 
> > There is a fundamental design issue that needs careful thought.
> > 
> > This change means that we are now parsing stuff under a wide pledge.
> > In particular, the libz and ASN.1 code is no longer confined to
> > "stdio rpath" like it was before. It would be nice if that could be
> > addressed one way or the other. Perhaps not running this by default
> > would be an option...
> > 
> > I am also very annoyed at ARIN that they can't be bothered to fix their
> > incorrectly encoded objects which have been flagged many times by several
> > groups over the years, so instead of looking only at a few octets to get
> > the lengths, we need to slurp in, parse and immediately free the whole
> > thing. That's just disgusting.
> > 
> 
> I agree with this. Also passing a stream of concatenated objects via
> RTYPE_FILE has limitations since we limit the message size to 50MB right
> now.

Note that the stream is chopped up and the individual objects are
passed as RTYPE_FILE (kinda like passing multiple files to '-f'), so I
don't think that 50MB limit play much of a role here? (I saw no issue
processing a gigabyte-sized stream.)

> We do FD passing for http so an option is to use fdpassing in filemode as
> well. That would allow us to move all the parsing into a proc that is
> highly restricted via pledge.

good idea