[Rpm-maint] [rpm-software-management/rpm] RPM fsverity support (#1203)

jessorensen notifications at github.com
Thu May 28 14:59:44 UTC 2020


@jessorensen commented on this pull request.



> +	    rpmlog(RPMLOG_DEBUG, "fsverity not supported by file system for %s\n",
+		   path);
+	    break;
+	case EOPNOTSUPP:
+	    rpmlog(RPMLOG_DEBUG, "fsverity not enabled on file system for %s\n",
+		   path);
+	    break;
+	case ETXTBSY:
+	    rpmlog(RPMLOG_DEBUG, "file is open by other process %s\n",
+		   path);
+	    break;
+	default:
+	    rpmlog(RPMLOG_DEBUG, "failed to enable verity (errno %i) for %s\n",
+		   errno, path);
+	    break;
+	}

> Ignoring on unsupported filesystems is totally fine, that's exactly what we do for SELinux (which is not supported on all filesystems either). There might well be other specific errors where ignoring is the right thing to do, but in general errors should be treated as such and fail the install, or at least issue a warning that something might not be okay.

OK, excuse my ignorance here. If I return RPMRC_FAIL for these, will it fail the installation of the package, or just spew warnings? I didn't want to get into a state where I had to check the file system for each file, before I enabled verity on the file.

Do you prefer I return RPMRC_OK if it's not supported, but RPMRC_FAIL if it actually fails? I'll have to have another look at all the return values to make sure I have them covered correctly.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1203#discussion_r431905174
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20200528/2bd30faa/attachment.html>


More information about the Rpm-maint mailing list