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.