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

jessorensen notifications at github.com
Thu May 28 14:50:24 UTC 2020


@jessorensen commented on this pull request.



> @@ -430,6 +438,10 @@ typedef enum rpmSigTag_e {
     RPMSIGTAG_SHA256	= RPMTAG_SHA256HEADER,
     RPMSIGTAG_FILESIGNATURES		= RPMTAG_SIG_BASE + 18,
     RPMSIGTAG_FILESIGNATURELENGTH	= RPMTAG_SIG_BASE + 19,
+    RPMSIGTAG_VERITYSIGNATURES		= RPMTAG_SIG_BASE + 20,
+    RPMSIGTAG_VERITYSIGNATURELENGTH	= RPMTAG_SIG_BASE + 21,
+    RPMSIGTAG_VERITYSIGNATUREALGO	= RPMTAG_SIG_BASE + 22,
+    RPMSIGTAG_VERITYSIGNATUREBLKSZ	= RPMTAG_SIG_BASE + 23,

> > Block size is a little tricky, as it depends on the file system block size, which depending on the file system is either fixed or page size. I was planning on adding option parameters to rpmsign allowing someone to specify them for the case they want to build rpms on one platform to be installed on another platform.
> 
> Eek. This seems terrible from rpm POV.
> 
> I mean, rpm's get built on some system somewhere, and signed on another, and then installed on wide variety of anything that we have zero control (or interest) over, data in rpms simply cannot be filesystem specific. Or page-size specific for that matter - while arch specific packages are obviously arch specific, a huge part of rpms are noarch where no such assumptions can be made.
> 
> I get that on the kernel side the filesystem block / page size is the smallest unit that will be read in at once, but seems to me the verity block size should be hardwired to the lowest common denominator (something like 512 or 1024) and verification on page-in looks at the data at that denominator size.

It's not pretty at all, I totally agree. The problem is that the kernel has to hold the Merkle tree in memory while files are opened, so the smaller the block size, the larger the memory footprint. The default should be PAGE_SIZE for public packages, but I would like to retain this option for those who package and maintain their own rpms, if that's OK with you?

-- 
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_r431898002
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20200528/81d9d937/attachment-0001.html>


More information about the Rpm-maint mailing list