> I think there are two cases of interest: > > 1) a file or signature in the rpm is corrupted, the signature doesn't have a matching > 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: > https://github.com/rpm-software-management/rpm/blob/master/plugins/fsveri.... > > 2) after installation, a file from an fs-verity enabled rpm gets one or more blocks > corrupted > The first read of a corrupted block from disk (the good uncorrupted page might survive in > 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. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
