James Antill wrote:
IMO, as has been said before, if you have a delta method that doesn't produce the exact same bits at the end ... you've probably failed. It might seem like a good idea, but even if you go to the extreme lengths needed to make it just for yum ... things like reposync won't be able to use it, Eg.
I realize there's a lot of stuff sitting on top of RPM that depends on how it works currently, but in terms of correctness, it still seems to me to make more sense to sign the uncompressed data, since that's what actually gets used, and it would avoid issues like https://fedorahosted.org/rel-eng/ticket/4224 which will have to be dealt with periodically as long as compression continues to improve. So let me rephrase the question: in an alternate universe where RPM was originally designed to sign the uncompressed data, and the higher-level tools were subsequently designed to work with that, is there any fundamental reason why things would be worse (or better) than they are now?
(Again, sorry for not replying in-thread, but Gmane isn't updating.)
On Thu, Nov 11, 2010 at 10:17:57AM -0500, Andre Robatino wrote:
I realize there's a lot of stuff sitting on top of RPM that depends on how it works currently, but in terms of correctness, it still seems to me to make more sense to sign the uncompressed data, since that's what actually gets used, and it would avoid issues like https://fedorahosted.org/rel-eng/ticket/4224 which will have to be dealt with periodically as long as compression continues to improve. So let me rephrase the question: in an alternate universe where RPM was originally designed to sign the uncompressed data, and the higher-level tools were subsequently designed to work with that, is there any fundamental reason why things would be worse (or better) than they are now?
Securitywise ist would be a bit worse, because the decompression libraries may contain exploitable bugs, so checking the signature of a rpm might be already a dangerous operation.
(But most repositories nowadays already contain checksums over the complete rpm, and most people trust repositories, not individual rpms.)
Cheers, Michael.
On 11/11/2010 07:17 AM, Andre Robatino wrote:
in an alternate universe where RPM was originally designed to sign the uncompressed data, and the higher-level tools were subsequently designed to work with that, is there any fundamental reason why things would be worse (or better) than they are now?
The bytes that are signed would be "farther away" from the contents of the .rpm file. The compression would occur in between the signing and packing the file, so the signing would be less "end-to-end" with respect to packing the contents into the file. This changes the data integrity implications of signature that does not match. Some uses want more protection against "mere transmission errors" of the file, other uses want more independence of the various steps in a larger process (ability to change compression without changing signature, for example.)
--
On Thu, 2010-11-11 at 10:17 -0500, Andre Robatino wrote:
James Antill wrote:
IMO, as has been said before, if you have a delta method that doesn't produce the exact same bits at the end ... you've probably failed. It might seem like a good idea, but even if you go to the extreme lengths needed to make it just for yum ... things like reposync won't be able to use it, Eg.
I realize there's a lot of stuff sitting on top of RPM that depends on how it works currently
Maybe I wasn't clear ... the above code doesn't "depend on rpm" it depends on the bits being identical, as it's used to speed up mirroring Fedora (so the bits have to be identical for the mirror users).
, but in terms of correctness, it still seems to me to make more sense to sign the uncompressed data, since that's what actually gets used
"used" is a loaded word here, as others have said from the point of view of different parts of yum/rpm it's the downloaded bits that are "used" and the uncompressed bits that are output.
, and it would avoid issues like https://fedorahosted.org/rel-eng/ticket/4224 which will have to be dealt with periodically as long as compression continues to improve. So let me rephrase the question: in an alternate universe where RPM was originally designed to sign the uncompressed data, and the higher-level tools were subsequently designed to work with that, is there any fundamental reason why things would be worse (or better) than they are now?
So assuming we could magically change everything, what would we need to do stop any differences in compression from causing problems? In theory we could publish everything as uncompressed ... and then use http content-encoding to add xz/etc. compression back. But that'd break everything that's non-http ... and any http clients that don't do content-encoding (and AFAIK no client/server currently supports xz in content-encoding).
The other option is for someone to add compat. code into xz, so we can say things like "compress how you would have with version x.y.z".
On Thu, 11 Nov 2010 10:17:57 -0500, Andre Robatino wrote:
James Antill wrote:
IMO, as has been said before, if you have a delta method that doesn't produce the exact same bits at the end ... you've probably failed. It might seem like a good idea, but even if you go to the extreme lengths needed to make it just for yum ... things like reposync won't be able to use it, Eg.
I realize there's a lot of stuff sitting on top of RPM that depends on how it works currently, but in terms of correctness, it still seems to me to make more sense to sign the uncompressed data, since that's what actually gets used, and it would avoid issues like https://fedorahosted.org/rel-eng/ticket/4224 which will have to be dealt with periodically as long as compression continues to improve.
This is what 0install uses: http://0install.net/faq.html
-
Andre Robatino -
James Antill -
John Reiser -
Michael Schroeder -
Michel Alexandre Salim