c66b78165a
If a change modifies a binary file, a user may need to download that file and use a local application in order to review what has been modified. Image files or common office file formats are two examples where this is very useful, as text level diff is just not available, or practical. Due to "features" in Microsoft Internet Explorer 6.0 that permit a user to open a downloaded file in the same security zone as the website that is serving the file, we wrap the download in a ZIP archive. This forces IE to open the ZIP archive rather than the file itself, tricking it into treating the content as a virtual folder and not the original file type. When the file is eventually opened from that virtual folder, it gets opened with the local security zone, rather than the server's, and the user's cookies and session are protected. To reduce risks associated with an attacker trying to use the ZIP archive as a container (e.g. for a Java applet), the file name within the ZIP archive is randomly generated, including request-specific information. This makes it very difficult to predict in advance what file name will appear in the archive, so an attacker cannot reference a Java class file through an applet tag (for example). As the ZIP archive contains exactly one file stream, it is also less likely to match with other common uses of the ZIP format, like a *.odf file, as only one data stream can appear. In the future we would like to support site-specific blessed content rules. For example, a Gerrit server on an internal corporate intranet might want to permit *.doc to be sent as an inline content (rather than wrapped in a ZIP) to make the review of Microsoft Word formatted files easier. This change does not permit that, but leaves the guessContentType() and the isSafeInline() methods available for future enhancement. Bug: GERRIT-132 Signed-off-by: Shawn O. Pearce <sop@google.com>