what is "KEY" file for on ftp.mozilla.org download?
When you look at the KEY (all caps) like https://ftp.mozilla.org/pub/firefox/releases/52.5.3esr/ Other than showing you a signing key ID(s) & an email addy to search for public keys, what is the purpose of the KEY on the download pages?
Entering: $ gpg KEY, where the KEY file is in the current location shown in the terminal, gives info like:
D98F0353 2015-07-17 Mozilla Software Releases <release@mozilla.com> sub 4096R/5E9905DB 2015-07-17 [expires: 2017-07-16]
Only thing I can figure is the "KEY" file is to tell users which public key ID or email addy to search for, if you don't already have the devs' correct public signing key stored on your keyring?
That still doesn't help to verify the authenticity of any downloads, unless there are *.asc signature files for each specific file. Like here: https://ftp.mozilla.org/pub/firefox/releases/52.5.3esr/update/linux-x86_64/en-US/
There's a firefox update file that was signed by the devs, using one or more of their PGP signature keys. And a 2nd "signature file" - with .asc extension, that's used with GPG to verify the downloaded file's **authenticity.** NOTE: This has NOTHING to do with checksums!
Checksums don't verify that the file you're downloading wasn't tampered with after it was loaded on the server. Only that there were no read / write errors during download process.
The two files below were together. You need both to verify authenticity using gpg. firefox-52.5.2esr-52.5.3esr.partial.mar firefox-52.5.2esr-52.5.3esr.partial.mar.asc
If I've already downloaded the mozilla devs' public keys & stored them on a keyring app, then I can verify the downloaded file. If you change dir to where the update file & the signature file (.asc) are stored, then you enter:
$ gpg --verify firefox-52.5.2esr-52.5.3esr.partial.mar.asc firefox-52.5.2esr-52.5.3esr.partial.mar
If the signed downloaded file's signature matches the .asc file & also the correct, stored public key for the authors, it will say:
gpg: Signature made Tue 03 Oct 2017 05:22:45 PM CDT using RSA key ID 24C6F355 gpg: Good signature from "Mozilla Software Releases <release@mozilla.com>"
The FULL installer packages like firefox-52.5.3esr.linux-x86_64.sdk.tar.bz2 don't seem to have signature files available (with .asc). There's no way for users to manually verify full installer packages. Maybe they somehow do "self verification." It seems like firefox would have to contact a server - at some point to compare signature of the package being installed against a known good signature key.
由 JoeB 於 修改
所有回覆 (6)
The usage of the KEY file is to verify the SHA512SUMS files that you find at the root level that stores the checksums of all available Firefox installers..
gpg2 -v --import < KEY gpg2 -v --verify SHA512SUMS.asc
The SHA512SUMS file stores the checksums that you can use to verify the file(s) you download. There is no .asc file for each individual file.
SHA256SUMS SHA256SUMS.asc SHA512SUMS SHA512SUMS.asc
Thanks cor-el. Has anyone seen an explanation - if or how Mozilla's full installer packages do self authentication, using PGP signature keys (not checksums)?
Full installer packages must do this "automatically" somehow. I doubt Mozilla would provide *.asc signature files for partial update files, but not verify the authenticity of full packages.
Verifying a file's authenticity using signature files (not checksums) shows that the file you downloaded is identical to the developer's finished version, and that the file on a server wasn't tampered with or replaced by malicious persons (this happens more to large & small developers / servers than most would think).
About GPG: https://www.gnupg.org/ https://www.gpg4win.org/about.html
The Mozilla updates - .partial.mar files usually DO have *.asc files available, to use with GPG to manually verify the authenticity of *.partial.mar files.
Again, for those unfamiliar with using GPG or signature files (that have extensions .asc or .sig), the checksums can ONLY show that there were no data errors during the download process (as in, errors writing a download to a hard drive, etc.).
Checksums do not / can not determine if a file on a server was tampered with (maliciously hacked), AFTER it was uploaded to the server.
"I doubt Mozilla would provide *.asc signature files for partial update files, but not verify the authenticity of full packages."
Hmmm. If I understand these articles, it looks like Mozilla "full packages" don't do any self-verification, AND there aren't any *.asc signature files to manually verify the full packages' authenticity.
- Mozilla is working on a new security project for Firefox, called Binary Transparency, currently to allow all Firefox users to verify the binary files of the web browser to ensure that the files are safe and have not been tampered with.''
- Binary versions of Firefox don't come with any assurance that they correspond to the Firefox source code of that particular version of the browser.
https://wiki.mozilla.org/Security/Binary_Transparency#Steps_to_Verify
If this is correct, I would never have thought Firefox / Thunderbird full package downloads or automatic updates have no verification that the files are identical to Mozilla's source code for those files (haven't been tampered with).
For 64-bit Firefox on 64-bit Linux the file you download for example is firefox-52.5.3esr.tar.bz2 in https://ftp.mozilla.org/pub/firefox/releases/52.5.3esr/linux-x86_64/en-US/ and not the firefox-52.5.3esr.linux-x86_64.sdk.tar.bz2 that is listed in https://ftp.mozilla.org/pub/firefox/releases/52.5.3esr/
Thanks James, for the info. But I know you don't think this topic is about which Fx version I need?? :D
1st, it was about the purpose of the KEY file. cor-el covered that.
Those were just examples of files and whether PGP signature files are / aren't present on various Mozilla or 3rd party download pages, if users want to verify that the files they download haven't been tampered with.
On Windows .exe files can be signed (it's an OS feature), but on Linux this isn't possible AFAIK. MAR files are handled internally by the Firefox updater and thus can be signed, but with compressed tar.bz2 archive files this isn't possible and that leaves only a checksum to verify the file. You can verify the checksum files, so you know they are valid.