Quite often files for download are accompanied by an md5 checksum to allow the user to verify that the file's contents have been transmitted correctly. It would potentially be useful for mozilla to compute the md5 checksum information and display it as part of the "Saving file" progress window.

I believe you cannot compute the checksum *before* downloading the complete file. It could be displayed *after* the file is downloaded, though.

Yes, I wasn't precise with my wording there. I was intending for the checksum to be displayed only when all the data had been downloaded (although it might be computed during the download). Geeks might like a continuously display of the checksum-so-far, but the ETA stuff is probably enough for everyone else!

If geeks want a continous checksum, they would probably be willing to hack the source to do it. I don't see that as something that we'd want in Mozilla. Plus it would add some overhead and won't make much sense. However, displaying the final checksum is a valid request and something that I'd like to see eventually. Save me the trouble from computing it myself. If this gets implemented though, i think it should be a pref. I doubt my mom would know what that "30 something letter and number garbledygook string" was... she might think it a bug!

spam: over to File Handling. i have not changed the assigned developer [or the other fields for that matter], so if anyone realizes that a bug should have a more appropriate owner, go ahead and change it. :)

-->law

Maybe something for the download manager?

*** Bug 140165 has been marked as a duplicate of this bug. ***

*** Bug 130120 has been marked as a duplicate of this bug. ***

*** Bug 189765 has been marked as a duplicate of this bug. ***

it shouldn't really be a pref, it should just be a column in the download manager which is hidden by default. the value should only be computed if the column is visible.

Really, MD5 is one-way hash function (correct me if wrong) and it only makes sense to compute it AFTER download of the very file. It doesn't make sense to compute it continuesly during download. But I'd like very much if MD5 was computed by Download Manager after download.

I'm not expert on MD5 algorythm; maybe the sum is computed continuesly in the order of blocks as they go, from begin of file to the end. If so, then it is able the Manager to compute the sum DURING download. Of course it dosen't change anything on fact, that the final result can be displayed only after download is finished. But I think better way is to compute the sum AFTER the whole file is downloaded. If nothing else, it's easier to code it I think :o) And computing the sum costs many processor's power and if user cancelled the download, the whole computing was useless.. On the result of MD5sum and on final/expected size of file can be later based an algorythm of Resume Download questioning etc..

*** Bug 182270 has been marked as a duplicate of this bug. ***

It's a great idea, but perhaps on the same page where one can elect to calculate this MD5 sum, one could also choose which hash to use, since there are many: MD5, SHA1, CRC32, etc.

retargeting

MD5 sums can be calculated as a stream, and this would lighten the load on the download as opposed to performing the calculation at the end of the download.

*** Bug 238355 has been marked as a duplicate of this bug. ***

(In reply to comment #11) > Really, MD5 is one-way hash function (correct me if wrong) and it only makes > sense to compute it AFTER download of the very file. It doesn't make sense to > compute it continuesly during download. But I'd like very much if MD5 was > computed by Download Manager after download. See the interface in <http://lxr.mozilla.org/seamonkey/source/security/nss/lib/freebl/blapi.h> : you can call MD5_Update() repeatibly, block by block. It gets accumulated in the context. Actually, this is the only way to do it, because an MD5 over a 300MB download file would take very, very long. Not to mention the fact that we might unzip / uncompress / unbinhex automatically (there are other bugs about that), so that the MD5 sum of the result would be something different. But it doesn't make any sense to display it continuously. It has no meaning whatsoever, until everything is downloaded. You'll find more sensible data in the white noise on your TV-screen.

Actually, you wouldn't need to see the stream, just have it be calculating as the download is progressing (seeing as though the average download is around 300Kb/s). And yes, this is much better than going through after it is done because even if it is zipped/rarred/whatever, the odds are it could be anything and if the immediate file is the right file, then the expensive cpu afterwards of the file would be pretty wasteful.

over to default owner since Bill Law isn't actively hacking mozilla anymore... if this were to happen for firefox perhaps it could be visible to the user if they right click on an item in the download manager and select "properties."

Re comment #18: The checksum should be computed on whatever is finally stored from the download. That is, if a file is compressed on its server but the downloaded file is uncompressed by the Download Manager, the checksum should be computed on the uncompressed version. Compression is often a function of the server. Whoever uploaded the file to the server and also uploaded the original checksum likely did not compute that original checksum on the compressed file. Indeed, he or she might not even be aware that the server is compressing files. This means that the checksum computed by Mozilla will likely have to be computed after the download and not during.

I just created a new bug (bug 267013) over in the Firefox product. Thought I've searched through everything and that there wasn't a related bug - But there you go: It was in the Browser product instead ;) Anyway. As I see it this bug only talks about checksums, but I have also proposed a feature on how to check for PGP so we can ensures that the file came from a certain person. Hope people find it helpful :) Btw... I've attached as well a couple screenshots showing how this might be done GUI wise.

*** Bug 267013 has been marked as a duplicate of this bug. ***

Note that MD5 might not be the only hash-function that can be used here ; see bug 292368 for a scriptable interface to several functions. Maybe we should calculate different checksums together ?

It would IMO be entirely useless to compute the MD5sum and display it to the user. If the server sent a Content-MD5 header, it would be useful to compute the MD5sum, and warn the user in the rare circumstance that they didn't match. But I don't see the value in ever displaying the raw hex digits. Gerv

I don't agree at all : some sites display the MD5 checkum (or others like a SHA-1 or RSA sig) next to the download link, so that the user can check it. For example : http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html And it's also used in download pages of my company, for firmware downloads (currently only internal, but they have been used in the past for public downloads). I agree that it's geeky, common user don't inderstand these hexadecimals strings. That's why bug 292481 (checksum in href) and bug 292481 (Content-MD5 header) are useful, the browser can check automatically. But a display of the checksum in the download window (not in the progress window) is still useful, althouhg it would probably be hidden behind an info-button or something similar.

As a slight addition to this, I think the browser should go one stage further and validate the hash against one the user enters. Specifically, the file download dialog box and download manager (in case the user has the file type set to automatically download) should have the ability for the user to enter the MD5 hash (or whatever hash they have selected) that is expected. The browser can then validate this on completion of the download and in the event of a mismatch advise the user of this fact, giving them the option to delete the downloaded file if they wish (perhaps changing the background colour for that file in the download manager to red).

For Windows, see digestIT at <http://digestit.kennethballard.com/>. This allows the user to compute the MD5 or SHA-1 hash of a file. It also provides for the user to input a hash and compare it with the hash of the file. Given that the capability exists for files in general, is it really worthwhile to expend effort to implement it in a browser only for downloaded files? While I originally thought this was a nice enhancement, I no longer support it because I have installed digestIT, which is more general than a browser implementation.

Given the problems with Thunderbird 13.0 MD5 and SHA1 hashes described in bug #762152, I question whether this is a worthwhile enhancement. After all, what would have happened with attempts to download that version of Thunderbird if this RFE had been implemented?

Metalink is one way to automate associating hashes (and signatures, mirrors and other info too) with files. it does this either with an XML description file (RFC 5854) or within HTTP headers (RFC 6249). many download programs support this, and it can be used with DownThemAll, a great firefox extension. DTA will also allow you to manually enter a hash for a file.