From: Theo Buehler Subject: Re: rpki-client: convert mft.c to opaque ASN1_STRING To: tech@openbsd.org Date: Mon, 1 Dec 2025 16:52:56 +0100 On Mon, Dec 01, 2025 at 04:30:29PM +0100, Claudio Jeker wrote: > On Mon, Dec 01, 2025 at 04:09:37PM +0100, Theo Buehler wrote: > > First, more of the same. I'm not sure I like the data/length reuse > > in mft_parse_filehash(), but using fdata/flength and hdata/hlength > > or similar didn't seem to make things any better. > > > > I added an XXX for a future check to avoid the possibility of someone > > fiddling with the unused bits octet if the hash ends in a few 0 bits. > > Tihs will be easier once we have API and I'll have audit the other bit > > strings anyway. > > > > For the two comparison functions, we can use ASN1_STRING_cmp() > > for simplicity. If length and data compare equal, this adds a type check, > > which is fine since the template ensures that we compare two IA5 or > > two bit strings. The assert can be dropped since the uniequeness check > > comes after the length check in mft_parse_filehash(). > > This looks fine. I don't really want to understand the horror of the > unused bits octet but doesn't the current code have the same issue? Yes, it's been like this since forever - we fail to nail that one down. A bit string has an arbitrary bit length and is zero padded to the next multiple of eight. The unused bits octet keeps track of the 0-7 padding bits added. IOW you get between 1 and 3 bits to play around with for every hash that ends with zero bits.