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

[jessorensen]

@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,

> Yes. So you'd have:
> 
> ```
> RPMTAG_VERITYSIGNATURES = RPMTAG_SIG_BASE+24, /* s */
> [...]
> RPMSIGTAG_VERITYSIGNATURES = RPMTAG_VERITYSIGNATURES,
> ```
> 
> ...and the similarly for the other tags.
> 
> > With regard to the different tags, then for the signature length, it depends on the key used and the algorithm. Are you suggesting we calculate the length of the signature from the length of the signature array and divide it by the number of entries?
> 
> I'm not sure what I'm suggesting  Storage size as such is not an issue, it's just that I find the length tag looking superfluous. Isn't it just "strlen() / 2" of the hex data - and once using base64, something you'll get from rpmBase64Decode(). It's not a value you need upfront, is it?
Oh that's an interesting point, I'll have a look at that with the base64 code. If I can derive the size from that, that would be a great win.


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