I think there are two cases of interest:
1) a file or signature in the rpm is corrupted, the signature doesn't have a
cert installed, etc...
in this case, if the plugin is present, when you attempt to install the rpm the verity
enable ioctl will explicitly fail, and presumably so will the rpm install. You can see
most of the details for this sort of case here in the rpm plugin code:
2) after installation, a file from an fs-verity enabled rpm gets one or more blocks
The first read of a corrupted block from disk (the good uncorrupted page might survive
page cache for a while) will result in EIO for read-like system calls and SIGBUS if the
file is mapped (executables, mmap).
Thanks for the information. So in the event of an error, it's expected that the user
would be informed that the error was due to a rpm-fsverity check and they could
potentially reinstall the rpm from a trusted source to resolve the problem? Of course
there's the underlying issue of _why_ it happened, but from the standpoint of wanting
an immediate path forward.