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

Reply via email to