On 5/31/19 12:53 PM, Chris Murphy wrote:
On Fri, May 31, 2019 at 12:40 PM Samuel Sieb <sam...@sieb.net> wrote:
On 5/31/19 6:57 AM, Martin Kolman wrote:
I guess we can't just switch what the signature refers to as there are other
tools
that do this kind of verification on the compressed data, not just delta-RPM,
right ?
So maybe, could we attach a second signature computed on the uncompressed
payload ?
Delta-RPM could then use that to verify the reconstructed package & would be
crazy fast,
as the slow XZ compression will no longer be needed to be performed client-side
to verify
the signature.
It's not deltarpm that needs the signature. It just puts the package
together. It's rpm that checks the signature.
I'm not sure...
847 fprintf(stderr, "could not read signature header\n");
There are several more of these, and also there are other checks happening.
1467 fprintf(stderr, "junk at end of payload\n");
That and a bunch of possible skipped file related messages suggests
drpm is not so simple. At least it seems like it isn't just some
simple difference map between two rpms.
Sorry, I didn't mean that deltarpm didn't check things. My point was
mainly that rpm itself will verify the signature, so deltarpm has to
make it exactly right. Or rpm will need to be modified to use a
different check as discussed elsewhere in this thread.
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
