@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:
Rpm-maint mailing list

Reply via email to