@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
