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

[jessorensen]

@jessorensen commented on this pull request.



> +    }
+
+    rpmlog(RPMLOG_DEBUG, _("key: %s\n"), key);
+    rpmlog(RPMLOG_DEBUG, _("cert: %s\n"), cert);
+
+    compr = headerGetString(h, RPMTAG_PAYLOADCOMPRESSOR);
+    rpmio_flags = rstrscat(NULL, "r.", compr ? compr : "gzip", NULL);
+
+    gzdi = Fdopen(fdDup(Fileno(fd)), rpmio_flags);
+    free(rpmio_flags);
+    if (!gzdi)
+	rpmlog(RPMLOG_DEBUG, _("Fdopen() failed\n"));
+
+    files = rpmfilesNew(NULL, h, RPMTAG_BASENAMES, RPMFI_FLAGS_QUERY);
+    fi = rpmfiNewArchiveReader(gzdi, files,
+			       RPMFI_ITER_READ_ARCHIVE_OMIT_HARDLINKS);

> Right, silly me. I plead ignorance and amnesia on what little I know about the Merkle tree stuff... but now that you remind me, it makes me think there's quite a bit of mutual interest here.
> 
> There are multiple places in rpm that would benefit from gradually verifiable content, starting with the file digests themselves. If rpm stored the Merkle hashes for the files at build time, I suppose you could then just sign those? And when available, rpm could use those instead of the traditional digests for its verify operation for quicker identification of modified content.

Yes that should be feasible, the traditional digest can be derived from the Merkle tree. If we added support for rpm to use a Merkle tree internally that would be a mutual benefit, since it allows one to verify a data block in linear time without having to checksum the entire file. Note that the Merkle tree consumes roughly 1/127 of the file size, so there is a cost with it, but it's not crazy. It would be a fair amount of work on top of this, but maybe something to put on the long term goal list?

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