Use maintenance service if the fallback key is present so tests can run

RESOLVED FIXED in mozilla12

Status

()

Toolkit
Application Update
RESOLVED FIXED
7 years ago
7 years ago

People

(Reporter: bbondy, Assigned: bbondy)

Tracking

unspecified
mozilla12
x86_64
Windows 7
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Assignee)

Description

7 years ago
If fallback key is present always use the service when pending-service state is written, even if we already have write access to the installation directory.

This is needed before we can land bug 481815 and friends so that Ehsan's tests can run. I plan to do this today.  The patch should be very small.
(Assignee)

Comment 1

7 years ago
Created attachment 582171 [details] [diff] [review]
Patch v1.

This patch fixes tests so they work after the newly added security mechanisms.
Attachment #582171 - Flags: review?(robert.bugzilla)
Comment on attachment 582171 [details] [diff] [review]
Patch v1.

>diff --git a/toolkit/mozapps/update/common/pathhash.h b/toolkit/mozapps/update/common/pathhash.h
>--- a/toolkit/mozapps/update/common/pathhash.h
>+++ b/toolkit/mozapps/update/common/pathhash.h
>@@ -44,9 +44,12 @@
>  * @param  filePath     The input file path to get a registry path from
>  * @param  registryPath A buffer to write the registry path to, must 
>  *                      be of size in WCHARs MAX_PATH + 1
>  * @return TRUE if successful
> */
> BOOL CalculateRegistryPathFromFilePath(const LPCWSTR filePath, 
>                                        LPWSTR registryPath);
> 
>+#define FallbackKey \
>+  L"SOFTWARE\\Mozilla\\MaintenanceService\\3932ecacee736d366d6436db0f55bce4"
You have both FallbackKey and fallbackKey which can be confusing. For this I think FallbackKeyPath or similar would be better

I know I didn't catch this until now so if it is a pain don't bother but it would be better to replace Fallback / fallback with Test / test throughout so it is clear that this isn't used as a fallback for normal updates.

Add a comment describing what this is used for.

>+
> #endif
>diff --git a/toolkit/mozapps/update/test/unit/head_update.js.in b/toolkit/mozapps/update/test/unit/head_update.js.in
>--- a/toolkit/mozapps/update/test/unit/head_update.js.in
>+++ b/toolkit/mozapps/update/test/unit/head_update.js.in
>@@ -542,33 +542,48 @@ function runUpdateUsingService(aInitialS
>...
>-    if (status == STATE_PENDING) {
>+    if (status == STATE_APPLYING) {
Do you think this could race where the status file isn't changed in time to STATE_APPLYING before this check? If it is a possibility it might be best to check for both STATE_PENDING and STATE_APPLYING.

>diff --git a/toolkit/mozapps/update/updater/updater.cpp b/toolkit/mozapps/update/updater/updater.cpp
>--- a/toolkit/mozapps/update/updater/updater.cpp
>+++ b/toolkit/mozapps/update/updater/updater.cpp
>@@ -1595,20 +1595,34 @@ int NS_main(int argc, NS_tchar **argv)
>   gSourcePath = argv[1];
> 
> #ifdef XP_WIN
>   // Disable every privilege we don't need. Processes started using
>   // CreateProcess will use the same token as this process.
>   UACHelper::DisablePrivileges(NULL);
> 
>   bool useService = false;
>+  bool fallbackKeyExists = false;
>+
>   // We never want the service to be used unless we build with
>   // the maintenance service.
> #ifdef MOZ_MAINTENANCE_SERVICE
>   IsUpdateStatusPending(useService);
>+  // Our tests run with a different apply directory for each test.
>+  // We use this registry key on our test slaves to store the 
>+  // allowed name/issuers.
>+  HKEY fallbackKey;
>+  LSTATUS retCode = RegOpenKeyExW(HKEY_LOCAL_MACHINE, 
>+                                  FallbackKey, 0,
>+                                  KEY_READ | KEY_WOW64_64KEY, &fallbackKey);
The return type for RegOpenKeyExW is LONG let's just go with LONG here and elsewhere. Since I missed this previously could you check the patches for other instances such as registrycertificates.cpp?

Alternatively, you could just do this in the if statement itself since retCode is only used in the if statement here... likely the same in the other uses as well.

>+  if (ERROR_SUCCESS == retCode) {
>+    fallbackKeyExists = true;
>+    RegCloseKey(fallbackKey);
>+  }

I'd like a quick skim over this again before r+'ing though I am tempted to just r+ with nit fixed.
Attachment #582171 - Flags: review?(robert.bugzilla) → review+
(Assignee)

Comment 3

7 years ago
Created attachment 582254 [details] [diff] [review]
Patch v2.

Implemented review comments, thanks for the quick review.
Attachment #582171 - Attachment is obsolete: true
Attachment #582254 - Flags: review?(robert.bugzilla)
Comment on attachment 582254 [details] [diff] [review]
Patch v2.

Looks good and thanks.
Attachment #582254 - Flags: review?(robert.bugzilla) → review+
(Assignee)

Updated

7 years ago
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla12
You need to log in before you can comment on or make changes to this bug.