Closed Bug 1230631 Opened 8 years ago Closed 8 years ago

On update 'User Account Control' popup shown, asks for access to change computer settings

Categories

(Toolkit :: Application Update, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
Tracking Status
firefox45 --- affected

People

(Reporter: aryx, Unassigned)

References

Details

(Keywords: regression)

Firefox Nightly 45.0a1 32 bit on Windows 8.1 64 bit, for KWierso Windows 10

Because I can't reproduce the issue, the following steps might not be minimal. But KWierso also saw the issue:

Profile was set to never remember history (start up in private browsing) and to check for updates but not automatically download them.
1. Open 'About Firefox' dialog.
2. Check for updates.
3. Download update.
4. Click button to restart Firefox.
Actual result:
Window prompt 'User Account Control' asks for permission to change computer settings.

Install directory is "C:\Program Files (x86)\Browser\Firefox\unstable\central\firefox.exe"
Update was from 45.0a1 20151203053521 to 20151204030208
Could you verify the application that is requesting the UAC. It will likely be updater.exe but it might be helper.exe
I've reverted to yesterday's nightly, and waiting for it to automatically attempt to download the update again.
No UAC prompt on this attempt. FWIW, my Nightly uses 16 content processes so each of my tabs gets its own process. Maybe shutting all of those down occasionally takes longer than the updater would like and just gives up and reverts to the one that shows the UAC prompt?
Possibly but only if it took an extremely long time to shut them down. I have seen firefox.exe not exit properly recently on Nightly which caused the UAC prompt on my system.
This is the second or third time in the last month or so that I've noticed a UAC prompt on updates, but I haven't really given it much thought. Is there any logging I should be taking note of (beyond seeing if the UAC prompt is for updater.exe) or turning on before it happens again?
There log files under Program Files\Mozilla Maintenance Service\logs\ or Program Files (x86)\Mozilla Maintenance Service\logs\ should shed some light.

mhowell, can you help out with triaging this?
Flags: needinfo?(mhowell)
The major thing that changed this week related to updates is that we switched to using SHA-2 for code signing. That was bug 1079858. The nightly for today is the first build *following* the one where that patch landed, so it's the first one that tries to update within that brave new world. So because of the timing of this bug, I feel like I have to assume that stuff is the cause.

On that assumption, the only theory I've got that explains these symptoms (and why they don't reproduce easily) is that somehow helper.exe didn't update the maintenance service's cert pinning keys like it should have done in a build with the bug 1079858 patch. That would mean that the maintenance service, which is what usually prevents you getting UAC prompts, failed out and left us having to run updater.exe directly from Firefox to apply the update, which does raise a UAC prompt. rstrong, do you know a way that kind of failure can happen? I don't have a clue.
Flags: needinfo?(mhowell) → needinfo?(robert.strong.bugs)
I don't but it would be a good thing to check if that is what actually happened.
Flags: needinfo?(robert.strong.bugs)
I have six log files in that folder that have been touched today.
maintenanceservice.log: https://pastebin.mozilla.org/8853865
maintenanceservice-1.log: https://pastebin.mozilla.org/8853866
maintenanceservice-2.log: https://pastebin.mozilla.org/8853868
maintenanceservice-3.log: https://pastebin.mozilla.org/8853871
maintenanceservice-4.log: https://pastebin.mozilla.org/8853872
maintenanceservice-install.log: https://pastebin.mozilla.org/8853873


maintenanceservice-4.log looks like it encountered errors.
Flags: needinfo?(robert.strong.bugs)
Flags: needinfo?(mhowell)
Flags: needinfo?(robert.strong.bugs)
I also have maintenanceservice-5.log through maintenanceservice-10.log, but they were last touched yesterday or earlier.
That maintenanceservice-4.log does fit my theory; it's showing a mismatch to the pinned certificate info.

I manually forced a complete update to nightly build 20151203030226 from an older build, and I do see that the old registry keys are still there and I start getting the bug as reported afterwards. I can invoke helper.exe from an admin command prompt and it fixes everything up like it should have, so I know that helper.exe itself is fine. Apparently the updater just isn't invoking it. I have absolutely no idea how that is possible, but it is reproducible, so I'm open to debugging suggestions.
Flags: needinfo?(mhowell) → needinfo?(robert.strong.bugs)
*puts thinking cap on* I think it is a chicken and egg scenario. The helper.exe launched after an update is the new one with the new certificate information. Its cert info doesn't match the info in the registry so the maintenance service doesn't launch it.

One hacky way around this is to update the cert info in the registry from the maintenance service.
Flags: needinfo?(robert.strong.bugs)
Bug 1079858 comment #83 should have caught this and I thought that had been tested previously.
Blocks: 1079858
Keywords: regression
(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #12)
> *puts thinking cap on* I think it is a chicken and egg scenario. The
> helper.exe launched after an update is the new one with the new certificate
> information. Its cert info doesn't match the info in the registry so the
> maintenance service doesn't launch it.
> 
> One hacky way around this is to update the cert info in the registry from
> the maintenance service.

Oh, I thought the mismatch there wouldn't matter, because I thought the service doesn't run the helper, updater.exe does, and I didn't think it would do any of those checks, so that the new cert info wouldn't be consulted at all until the *next* update.
If that's what's happening, then we'll need to break up the patch so that we don't actually switch over the signatures until builds with the new pinning info are out on all the channels.

(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #13)
> Bug 1079858 comment #83 should have caught this and I thought that had been
> tested previously.

I should have been making sure, I'll take responsibility. I honestly thought the service worked differently than comment 12 indicates, so I didn't think of this failure mode.
When running the helper from the service it does verify the certificate since it is running as system. Using the maintenance service as I suggested actually won't work (should have kept my thinking cap on a little longer).
I've backed out the offending patches from bug 1079858 on trunk, aurora and beta. I'm guessing that tonight's Nightly will show the UAC prompt again as the updater gets downgraded. Hopefully that's the only negative consequence of downgrading...

Unsure if we should leave this open until it's finally done happening, or close it because the bad patches are backed out.
Updates are back on again, with fixes from bug 1079858.  There's a two step update to 20151209095500 and then onto the latest build. Please reopen if you see UAC prompts when updating from the 20151209095500 build to latest, or after that.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.