User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041026 Firefox/1.0RC1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041026 Firefox/1.0RC1 A very powerful feature would be to add some functionality that makes it possible for a user to "add" .md5/.md5sum and .asc files to files in the download manager (fully or partially downloaded - it shouldn't matter - just as long as it's in the download manager). When the file that needs to be verified is 100% downloaded, the download manager should verify the file using the PGP fingerprint and/or the md5 hash. How could this be done GUI wise? There are two parts to it. First the asc or md5 files need to be associated with the file that needs to be checked – second the user should be able to see if a file in the download manager has a md5/asc file associated with it and the outcome of the check needs to be displayed as well: Usually if I gave away a file named myprogram.tar.gz I would the provided two other files as well: myprogram.tar.gz.asc and myprogram.tar.gz.md5. So by just looking at the filename the user can work out that these relate to a file called myprogram.tar.gz. This automated functionality could also be build into the Firefox download manager. There are two ways of doing this. The one-click version would be just to download the md5/asc file like any other file. The download manager should then compare the filenames with the ones already in the download manager and tie related ones together. It should not matter in which order the user downloaded the files. If the user first downloaded the md5/asc files and then later the full program this feature should work in the same way as if the program was downloaded first and the md5/asc files later. Where should the md5/asc files be downloaded to? You could argue that the user only is interested in the program it self – not the md5/asc files. So should they automatically be downloaded to some temp folder? This is a matter of attitude. Personally I would prefer them to be downloaded to some temp folder. But others might want to store them locally together with the downloaded program for later use or distribution. So this feature should be configurable from some advanced options setting (or at least via a plug-in or ini-file configuration). In the end the user can always right-click and select “Save link as...” if he wants the md5/asc file in a specific location. Should the different files show up independently in the download manager? The perfect solution would be to show them as normal files for as long as they are still being downloaded. The second the md5/asc file are fully downloaded and there is a “master” file (e.g. myprogram.tar.gz) present in the download manager the md5/asc file should be removed from the list (this should be configurable as well – some users might want it to remain in the download list) and be attached as a little icon on the myprogram.tar.gz download. This icon should display a “?” for as long as the “master” file was not completely downloaded, as a “ok-tick-mark” when the validation went ok and as a “!” if the validation went wrong (in this case a dialog box with a warning might be appropriate as well as the option to either re-download all files, delete or ignore). I’ll attach a screenshot later with an example of the above icons in the download manager. If the user chooses to disable the md5/asc check all together and downloads an md5/asc file, this file should be treated just as any other download. But then the user should be able (from within the download manager) to drag’n’drop the md5/asc or the “master” file onto one another to tie them together just as described above. Another solution is to add a menu item to the right-click menu when the user right-clicks a file for download. The menu item could be named “Integrity check...”. When the user clicks this menu item a dialog window appears with a list of files from the download manager. Here the user can then choose which file to either verify or use for verification (i.e. it shouldn’t matter if the user does this with an md5/asc file and then chooses the “master” file or with the “master” file and then chooses the md5/asc file). Reproducible: Always Steps to Reproduce:

Ok I have no idea what went wrong with the character encoding... sorry about that.

see bug 101743

Added an attachment showing how it could look if both a asc and a md5 file have been tied to a download. In this case the download is finished and is verified to be ok.

Added an attachment showing how it could look like if both a asc and md5 file have been tied to an existing download that is not yet finished. I don't like the question mark icons I've used, but they illustrate the point (something closer to the ok-ticks in the previous attachment would be nicer)

(In reply to comment #2) > see bug 101743 Ups didn't see that. Stange... I tired searching for both md5, asc and pgp before submitting the bug, but nothing came up... Hmmm weird. Chould they be tied together?

(In reply to comment #5) > (In reply to comment #2) > > see bug 101743 ... Ahhh :) I was searching only for bugs in Firefox. I see that bug 101743 is in the product "Browser" ;)

I see some problems with automating the comparison of a downloaded file with a downloaded MD5 hash or PGP signature. The most important is that a hacked server would contain both a bogus file for downloading and also a bogus hash or signature. And protecting against bogus downloads is one of the important purposes of PGP-signing a file. For security, I prefer obtaining the originator's hash or signature manually. The MD5 hash algorithm is relative small. I have a tool on my PC for computing the hash on a file; it's about 40 kB. Thus, it could be embedded in Firefox (or for bug #101743 in the Mozilla suite). I don't know if the added burden of code to search for an .md5 file (which more than likely won't exist) when downloading can be justified. The PGP signature is even more a problem. Even the old PGP 2.6.2 is over 238 kB, and it can handle only RSA signatures. To handle DSS/DH signatures too might add 500 kB to Firefox plus the code (again) to search for the .asc file (which -- even more likely than for an .md5 file -- won't exist). In any case, a PGP signature would only verify that the downloaded file was not corrupted. To verify its authenticity, the user would have to have PGP itself installed and possess copy of the signer's public key, which the user has signed after establishing the signer's true identity. In the end, I do not see great utility in automating either comparison. I do see some utility in an option for automatically computing the MD5 hash, leaving the acquisition of the originator's hash and the comparison as something I do manually. Already having PGP 2.6.2, 5.0, and 8.0.3 installed, I see no utility in having the Download Manager for Firefox or Mozilla doing any PGP operations. On the other hand, I would see a great utility in a plugin compatible with PGP 8.x for use with Thunderbird and Mozillas MailNews for signing, encrypting, decrypting, and verifying messages. But that would be a new bug report, an extension, or some third-party product.

This is an excellent suggestion, it would allow the average person who knows nothing about md5, pgp, etc. to verify the integrity of a download. Bug 101743 only goes part way - the end user would still need to know conceptually what an md5 checksum was, and where to find the value to compare it to. Ideally, an independent centralized service would store md5 checksums, similar to the way a public keyserver works. When Mozilla downloads a file, it could query this default md5 server with the filename and automatically display some sort of "verified", "unverified", or "damaged" message or icon in the download manager (depending on whether a valid checksum was or wasn't found, or if a non-matching md5 was found). Of course this sort of scheme depends on an as yet non-existent central md5 keyserver hosted someplace, and probably mirrored at several locations. It would probably be enough to only implement one variety, say md5. Anyone who wanted a different method like pgp could still do things the old way, but that type of person likely has the tools and skills to do so already.

duping to bug 101743, now that it's in the 'Core' product. The interface-proposal in this bug is the best example I've seen so far. *** This bug has been marked as a duplicate of 101743 ***

one way to automate this is with Metalink, which associates hashes and signatures with files (and mirrors too). 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.