> Okay, this sounds like its headed to the right direction then, I agree this 
> seems like something where the kernel needs to deal with it because it's the 
> only thing that can.
> I see block size is an argument passed to the ioctl() that enables this 
> fsverity for a file, but what does that actually mean? Can individual files 
> have different block size for their Merkle tree? In the current state of 
> things it seems more like a hardwired global'ish thing.
> What I'm getting at is that if we make block size a configurable thing in 
> rpm, then the kernel will really need to support different block sizes for 
> individual files as rpms come from variety of sources and might be signed 
> with different options.
> I'm tempted to say lets just go with a hardwired 4K size for now to keep 
> things simple, we can always add another tag for alternative block size if it 
> becomes necessary for one reason or another.

The block_size argument is used as follows: When fsverity is enabled on a file, 
the kernel will build a Merkle tree for the file, using the specified block 
size. In addition the signature signs the root hash of the Merkle tree, so the 
block size has to match that used to generate the signature, for it to validate.

Each file can use a different block size for it's Merkle tree, but I think it's 
fine for RPM to mandate what block size it's willing to generate. As you say, 
we can add a tag for the block size later if we find a need for it.

I'll update the code to use 4K.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Rpm-maint mailing list

Reply via email to