@pmatilai 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. 

-- 
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_r431678635
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Reply via email to