Closed Bug 1684005 Opened 5 years ago Closed 5 years ago

Offline 84.0.1 download version is 84.0.0

Categories

(Firefox :: Installer, defect)

Firefox 84
defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: nick, Unassigned)

Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:84.0) Gecko/20100101 Firefox/84.0

Steps to reproduce:

Downloading 84.0.1 Offline .exe

Actual results:

The "Firefox Setup 84.0.1.exe" file includes the 84.0.0 version.

Expected results:

Getting the version which is in the file name.

Hi Nick,

Are you downloading any of these? https://ftp.mozilla.org/pub/firefox/releases/84.0.1/win64/en-US/ I've downloaded exe build, and the correct version is downloaded. Please let me know if there's any additional step in order for me to replicate on my end.

Best,
Clara

Flags: needinfo?(nick)

Now i get the correct version from both (Website and FTP).
But i also noticed that the file hash is different from the Website .exe and FTP .exe, but the FireFox version after the installation is the same.

Flags: needinfo?(nick)

So can you still reproduce or this is no longer reproducible on your end?
Best,
Clara

Flags: needinfo?(nick)

The problem in my first posted is now gone (fixed).
The only strange thing i have noticed today is that the file hash is different from the 2 links below. Not sure if that's normal or not, but i thought it didn't hurt to post this too.
https://download.mozilla.org/?product=firefox-latest-ssl&os=win64&lang=en-US
https://ftp.mozilla.org/pub/firefox/releases/84.0.1/win64/en-US/

Flags: needinfo?(nick)

Setting a component for this in order to get the dev team involved.
(If the team feels it's an incorrect one please feel free to change it to a more appropriate one.)

Best,
Clara

Component: Untriaged → Installer
Status: UNCONFIRMED → RESOLVED
Closed: 5 years ago
OS: Unspecified → All
Hardware: Unspecified → All
Resolution: --- → INVALID
Resolution: INVALID → WORKSFORME

(In reply to nick from comment #4)

The problem in my first posted is now gone (fixed).
The only strange thing i have noticed today is that the file hash is different from the 2 links below. Not sure if that's normal or not, but i thought it didn't hurt to post this too.
https://download.mozilla.org/?product=firefox-latest-ssl&os=win64&lang=en-US
https://ftp.mozilla.org/pub/firefox/releases/84.0.1/win64/en-US/

Hi Nick -- this is expected, if a little surprising. I just saw a comprehensive discussion of this go by but for the life of me I can't find it! So let me explain what's happening here very briefly.

The archives at ftp.mozilla.org/archive.mozilla.org are the official, blessed archives. The md5/sha fingerprints there should always line up.

The archives served from download.mozilla.org are "attributed": some general information about where the archive was downloaded from is baked into the archive. That alters the md5/sha. For technical reasons, it does not alter the Windows Authenticode signature.

Since you're on Bugzilla, let me link you to the set of things that might be contained in the attribution data: https://searchfox.org/mozilla-central/rev/85f20360d898501f0fac12dd35fe8b7475e01848/browser/components/attribution/AttributionCode.jsm#45-53. The idea is that if you landed on download.mozilla.org from a specific marketing campaign, we can funnel that information through to the browser and do additional configuration on your first run. I don't have a great link to explain the technical mechanism on Windows, but here's a ticket from which you can dig further: https://bugzilla.mozilla.org/show_bug.cgi?id=fx-stub-attribution.

Hope that explains a worrying discrepancy to your satisfaction.

You need to log in before you can comment on or make changes to this bug.