Re: RPM: signing uncompressed data instead of signed data?
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. http://james.fedorapeople.org/python/delta-rpm-dir.py 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 -- Michel Alexandre Salim Fedora Project Contributor: http://fedoraproject.org/ Email: sali...@fedoraproject.org | GPG key ID: 78884778 Jabber: hir...@jabber.ccc.de | IRC: hir...@irc.freenode.net () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RPM: signing uncompressed data instead of signed data?
On Thu, Nov 11, 2010 at 10:41:13 +, Andre Robatino robat...@fedoraproject.org wrote: The question was raised why RPMs sign their compressed data, rather than uncompressed. (One advantage would be to avoid deltarpm rebuild failures due to changes in compression such as the recent one in xz.) The answer had to do with the fact that higher-level tools (createrepo and yum) depend on the current behavior, but that doesn't address whether it's just an early design mistake that we're locked into now, or if there's actually some overall advantage to doing things this way (that outweighs the obvious disadvantage of inflexibility in how the data is compressed). Can anyone shed some light on this? Uncompressing hostile data is generally not a good thing to be doing. From that aspect it makes more sense to sign the compressed payload. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
RPM: signing uncompressed data instead of signed data?
Bruno Wolff III wrote: Uncompressing hostile data is generally not a good thing to be doing. From that aspect it makes more sense to sign the compressed payload. I was thinking that since the signature check usually passes, the data could be uncompressed into a cache, checked there, then copied into place (assuming the check passes). If the data is capable of escaping from that sandbox before being checked, that's a serious security bug in the compression software that should be fixed in any case. (Sorry for not responding in-thread. Gmane isn't updating its list of existing threads.) signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RPM: signing uncompressed data instead of signed data?
On Thu, 2010-11-11 at 10:41 +, Andre Robatino wrote: I came across the following old post, which I'm not responding to in-thread due to its age. https://www.redhat.com/archives/fedora-devel-list/2009-September/msg00517.html The question was raised why RPMs sign their compressed data, rather than uncompressed. (One advantage would be to avoid deltarpm rebuild failures due to changes in compression such as the recent one in xz.) That's not true, there are four checks for delta rpms: 1. yum-presto runs checksums on the installed rpm, and the downloaded deltarpm. If these pass it then creates a new .rpm from those two sources. 2. Yum then checks that any rpm it has on disk matches the checksum it has from the repodata. 3. Yum then asks rpm to check the gpg signature of the new rpm. 4. Yum then looks at the SHA1HEADER for the rpm (which, again, is over the compressed contents). ...now it's possible that #3 will change within the next year or so, but it is much more likely to end up simpler than more complicated (Eg. detached signature of the entire file). 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. http://james.fedorapeople.org/python/delta-rpm-dir.py -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/whatsnew/3.2.29 http://yum.baseurl.org/wiki/YumBenchmarks http://yum.baseurl.org/wiki/YumHistory -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RPM: signing uncompressed data instead of signed data?
On Thu, Nov 11, 2010 at 09:29:54 -0500, Andre Robatino robat...@fedoraproject.org wrote: Bruno Wolff III wrote: Uncompressing hostile data is generally not a good thing to be doing. From that aspect it makes more sense to sign the compressed payload. I was thinking that since the signature check usually passes, the data could be uncompressed into a cache, checked there, then copied into place (assuming the check passes). If the data is capable of escaping from that sandbox before being checked, that's a serious security bug in the compression software that should be fixed in any case. The issue is the uncompression itself rather than the resulting uncompressed data being used. It is easy to do a DOS by compressing a very large file of constant data and having the victum fill up their disk. Also compression / decompression seems to be an area where proper paranoia isn't practiced and malformed data can cause problems. There have been several cases of libraries handling compressed image formats allowing arbitrary execution of code when operating on trojan images. I suspect that historically the people writing this kind of code were more interested in speed than security. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
RPM: signing uncompressed data instead of signed data?
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. http://james.fedorapeople.org/python/delta-rpm-dir.py 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.) signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RPM: signing uncompressed data instead of signed data?
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.
--
Michael Schroeder m...@suse.de
SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RPM: signing uncompressed data instead of signed data?
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.) -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RPM: signing uncompressed data instead of signed data?
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. http://james.fedorapeople.org/python/delta-rpm-dir.py 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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
