-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rebase on top of v1.3.36.111 #36
Conversation
dir/ matches the directory and the paths underneath it.
The build passes with the latest version of the compiler (16.7.3), on /std:c++latest (even though the build file declares c++17 as std), protocol buffers version 3.13.0, and googletest version 1.10.0.
Version 1.7.3 needs an additional generated file zip_err_str.c. This file is missing in the distribution itself and has to be generated. To make it easier for people to build open source without having to invoke CMake and generate this file, this file is being included in this CL.
This CL changes from passing in a more permissive security descriptor to NULL. The ACLs in the default security descriptor for a named pipe grant full control to the LocalSystem account, administrators, and the creator owner. This is sufficient for now, since Omaha is the only client for the corresponding Breakpad server. The drawback is that we will not be able to capture crashes that happen in Medium Integrity Machine Omaha processes, which is a corner case, and hence is ok.
This change includes the following: * Group Policy and DM. * XML protocol. * Policy template. * COM interface. Some DM code is commented out until another CL lands.
It is useful to surface the currently running version of the Updater as well as the last successful check for updates in chrome://policy.
This change allows MDM enrolled machines that are running a non-personal version of Windows to be considered domain-joined machines. Note: MDM is not the same as Azure Active Directory, which will be a separate change. Also fixed an issue where a couple of policies were not falling back to DM policies.
This is a needed fix for customers with Azure AD joined machines who are not able to enforce Group Policy for Chrome and other Google apps administered by GoogleUpdate.
The idea is to send some extra context even in cases where the install is a success.
Google Update may get its policies from CBCM or from GPO. This isn't reflected in the "Source" column of chrome://policy. This makes diagnosing policy behavior very difficult. Fixing this would be a great help for admins.
* Allow for PolicyStatus to run at High Integrity under the Medium Service. * Support for OnDemand refresh of DM Policies, enabled by running at High Integrity. * Add PolicyStatus for User Omaha. This is needed to allow chrome://policy to show policy status for per-user installations.
If ::NetGetJoinInformation() returns 'NetSetupUnknownStatus' and the Windows version is an Enterprise SKU, we will consider it domain-joined.
There is an upper limit for how large the payload files can be for hash verification purposes. Currently, the limit is 512MB. This CL increases the limit to 1GB. A new error for this case is defined: SIGS_E_FILE_SIZE_TOO_BIG.
This change increases the size of the read buffer from 128KB to 1MB to assess the impact of reducing the number of IO calls during the verification of payload hashes.
This change contains two work arounds to slightly improve the user experience due to long times taken by hash verification of large files (>512MB). First, it changes the text displayed when the download is complete from "Download complete." to "Download complete. Please wait while the installer is verified.". The change is made for en-us only. GRIT in Omaha is broken at the moment. i18n must be dealt with in a follow up CL. Second, checking of hashes occurs at several times during /install execution. In particular, it happens once right before running the installer. Unfortunately, during the hash check, the model lock in Omaha is taken, so Omaha can't respond to polling for state changes. That means that the UI keeps displaying "Download Complete." instead of displaying "Waiting to install...". There is no easy workaround for this. A delay is introduced in the WaitingToInstall state to allow the UI client to catch up with the state transition, and show the "Waiting to install..." text while the hash is checked.
…backs. This CL has the following changes: * Adds a new IPolicyStatus2 interface which exposes policies from multiple sources. For instance, if both Group Policy and DM have a policy set and Group Policy has precedence, then the policy values will supply the conflicting DM value as well. The IPolicyStatus interface is deprecated. * Changes from using a single policy source for all Omaha policies, to one where all sources are considered. This brings the behavior on par with Chrome, and lessens the intellectual overhead for customers and support teams. This also makes it easier to support a gradual migration from platform policies to CBCM.
The prod is not responding with Etag any longer. We are using the kHeaderXETag exclusively now. Handling this header is encapsulated in the CupEcdsaRequest and not visible at all in the WebServiceClient class. The test determines that sending with CUP succeeds solely by instantiating the WebServiceClient with `use_cup=true`. There is no need to check for the presence of CUP headers, which were not tested in the past either.
For Google builds, the function UploadMetrics() is going to return early, before the network call is made, and return S_FALSE. The idea here is that we want to stop sending usage stats, and start deprecating the feature, without making intrusive changes to the code, or creating stability issues.
Version 1.3.36.21 signed on 09/21/2020.
This CL has the following changes: * refactors the proxy detection policies to go through the Config Manager, thereby unifying all policies under the ConfigManager class. * exposes the proxy detection policies via the IPolicyStatus2 COM interface, thereby allowing chrome://policy/ to display these policies.
Toolchain and libraries update
Limit the path where LoadLibray should be looking for dlls to %windir%\System32 only.
(Edit: @mihaiplesa said he's looking into setting up the different build VM so no need for you to do this @linhkikuchi.) @linhkikuchi compiling this PR requires a slightly different build environment from the current Omaha build. Specifically, instead of The repository also now needs to be checked out with the |
@simonhong thank you again for the explanations on Slack. I have another question please: Why are the UUIDs for |
For reviewers: The diff between this PR and
So I computed the diff between Instead of "merging" this PR in the classical sense, it might be easiest to simply make it the new |
TODO purely from a code perspective:
Once CI can be run for this PR, it should be relatively trivial to remove the files and see whether everything still works. For now, I'm blocked on this CI integration and am waiting for answers to my questions above. |
I assume above two didn't exist when we forked omaha at first time. and I found that we are using outdated https://github.com/brave/brave-core/blob/master/chromium_src/google_update/google_update_idl.idl. |
Good catch. I remember copying the |
I wrote about it when I did porting first time to https://github.com/brave/brave-browser/wiki/Chromium-rebases at |
@mherrmann so you need me to update the windows build node to have |
@linhkikuchi yes, thank you :-) |
(PS @linhkikuchi as I mentioned Mihai told me yesterday he's looking into this but either he or you may do it; Also, we probably still need the |
@mherrmann I downloaded
|
@linhkikuchi as I wrote above - we need C:\protobuf-3.17.3 with contents bin/, include/ and src/ as explained under "Google Protocol Buffers" here. Thanks! |
@linhkikuchi we can install |
@mherrmann this has been done https://github.com/brave/devops/pull/6210 |
Thank you @linhkikuchi! I kicked off a build in brave/brave-core#10883 now. |
gclient does not support submodules. The cleanest way to deal with this repository's dependencies when included from another repo via a DEPS file is to add a DEPS file of our own.
It was removed upstream in 2f4139 and was likely still in our tree by accident.
It seems it is no longer being used.
Apparently, it needs to be odd.
Closing as this PR is not needed anymore since it became the default branch. |
Tested to compile with:
The remaining dependencies are now included via a
DEPS
file.The following 43 tests fail. These tests already failed before the rebase, with the exception of
UnitTestHelpersTest.ClearGroupPolicies
, which also fails upstream.See failing tests