1127481 - (CVE-2015-2720) Run updater.exe from the application directory when not using the service for an update

Status: VERIFIED FIXED

(Toolkit :: Application Update, defect)

Description

[Robert Strong (they/them - no direct email)]

+++ This bug was initially created as a clone of Bug #945192 +++

From bug 945192 comment #250
"The patch as it stands I believe covers loading all dll's placed in the directory alongside the updater.exe except for the following cases using Firefox x86:
Windows Vista x86 and x64 - apphelp.dll
Windows XP x64 - wow64log.dll

Firefox x64 is fixed.

To fix this for the two cases above the directory where the updater.exe would need to be secured which we can't guarantee with our current policy of allowing users to install into a directory of their own choosing and the fact that the user can change the permissions of the directory.

To address these two cases I am planning on running the updater from the application directory when not using the service. This would require not staging updates when not using the service which I don't see as a major issue since the vast majority of users use the maintenance service with less than 5% not using it according to telemetry. The visible affect of not using staging is it taking longer to apply an update during startup.

Making app update use the updater.exe from the application directory will take time to implement and I am unsure of the amount of time it will take. Since the affected systems after the current patch lands are a very small subset of the Windows install base we need to decide whether or not we should hold off on landing the current patch until this additional work is completed."

Comment 1

[Robert Strong (they/them - no direct email)]

Remaining dll loads that will be fixed by this bug.

Win XP x86 - Firefox x86
updates\0\LPK.DLL - loads before preloading - elevated since there is no UAC
updates\0\USP10.dll - loads before preloading - elevated since there is no UAC
updates\0\updater.exe.Local\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.6028_x-ww_61e65202\comctl32.dll - elevated since there is no UAC

Win XP x64 - Firefox x86
updates\0\wow64log.dll - loads before preloading - elevated since there is no UAC
updates\0\updater.exe.Local\WOW64_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.3790.3959_x-ww_5FA17F4E\comctl32.dll - elevated since there is no UAC

Win Vista x86 - Firefox x86
updates\0\apphelp.dll - loads before preloading - unelevated and elevated
updates\0\updater.exe.Local\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.6002.18005_none_5cb72f96088b0de0\comctl32.dll - unelevated and elevated

Win Vista x64 - Firefox x86
updates\0\apphelp.dll - loads before preloading - unelevated and elevated
updates\0\updater.exe.Local\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.6002.18005_none_5cb72f96088b0de0\comctl32.dll - unelevated and elevated

Win 7 x86 - Firefox x86
updates\0\updater.exe.Local\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.17514_none_41e6975e2bd6f2b2\comctl32.dll - only unelevated

Win 7 x64 - Firefox x86
updates\0\updater.exe.Local\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.17514_none_41e6975e2bd6f2b2\comctl32.dll - only unelevated

Win 7 x64 - Firefox x64
updates\0\updater.exe.Local\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.17514_none_fa396087175ac9ac\comctl32.dll - only unelevated

Comment 3

[Robert Strong (they/them - no direct email)]

Attachment: patch in progress

I'd like to get feedback on this approach. Note: the nsUpdateDriver.cpp code will be refactored in bug 1156046 and I'd like to keep the changes to it simple in this bug so it can be easily uplifted.

Comment 4

[Robert Strong (they/them - no direct email)]

I landed the code and a couple of fixes on oak and updating is working as expected so far. Yay!

Comment 5

[Robert Strong (they/them - no direct email)]

Attachment: patch in progress

Includes a couple of fixes

Comment 6

[Brian R. Bondy [:bbondy]]

Comment on attachment 8597392 [details] [diff] [review]
patch in progress

Review of attachment 8597392 [details] [diff] [review]:
-----------------------------------------------------------------

neat :)

::: toolkit/mozapps/update/updater/updater.cpp
@@ +896,5 @@
> +      NS_tsnprintf(childPath, sizeof(childPath)/sizeof(childPath[0]),
> +                   NS_T("%s/%s"), path, entry->d_name);
> +      rv = remove_recursive_on_reboot(childPath, deleteDir);
> +      if (rv) {
> +// Log

// pls

@@ +901,5 @@
> +      }
> +    }
> +  }
> +
> +  NS_tclosedir(dir);

nit: Make sure dir is non null

::: toolkit/xre/nsUpdateDriver.cpp
@@ +414,5 @@
>                     nsIFile *appDir, int appArgc, char **appArgv)
>  {
>    nsresult rv;
>  
> +#ifndef XP_WIN

nit: Pls explain here why we don't do this on Windows.

Comment 7

[Robert Strong (they/them - no direct email)]

I've tested the different paths this can take and all is looking good. I'll clean up the patch and submit it for review soon.

Comment 8

[Robert Strong (they/them - no direct email)]

Attachment: patch rev1

(In reply to Brian R. Bondy [:bbondy] from comment #6)
> ::: toolkit/mozapps/update/updater/updater.cpp
> @@ +896,5 @@
> > +      NS_tsnprintf(childPath, sizeof(childPath)/sizeof(childPath[0]),
> > +                   NS_T("%s/%s"), path, entry->d_name);
> > +      rv = remove_recursive_on_reboot(childPath, deleteDir);
> > +      if (rv) {
> > +// Log
> 
> // pls
Actually the error will already have been logged so I just added a comment explaining this.

> @@ +901,5 @@
> > +      }
> > +    }
> > +  }
> > +
> > +  NS_tclosedir(dir);
> 
> nit: Make sure dir is non null
There is already that dir is non null after it is opened.

> ::: toolkit/xre/nsUpdateDriver.cpp
> @@ +414,5 @@
> >                     nsIFile *appDir, int appArgc, char **appArgv)
> >  {
> >    nsresult rv;
> >  
> > +#ifndef XP_WIN
> 
> nit: Pls explain here why we don't do this on Windows.
Done

Comment 9

[Robert Strong (they/them - no direct email)]

Attachment: patch rev1

Comment 10

[Robert Strong (they/them - no direct email)]

Attachment: patch rev1

Comment 11

[Robert Strong (they/them - no direct email)]

Attachment: patch rev1

Though with a little work it should be possible to merge remove_recursive_on_reboot with ensure_remove_recursive I don't want to do that in this bug since it would add risk to the patch and this patch will likely get uplifted.

Comment 12

[Robert Strong (they/them - no direct email)]

I verified the following scenarios work for both an install under program files and an install in a writable location using oak:

service and staging
service and no staging
no service and staging
service and staging with the directory in use
service and staging with a second instance of the application running

Comment 13

[Stephen A Pohl [:spohl]]

Comment on attachment 8598417 [details] [diff] [review]
patch rev1

Review of attachment 8598417 [details] [diff] [review]:
-----------------------------------------------------------------

LGTM!

::: toolkit/mozapps/update/updater/updater.cpp
@@ +863,5 @@
> +    return rv;
> +  }
> +
> +  if (!S_ISDIR(sInfo.st_mode)) {
> +    NS_tchar tmpDeleteDir[MAXPATHLEN];

nit: Since we're dealing with a file here, maybe |tmpDeleteFile| is a better variable name?

@@ +865,5 @@
> +
> +  if (!S_ISDIR(sInfo.st_mode)) {
> +    NS_tchar tmpDeleteDir[MAXPATHLEN];
> +    GetTempFileNameW(deleteDir, L"rep", 0, tmpDeleteDir);
> +    NS_tremove(tmpDeleteDir);

nit: I think |rename_file| removes the destination file if it exists (and has extra logging in case of failure).

::: toolkit/xre/nsUpdateDriver.cpp
@@ +421,3 @@
>    // Steps:
>    //  - copy updater into updates/0/MozUpdater/bgupdate/ dir
>    //  - run updater with the correct arguments

nit: I wonder if these steps should be kept outside of the #ifndef, since running the updater with the correct arguments still applies to Windows. This is even more the case for the steps in |ApplyUpdates| later in this file. Maybe the step about copying the updater could be changed to say "on all platforms but Windows", or something like that?

Comment 14

[Robert Strong (they/them - no direct email)]

(In reply to Stephen Pohl [:spohl] from comment #13)
> Comment on attachment 8598417 [details] [diff] [review]
> patch rev1
> 
> Review of attachment 8598417 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> LGTM!
> 
> ::: toolkit/mozapps/update/updater/updater.cpp
> @@ +863,5 @@
> > +    return rv;
> > +  }
> > +
> > +  if (!S_ISDIR(sInfo.st_mode)) {
> > +    NS_tchar tmpDeleteDir[MAXPATHLEN];
> 
> nit: Since we're dealing with a file here, maybe |tmpDeleteFile| is a better
> variable name?
Done

> @@ +865,5 @@
> > +
> > +  if (!S_ISDIR(sInfo.st_mode)) {
> > +    NS_tchar tmpDeleteDir[MAXPATHLEN];
> > +    GetTempFileNameW(deleteDir, L"rep", 0, tmpDeleteDir);
> > +    NS_tremove(tmpDeleteDir);
> 
> nit: I think |rename_file| removes the destination file if it exists (and
> has extra logging in case of failure).
I considered that and instead rely on the logging that follows this since that is all that is needed.

> ::: toolkit/xre/nsUpdateDriver.cpp
> @@ +421,3 @@
> >    // Steps:
> >    //  - copy updater into updates/0/MozUpdater/bgupdate/ dir
> >    //  - run updater with the correct arguments
> 
> nit: I wonder if these steps should be kept outside of the #ifndef, since
> running the updater with the correct arguments still applies to Windows.
> This is even more the case for the steps in |ApplyUpdates| later in this
> file. Maybe the step about copying the updater could be changed to say "on
> all platforms but Windows", or something like that?
Done

Comment 15

[Robert Strong (they/them - no direct email)]

Attachment: patch for landing

[Security approval request comment]
How easily could an exploit be constructed based on the patch? Not too easily and less easily than other patches I've landed to mitigate this bug.

Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem? No

Which older supported branches are affected by this flaw? All

If not all supported branches, which bug introduced the flaw?

Do you have backports for the affected branches? If not, how different, hard to create, and risky will they be? Not yet but it should be fairly simple to backport.

How likely is this patch to cause regressions; how much testing does it need? Manual testing leads me to believe that this won't cause regressions but I still want this on nightly for around a week before uplifting.

Comment 16

[Robert Strong (they/them - no direct email)]

Attachment: aurora patch

only test changes for aurora

Comment 17

[Robert Strong (they/them - no direct email)]

Attachment: beta patch

test changes and context difference in updater.cpp

Comment 18

[Robert Strong (they/them - no direct email)]

Tests pass locally on aurora and beta. I'll provide steps for verification next

Comment 19

[Robert Strong (they/them - no direct email)]

To verify this bug you should be able to just use procmon and verify that the updater.exe process doesn't try to load any dll's from the updates directory.

Comment 20

[Robert Strong (they/them - no direct email)]

Process Name updater.exe and the path to your Windows profile should be sufficient for a filter. Then just search for .dll

Comment 21

[Al Billings [:abillings - ex-MoCo]]

Comment on attachment 8598828 [details] [diff] [review]
patch for landing

sec-approval+. It will be nice to get this fixed.

Comment 22

[Robert Strong (they/them - no direct email)]

Pushed to mozilla-inbound
https://hg.mozilla.org/integration/mozilla-inbound/rev/34da940cd412

I'll request branch approvals after this has baked.

Comment 23

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/34da940cd412

Comment 24

[Robert Strong (they/them - no direct email)]

I will be away from my computer until around 5/6. I don't expect any issues but if there are any please contact Stephen (:spohl) or Benjamin Smedberg during this time.

Comment 25

[Robert Strong (they/them - no direct email)]

Sylvestre, how long can I let this bake on Nightly and still get it in for Firefox 38 so it makes it into ESR?

Comment 26

[Robert Strong (they/them - no direct email)]

Liz, perhaps you can answer the question in comment #25

Comment 27

[Robert Strong (they/them - no direct email)]

Comment on attachment 8598861 [details] [diff] [review]
aurora patch

Approval Request Comment
[Feature/regressing bug #]: None
[User impact if declined]: They will still have this vulnerability
[Describe test coverage new/current, TreeHerder]: Landed on m-c, the tests exercise this code, and the update from Thursday to Friday used this code without any bug reports.
[Risks and why]: It would be nice to let this bake a little longer but there are no known issues at this time. 
[String/UUID change made/needed]: None

Comment 28

[Robert Strong (they/them - no direct email)]

Comment on attachment 8598863 [details] [diff] [review]
beta patch

Approval Request Comment
[Feature/regressing bug #]: None
[User impact if declined]: They will still have this vulnerability
[Describe test coverage new/current, TreeHerder]: Landed on m-c, the tests exercise this code, and the update from Thursday to Friday used this code without any bug reports.
[Risks and why]: It would be nice to let this bake a little longer but there are no known issues at this time. 
[String/UUID change made/needed]: None

Comment 29

[Robert Strong (they/them - no direct email)]

(In reply to Robert Strong - out until 5/6 [:rstrong] (use needinfo to contact me) from comment #25)
> Sylvestre, how long can I let this bake on Nightly and still get it in for
> Firefox 38 so it makes it into ESR?
I was told over irc that it would need to land by Sunday.

Comment 30

[Robert Strong (they/them - no direct email)]

Pushed to mozilla-aurora
https://hg.mozilla.org/releases/mozilla-aurora/rev/a0e53f1db114

Comment 31

[Robert Strong (they/them - no direct email)]

Ryan, could you land this for 38 and 38esr?

Comment 32

[Robert Strong (they/them - no direct email)]

attachment #8598863 [details] [diff] [review] needs to land for 38 and 38esr.

Comment 33

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-release/rev/dd9d5b512e0e

Comment 34

[Ryan VanderMeulen [:RyanVM]]

(It'll merge to other 38 branches from there)

Comment 35

[Robert Strong (they/them - no direct email)]

I'd prefer not landing this on esr31 but I'll create a patch if it is wanted.

Comment 36

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/dd9d5b512e0e
https://hg.mozilla.org/releases/mozilla-esr38/rev/dd9d5b512e0e

Comment 37

[[SV Manager] Florin Mezei, QA (:FlorinMezei)]

Robert, is manual testing needed for this fix? If yes, can you provide us some detailed steps to verify it?

Comment 38

[Kamil Jozwiak [:kjozwiak]]

* Reproduced the original issue using the following build:
** http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2015/02/2015-02-09-03-02-04-mozilla-central/

* Went through verification using the following build:
** http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2015-05-01-03-02-05-mozilla-central/

For each of the OS's listed below, went through the following as well:

Scrubbing through procmon to see if DLL's are being loaded into "\updates\0\" or "\updates\0\updater.exe.Local"
* Older build: found the original DLL's listed above
* Build with fix: couldn't find the DLL's listed above

Win XP Pro SP3 x86 - PASSED
==================

* \updates\0\lpk.dll
** Older build: never appeared for me as an affected DLL, going through it either way as it appears in comment #1
** Build with fix: no cmd prompt spawned (ran through update twice)

* \updates\0\usp10.dll
** Older build: never appeared for me as an affected DLL, going through it either way as it appears in comment #1
** Build with fix: no cmd prompt spawned (ran through update twice)

* \updates\0\updater.exe.Local\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.6028_x-ww_61e65202\comctl32.dll
** Older build: couldn't reproduce the original issue
** Build with fix: no cmd prompt spawned (ran through update twice)

I also tried \updates\0\MozUpdater\bgupdate\updater.exe.Local\ without any luck reproducing the original issue

Win XP Pro SP2 x64: - PASSED
=================== 

* \updates\0\updater.exe.Local\WOW64_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.3790.5190_x-ww_B8C2A5B7\comctl32.dll
** Older build: spawned 1 cmd prompt (integrity level not available in XP)
** Build with fix: no cmd prompt spawned (ran through update twice)

Win Vista Ultimate SP2 x86 - PASSED
==========================

* \updates\0\apphelp.dll
** Older build: crashed the updater and spawns 1 medium integrity cmd prompt (fx doesn't update)
** Build with fix: no cmd prompt spawned and updated without crashes (ran through update twice)

* \updates\0\updater.exe.Local\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.6002.18305_none_5cb72f2a088b0ed3\comctl32.dll
** Older build: spawned 3 medium and 2 high integrity cmd prompts
** Build with fix: no cmd prompt spawned and updated without crashes (ran through update twice)

Win Vista Ultimate SP2 x64 - PASSED
==========================

* \updates\0\apphelp.dll
** Older build: crashed the updater and spawns 1 medium integrity cmd prompt (fx doesn't update)
** Build with fix: no cmd prompt spawned and updated without crashes (ran through update twice)

* \updates\0\updater.exe.Local\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.6002.18305_none_5cb72f2a088b0ed3\comctl32.dll
** Older build: spawned 3 medium and 2 high integrity cmd prompts
** Build with fix: no cmd prompt spawned (ran through update twice)

Win 7 Pro SP1 x86 - PASSED
=================

* \updates\A3710B8EBB50CD3\updates\0\version.DLL
** Older build: spawned 1 medium integrity cmd prompt
** Build with fix: no cmd prompt spawned (ran through update twice)

* \updates\A3710B8EBB50CD3\updates\0\SSPICLI.DLL
** Older build: spawned 1 medium integrity cmd prompt
** Build with fix: no cmd prompt spawned (ran through update twice)

* \updates\0\updater.exe.Local\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.17514_none_41e6975e2bd6f2b2\comctl32.dll
** Older build: spawned 1 medium integrity cmd prompt
** Build with fix: no cmd prompt spawned (ran through update twice)

Win 7 Pro SP1 x64 - PASSED
=================

Using FX x86:

** \updates\EEFEA8717BC47F65\updates\0\version.DLL
** Older build: spawned 1 medium integrity cmd prompt
** Build with fix: no cmd prompt spawned (ran through update twice)

* \updates\0\updater.exe.Local\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.17514_none_41e6975e2bd6f2b2\comctl32.dll
** Older build: spawned 1 medium integrity cmd prompt
** Build with fix: no cmd prompt spawned (ran through update twice)

Using FX x64:

FX x64:
* \updates\A3710B8EBB50CD3\updates\0\version.DLL
** Older build: spawned 1 medium integrity cmd prompt
** Build with fix: no cmd prompt spawned (ran through update twice)

* \updates\A3710B8EBB50CD3\updates\0\SSPICLI.DLL
** Older build: spawned 1 medium integrity cmd prompt
** Build with fix: no cmd prompt spawned (ran through update twice)

* \updates\0\updater.exe.Local\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.17514_none_fa396087175ac9ac\comctl32.dll
** Older build: spawned 1 medium integrity cmd prompt
** Build with fix: no cmd prompt spawned (ran through update twice)

Comment 39

[[SV Manager] Florin Mezei, QA (:FlorinMezei)]

Kamil, do you think you could also do a quick check for this on ESR 38.0?

Comment 40

[Kamil Jozwiak [:kjozwiak]]

* Went through verification using the following build:
** http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2015-05-02-00-40-03-mozilla-aurora/

Used the same method as comment # 38. Not adding as much detail as it's the same test, just a different channel.

Win XP Pro SP3 x86 - PASSED
==================

* \updates\0\lpk.dll
* \updates\0\usp10.dll
* \updates\0\updater.exe.Local\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.6028_x-ww_61e65202\comctl32.dll


Win XP Pro SP2 x64: - PASSED
=================== 

* \updates\0\updater.exe.Local\WOW64_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.3790.5190_x-ww_B8C2A5B7\comctl32.dll

Win Vista Ultimate SP2 x86 - PASSED
==========================

* \updates\0\apphelp.dll
* \updates\0\updater.exe.Local\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.6002.18305_none_5cb72f2a088b0ed3\comctl32.dll


Win Vista Ultimate SP2 x64 - PASSED
==========================

* \updates\0\apphelp.dll
* \updates\0\updater.exe.Local\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.6002.18305_none_5cb72f2a088b0ed3\comctl32.dll


Win 7 Pro SP1 x86 - PASSED
=================

* \updates\A3710B8EBB50CD3\updates\0\version.DLL
* \updates\A3710B8EBB50CD3\updates\0\SSPICLI.DLL
* \updates\0\updater.exe.Local\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.17514_none_41e6975e2bd6f2b2\comctl32.dll

Win 7 Pro SP1 x64 - PASSED
=================

Using FX x86:

* \updates\EEFEA8717BC47F65\updates\0\version.DLL
* \updates\0\updater.exe.Local\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.17514_none_41e6975e2bd6f2b2\comctl32.dll

Using FX x64:

* \updates\A3710B8EBB50CD3\updates\0\version.DLL
* \updates\A3710B8EBB50CD3\updates\0\SSPICLI.DLL
* \updates\0\updater.exe.Local\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.17514_none_fa396087175ac9ac\comctl32.dll

Comment 41

[Kamil Jozwiak [:kjozwiak]]

(In reply to Florin Mezei, QA (:FlorinMezei) from comment #39)
> Kamil, do you think you could also do a quick check for this on ESR 38.0?

Ya, I'll verify it on ESR 38.0 as well. Could you link me to the build?

Comment 42

[Kamil Jozwiak [:kjozwiak]]

Currently can't verify the following channels:

* fx38 - the two latest builds are from 29-Apr-2015 and 04-May-2015. Because the fix was merged on 01-May-2015 (comment # 33), I need two builds that have been created after 2015-05-01 to correctly update. Right now, there's only the build from 04-May-2015.

* fx38.0.5 - not created yet (will need two builds to test updating)

* fx-esr38 - only a single nightly build is currently available from 05-May-2015. As mentioned above, I need two builds.

I can't use debug builds (2015-05-05-mozilla-esr38-debug) nor tinderbox builds because they're not nighties and don't have updates enabled. I'll have to wait until I either have two nightly builds that have been created after the fix was merged.

Robert, let me know if there's anything else I can do. I'll leave the needinfo for Florin (comment # 39) in case he knows any other builds that have been created that I can use but can't find.

Comment 43

[Robert Strong (they/them - no direct email)]

There is a way to force an update using the complete to verify. I'll set that up for you

Comment 44

[Robert Strong (they/them - no direct email)]

You can use the following to force the latest esr38 to update to itself
http://exchangecode.com/robert/work/snippets/esr38.xml

You can also use the following url to apply an empty update to test this.
http://exchangecode.com/robert/work/snippets/general.xml

Just add a new string pref named app.update.url.override with the value of the url you are using

Comment 45

[Robert Strong (they/them - no direct email)]

For comment #44

Comment 46

[Kamil Jozwiak [:kjozwiak]]

Thanks Robert, that definitely did the trick. I used your xml file(s) as the template but had to upload it to my server as I had to change the hash values:

* http://kamiljozwiak.com/esr38.xml

Comment 47

[Robert Strong (they/them - no direct email)]

Sorry about that and thanks!

Comment 48

[[SV Manager] Florin Mezei, QA (:FlorinMezei)]

Kamil, I'm not sure if you still need it, but here's the link to the 38 ESR builds location: ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/38.0esr-candidates/build1/.

Comment 49

[Kamil Jozwiak [:kjozwiak]]

* Went through verification using the following build:
** http://ftp.mozilla.org/pub/mozilla.org/firefox/candidates/38.0esr-candidates/build1/

Used the method outlined in comment # 44 for updates. Also wanted to mention that I couldn't test FX x64 on the Win 7 x64 machine as the build doesn't exist.

Win XP Pro SP3 x86 - PASSED
==================

* \updates\0\lpk.dll
* \updates\0\usp10.dll
* \updates\0\updater.exe.Local\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.6028_x-ww_61e65202\comctl32.dll


Win XP Pro SP2 x64: - PASSED
=================== 

* \updates\0\updater.exe.Local\WOW64_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.3790.5190_x-ww_B8C2A5B7\comctl32.dll

Win Vista Ultimate SP2 x86 - PASSED
==========================

* \updates\0\apphelp.dll
* \updates\0\updater.exe.Local\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.6002.18305_none_5cb72f2a088b0ed3\comctl32.dll


Win Vista Ultimate SP2 x64 - PASSED
==========================

* \updates\0\apphelp.dll
* \updates\0\updater.exe.Local\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.6002.18305_none_5cb72f2a088b0ed3\comctl32.dll

Win 7 Pro SP1 x86 - PASSED
=================

* \updates\A3710B8EBB50CD3\updates\0\version.DLL
* \updates\A3710B8EBB50CD3\updates\0\SSPICLI.DLL
* \updates\0\updater.exe.Local\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.17514_none_41e6975e2bd6f2b2\comctl32.dll

Win 7 Pro SP1 x64 - PASSED (Couldn't test check on FX x64 as only x86 builds of FX are available)
=================

Using FX x86:

* \updates\EEFEA8717BC47F65\updates\0\version.DLL
* \updates\0\updater.exe.Local\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.17514_none_41e6975e2bd6f2b2\comctl32.dll

Using FX x64: (only x86 builds available)

Comment 50

[Kamil Jozwiak [:kjozwiak]]

* Went through verification using the following build:
** http://ftp.mozilla.org/pub/mozilla.org/firefox/candidates/38.0-candidates/build2/

Used the same method outlined in comment # 44 for updates using the following URL:

- http://kamiljozwiak.com/fx38.xml

I also wanted to mention that I couldn't test FX x64 on the Win 7 x64 machine as fx x64 builds for the release candidate haven't been created.

Win XP Pro SP3 x86 - PASSED
==================

* \updates\0\lpk.dll
* \updates\0\usp10.dll
* \updates\0\updater.exe.Local\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.6028_x-ww_61e65202\comctl32.dll


Win XP Pro SP2 x64: - PASSED
=================== 

* \updates\0\updater.exe.Local\WOW64_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.3790.5190_x-ww_B8C2A5B7\comctl32.dll


Win Vista Ultimate SP2 x86 - PASSED
==========================

* \updates\0\apphelp.dll
* \updates\0\updater.exe.Local\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.6002.18305_none_5cb72f2a088b0ed3\comctl32.dll


Win Vista Ultimate SP2 x64 - PASSED
==========================

* \updates\0\apphelp.dll
* \updates\0\updater.exe.Local\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.6002.18305_none_5cb72f2a088b0ed3\comctl32.dll

Win 7 Pro SP1 x86 - PASSED
=================

* \updates\A3710B8EBB50CD3\updates\0\version.DLL
* \updates\A3710B8EBB50CD3\updates\0\SSPICLI.DLL
* \updates\0\updater.exe.Local\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.17514_none_41e6975e2bd6f2b2\comctl32.dll

Win 7 Pro SP1 x64 - PASSED (Couldn't test fx64, builds not available for candidates builds)
=================

Using FX x86:

* \updates\EEFEA8717BC47F65\updates\0\version.DLL
* \updates\0\updater.exe.Local\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.17514_none_41e6975e2bd6f2b2\comctl32.dll

Using FX x64: (only x86 builds available for the candidates builds)

Comment 51

[Kamil Jozwiak [:kjozwiak]]

I'll go through fx38.0.5 verification once the build is released on Sunday/Monday. I'll use the same update method as outlined in comment # 44.

Comment 52

[Robert Strong (they/them - no direct email)]

Thanks Kamil! You thoroughness is appreciated!

Comment 53

[Kamil Jozwiak [:kjozwiak]]

* Went through verification using the following build:
** http://ftp.mozilla.org/pub/mozilla.org/firefox/candidates/38.0.5b1-candidates/build2/

Used the same method outlined in comment # 44 for updates using the following URL:

- http://kamiljozwiak.com/fx385x86.xml [fx86]
- http://kamiljozwiak.com/fx385x64.xml [fx64]

Win XP Pro SP3 x86 - PASSED
==================

* \updates\0\lpk.dll
* \updates\0\usp10.dll
* \updates\0\updater.exe.Local\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.6028_x-ww_61e65202\comctl32.dll

Win XP Pro SP2 x64: - PASSED
=================== 

* \updates\0\updater.exe.Local\WOW64_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.3790.5190_x-ww_B8C2A5B7\comctl32.dll

Win Vista Ultimate SP2 x86 - PASSED
==========================

* \updates\0\apphelp.dll
* \updates\0\updater.exe.Local\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.6002.18305_none_5cb72f2a088b0ed3\comctl32.dll

Win Vista Ultimate SP2 x64 - PASSED
==========================

* \updates\0\apphelp.dll
* \updates\0\updater.exe.Local\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.6002.18305_none_5cb72f2a088b0ed3\comctl32.dll

Win 7 Pro SP1 x86 - PASSED
=================

* \updates\A3710B8EBB50CD3\updates\0\version.DLL
* \updates\A3710B8EBB50CD3\updates\0\SSPICLI.DLL
* \updates\0\updater.exe.Local\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.17514_none_41e6975e2bd6f2b2\comctl32.dll

Win 7 Pro SP1 x64 - PASSED
=================

Using FX x86:

* \updates\EEFEA8717BC47F65\updates\0\version.DLL
* \updates\0\updater.exe.Local\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.17514_none_41e6975e2bd6f2b2\comctl32.dll

Using FX x64:

* \updates\A3710B8EBB50CD3\updates\0\version.DLL
* \updates\A3710B8EBB50CD3\updates\0\SSPICLI.DLL
* \updates\0\updater.exe.Local\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.17514_none_fa396087175ac9ac\comctl32.dll