-
Notifications
You must be signed in to change notification settings - Fork 313
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add length method to InputStream #277
Add length method to InputStream #277
Conversation
To make this thing act more realistically like an IO, it needs a length method.
The omission of the If you are creating the ZIP files yourself and know that the entry size is reliable, using the entry size in this way might be acceptable. However, I don't support this as a general addition to RubyZip because it can't be used reliably on ZIP files from other sources. |
Are there any risks that outweigh the benefits? From my perspective, a zip with inaccurately reported entry sizes is just invalid, and with invalid data you can expect invalid behavior. Unless there are security implications, it seems useful to me to be able to treat the stream like an IO, even if it requires some implicit trust in the archive being truthful about the decompressed size of its entries |
RubyZip is sometimes used in web applications, and the ZIP files being decompressed may come from user uploads. Zip bombs are well known and commonly used as a denial of service attack. The ZIP bomb works by exploiting the possible inconsistency between the size reported in the entry and the actual size the data will decompress to. A very tiny ZIP file may expand to many gigabytes. If the consumer of the decompressed data is holding it in RAM, it may consume all available RAM and swap. If the consumer of the decompressed data is storing it on disk, it may consume all space on the disk. Web developers can't ignore these kinds of ZIP files as simply "invalid" or else they will be vulnerable to these attacks. |
Playing Devil's Advocate a bit here, but is it the responsibility of RubyZip to save badly designed Web applications from themselves? Or, to put it another way: is it reasonable to omit a useful, sensible and (maybe) expected feature just because people may abuse it? I suppose a third way of looking at it might also be: There's no length attribute now, so how would a Web application make decisions on how to unpack things as they stand? At least if there was an advertised length then one could stop reading when one hit that length. |
The expected size of the decompressed data is already available from This pull request is about adding a |
I don't agree a reasons for it. If you need such method you can wrap it in your code. |
To make this thing act more realistically like an IO, it needs a length method.
One useful example is being able to iterate through a zip of images and upload them to an HTTP server using
UploadIO
. In order to multi-part such a POST body, the length of the IO must be known.Fixes #276