depending on libfsverity

[cgwalters]

Is there any reason for us to not depend on libfsverity? Why are we carrying a reimplementation of things like the digest computation?

[alexlarsson]

The reason is two-fold. First to be easy to include as a git submodule, but also it is because we need a streaming version of the computation and the libfsverity APIs didn't have that.

[cgwalters]

First to be easy to include as a git submodule,

In the future, do we really want to care about that? I'm not sure.

but also it is because we need a streaming version of the computation and the libfsverity APIs didn't have that.

That doesn't seem to be the case at least today, https://github.com/ebiggers/fsverity-utils/blob/4ba79698b0381fe953f2d74b622b3b9586969e2b/include/libfsverity.h#L184 is a streaming API right?

Now I know we have two cases:

• build server (where we may not be able to or want to enable fsverity on files)
• client side

I guess I have a bigger question here: on the client end with mkcomposefs why wouldn't we just enable fsverity, and let the kernel compute its digest which we fetch via the ioctl?

[alexlarsson]

That is not streaming in the same way we need. Yes, you can pass a read_fn to it, but the function is in control of calling it.

What we need it for is that when you call lcfs_write_to() we produce the output bytes one block at a time to a write callback, but we also pass those blocks to a streaming computation of the fs-verity digest. This means that once the image has been written to the caller the digest is available in options->digest out.

This is used for example in ostree when we just compute the digest for an image. If we were to do a two step thing that first creates the image file, and then pass it to libfsverity_compute_digest() we would have to keep the entire file on disk or in memory, which is very wasteful.