cdd5206c6507fa5c70344c269053d30777f7d674 |
|
19-May-2017 |
Sen Jiang <senj@google.com> |
Support IsDeltaPayload per <package>. Mixed full and delta payloads are now supported for multi-payload. Bug: 36252799 Test: update_engine_unittests Change-Id: Ic519f8399579c714a65ba9f9f948a389fcc249ed (cherry picked from commit 4928112f8635f7a5b583171640aee2bda690ba34)
/system/update_engine/omaha_response_handler_action.cc
|
0affc2c099fac47b999ba39f8f1bacb418e65a97 |
|
11-Feb-2017 |
Sen Jiang <senj@google.com> |
Parse multiple packages from Omaha response. The multi-payload info are stored in OmahaResponse and InstallPlan, but we still can only apply the first payload for now. Bug: 36252799 Test: mma -j Test: update_engine_unittests Change-Id: I5ca63944ae9082670d0e67888409374f140d4245 (cherry picked from commit 2aba8a87d4fac245a2e2d238b3159f8eabce630f)
/system/update_engine/omaha_response_handler_action.cc
|
2703ef4466066d64d8021904e233b120f38c0272 |
|
16-Mar-2017 |
Sen Jiang <senj@google.com> |
Store raw payload hash blob in install plan. We were using a custom sha256 pair in Omaha response, now that Omaha has a standard hash_sha256 field in package, we should use that instead. The difference is that hash_sha256 is encoded in hex instead of base64, but the android payload property is still using base64, to be backward compatible, we have to keep accepting base64 there, to avoid decoding and then re-encoding to another encoding, we store the decoded raw hash. Also removed the hash() related functions in HashCalculator, since it's rarely used and the caller should encode it in whatever encoding they want. Also make use of RawHashOfBytes to simply code in a few places. Bug: 36252799 Test: update_engine_unittests Change-Id: Iaa02611b4c9cda3ead5de51e777e8caba6d99d93 (cherry picked from commit f14d51b6823522f6b2eb834f9e14d72c8363a3ad)
/system/update_engine/omaha_response_handler_action.cc
|
64d9878470aa7b388e971862181daf6260851602 |
|
06-Feb-2016 |
Alex Deymo <deymo@google.com> |
Replace is_full_update boolean with a payload_state enum. The "is_full_update" flag in the InstallPlan is required to decide whether we should run a FilesystemVerification step before start downloading the payload (for delta payloads) or not (for full payloads). This step is done before start downloading the payload and not after downloading the metadata to avoid long delays in the connection which would then drop and require a retry. Since the not so recent inclusion of the source_data_hash field in the delta operations, the source data is verified on each operation, so the install plan field and the pre-download FilesystemVerification is not needed anymore. To help deprecate this process, which is not included in the non-Brillo version, this patch changes the is_full_update field to a payload_state enum with a third "unknown" state that will be changed to delta or full once the payload metadata is parsed. Bug: 25631949 TEST=unittests updated. TEST=Pushed a delta update to edison-eng and a non-Brillo target. Change-Id: I17d8bf58990d8465bb8487adc66601f1c1dfca6d
/system/update_engine/omaha_response_handler_action.cc
|
0103c36caa2e38e034e0d22185736b9ccfb35c58 |
|
20-Jan-2016 |
Alex Vakulenko <avakulenko@google.com> |
update_engine: Update libchrome APIs to r369476 The new libchrome has been ported from Chromium and some APIs have changed. Make necessary changes at call sites. Change-Id: I42e65bda7f1dbdf6f6e0ebf356d2cfea6b729193
/system/update_engine/omaha_response_handler_action.cc
|
39910dcd1d68987ccee7c3031dc269233a8490bb |
|
10-Nov-2015 |
Alex Deymo <deymo@google.com> |
Split payload application code into a subdirectory. This patch splits from the main libupdate_engine code the part that is strictly used to download and apply a payload into a new static library, moving the code to subdirectories. The new library is divided in two subdirectories: common/ and payload_consumer/, and should not depend on other update_engine files outside those two subdirectories. The main difference between those two is that the common/ tools are more generic and not tied to the payload consumer process, but otherwise they are both compiled together. There are still dependencies from the new libpayload_consumer library into the main directory files and DBus generated files. Those will be addressed in follow up CLs. Bug: 25197634 Test: FEATURES=test emerge-link update_engine; `mm` on Brillo. Change-Id: Id8d0204ea573627e6e26ca9ea17b9592ca95bc23
/system/update_engine/omaha_response_handler_action.cc
|
856166594771c61973856f563e622ccb7dd48aa1 |
|
16-Oct-2015 |
Alex Deymo <deymo@google.com> |
Read ProductId, ProductVersion and Channel setting in Brillo. The ProductId, ProductVersion and current/target channels are specified in a very different way in Brillo compared to Chrome OS. This patch moves the logic to read and parse /etc/lsb-release in Chrome OS to a new image_properties module and implements the equivalent module in Brillo. This new module replaces some of the logic previously in the OmahaRequestParams class, both for parsing the read-only properties from the rootfs and parsing and storing the target channel in the stateful partition. The Chrome OS version of the new module keeps the same behavior, except that it falls back to "stable-channel" if the the current channel is missing in the rootfs (unlikely in Chrome OS). On the other hand, the new Brillo implementation reads these settings from the /etc/osrelease file and /etc/osrelease.d directory and doesn't allow to override those setting during development. The persisted target_channel and powerwash_allowed settings are stored in Prefs as many other settings. Finally, since Brillo images don't contain a channel name baked in the image, we store the channel name where we got the image from at the time of the update. The first boot after provisioning will default to "stable-channel". Bug: 25013069 Test: unittest in Chrome OS; `mm` and tested on a Brillo device. Change-Id: Icc114b8098af3edaaba715c9c2e3ebe9f417c876
/system/update_engine/omaha_response_handler_action.cc
|
6dd160ab4a0e631fdf1faf33eb7cb746ddf5ccdb |
|
10-Oct-2015 |
Alex Deymo <deymo@google.com> |
Disable deadline file in Android. The deadline file is used to notify chrome the deadline string sent by the server. This message allows chrome to take a different action based on the urgency of the update. While we would like to provide a proper API for this mechanism, it is rarely used in Chrome OS and doesn't work on Android, so we disable it for now. Bug: 24868621 Test: Unittest pass. No error message when tested on a dragonboard. Change-Id: I77fc5b55e1c6ec79f12d88be40426058b8aa4d02
/system/update_engine/omaha_response_handler_action.cc
|
e5e5fe926e9ea45b1a381af1bee91a86643ffd72 |
|
05-Oct-2015 |
Alex Deymo <deymo@google.com> |
Move InstallPlan partitions to a list of partitions. This patch changes the InstallPlan instance from having hard-coded rootfs and kernel paritions to have a list of partitions with a name, source and target information. The FilesystemVerifierAction, DeltaPerformer and PostInstallAction were adapter to use the list of partitions instead. In delta payloads (only supported in the current major version 1) the list of operations is still fixed: the rootfs first and the kernel. This list is now populated by the FilesystemVerifierAction including the size of these partitions, until the whole source partition hash checking is deprecated (b/23182225). The PostIntallAction now relies on the DeltaPerformer to populate the post-install information from the payload. This means that in rollback we won't run any device-specific post-install operation, and will simply flip the slots in the bootloader. Bug: 24667689 Test: Updated unittests. Tested on a dragonboard and a link. Change-Id: I8277e3190ac74e57832a58dc0730e3713f48af8a
/system/update_engine/omaha_response_handler_action.cc
|
e6fc8e1c01e6b733eee45c97d47b1960d0b64f1c |
|
28-Sep-2015 |
Alex Deymo <deymo@google.com> |
Update the payload public key location in Android. In Android builds, the payload public key is installed in a different location. Bug: 23937688 Test: emerge-link update_engine; `mm` Change-Id: Ic3a661e041a5709c116b6acd0d082a37b8bfe5df
/system/update_engine/omaha_response_handler_action.cc
|
763e7dbaac735da0ae802933a1015b6b7874bce2 |
|
28-Aug-2015 |
Alex Deymo <deymo@google.com> |
update_engine: New BootControlInterface class. The new BootControlInterface class is a platform-independent abstraction to control the bootloader. It provides methods for setting what partition slots are available for booting and getting the bootloader status about the available slots. The Chrome OS specific implementation of the bootloader was moved to the BootControlChromeOS which now depends on the vboot_host implementation used in Chrome OS. Follow up CL will implement the equivalent class for Brillo. BUG=b:23010637 TEST=unittests; cros flash from the new image and rolled back from it. Change-Id: I0a03aeeb8c21d8c99e1866b625e6e8c96628215b
/system/update_engine/omaha_response_handler_action.cc
|
aea4c1cea20dda7ae7e85fc8924a2d784f70d806 |
|
20-Aug-2015 |
Alex Deymo <deymo@google.com> |
Re-license update_engine to Apache2 This patch automatically replaced the license on all text files from Chromium OS (BSD style) to AOSP (Apache2), keeping the original year as a reference. The license header was added to .gyp and .gypi files, the NOTICE was replaced with a copy of the Apache2 license and MODULE_LICENSE_* file was updated. BUG=b/23084294 TEST=grep 'Chromium OS Authors' doesn't find anything. Change-Id: Ie5083750755f5180a8a785b24fe67dbf9195cd10
/system/update_engine/omaha_response_handler_action.cc
|
f6ee0163504eaf1a7cc136ba2c075d77ae2b4dd5 |
|
31-Jul-2015 |
Alex Deymo <deymo@chromium.org> |
update_engine: Move ConnectionManager to an abstract Interface. MockConnectionManager required to use one of ConnectionManager constructors passing pointers that won't be use by the mock. This patch moves the interface to its own ConnectionManagerInterface class. BUG=None TEST=unittests still pass. Change-Id: I9ed09daf8e4256304be7dab30cfbe751901dc24b Reviewed-on: https://chromium-review.googlesource.com/290120 Reviewed-by: Alex Vakulenko <avakulenko@chromium.org> Commit-Queue: Alex Deymo <deymo@chromium.org> Trybot-Ready: Alex Deymo <deymo@chromium.org> Tested-by: Alex Deymo <deymo@chromium.org>
/system/update_engine/omaha_response_handler_action.cc
|
6a9d3497bcf57b8b9f5765a2909a51c9f8119cd1 |
|
15-Jun-2015 |
Alex Vakulenko <avakulenko@chromium.org> |
platform2: Fix issues with new version of libchrome libchrome r334380 has the following breaking changes that need to be fixed: - base::JSONWriter::Write() and base::JSONWriter::WriteWithOptions() take "const base::Value&" instead of "const base::Value*" - base::JSONReader::Read() and base::JSONReader::ReadAndReturnError() return a scoped_ptr<base::Value> instead of base::Value* - base/safe_strerror_posix.h is moved to base/posix/safe_strerror.h - safe_strerror() is now in "base" namespace - StartsWithASCII(), EndsWith(), StringToUpperASCII(), LowerCaseEqualsASCII() are now in "base" namespace - ObserverList<T> is now in "base" namespace - base::PrintTo(base::FilePath) used in gtest is now moved to libchrome-test library and as such, unit test runners need to link to this library now. - crypto::RSAPrivateKey::CreateSensitive() is now removed from //crypto, so some of tests in chromeos-login that used that function had to be changed to use crypto::GenerateRSAKeyPairNSS() directly. - UnixDomanSocket class is now in "base" namespace - Pickle class is now in "base" namespace BUG=chromium:496469 TEST=`./build_packages` CQ-DEPEND=CL:277662 Change-Id: I36e5fbf2e36a92068873ffbd44020c862a3ed9e3 Reviewed-on: https://chromium-review.googlesource.com/277671 Reviewed-by: Alex Vakulenko <avakulenko@chromium.org> Commit-Queue: Alex Vakulenko <avakulenko@chromium.org> Trybot-Ready: Alex Vakulenko <avakulenko@chromium.org> Tested-by: Alex Vakulenko <avakulenko@chromium.org>
/system/update_engine/omaha_response_handler_action.cc
|
9f6f0a53509476be5f0ba152ec182d46a8d3c976 |
|
30-Mar-2015 |
Allie Wood <alliewood@chromium.org> |
update_engine: Implement SOURCE_COPY/SOURCE_BSDIFF operations. Implement SOURCE_COPY and SOURCE_BSDIFF in DeltaPerformer. These new operations are the same as MOVE and BSDIFF, respectively, except that they read from the source partition rather than the destination partition. Also fills in the source paths in omaha_response_handler_action, which were previously not being set. BUG=chromium:461632 TEST=`FEATURES=test emerge-link update_engine` and manual testing. Change-Id: I81eba5780c73ed920a5db72702d9d7c67dbaa673 Reviewed-on: https://chromium-review.googlesource.com/263747 Reviewed-by: Allie Wood <alliewood@chromium.org> Commit-Queue: Allie Wood <alliewood@chromium.org> Trybot-Ready: Allie Wood <alliewood@chromium.org> Tested-by: Allie Wood <alliewood@chromium.org>
/system/update_engine/omaha_response_handler_action.cc
|
907b4fa4009e5221f7b5f13cc03d9382e693c0c2 |
|
27-Jan-2015 |
David Pursell <dpursell@chromium.org> |
update_engine: Don't require hashes for non-official builds. CL 228293 changed hash check logic such that hashes are always required for official update URLs, on the assumption that they will always be available. This turns out to cause problems for situations like the referenced bug, where the devserver counts as an official URL but isn't providing hashes. This CL waives the hash check requirement for non-official (dev/test) builds. BUG=chromium:452139 TEST=cros_run_unit_tests --board=panther --packages=update_engine Change-Id: I0a48bfe216a8afdff27e06baa24b3d37e7517b25 Reviewed-on: https://chromium-review.googlesource.com/243730 Trybot-Ready: David Pursell <dpursell@chromium.org> Reviewed-by: Jorge Lucangeli Obes <jorgelo@chromium.org> Commit-Queue: David Pursell <dpursell@chromium.org> Tested-by: David Pursell <dpursell@chromium.org>
/system/update_engine/omaha_response_handler_action.cc
|
02c1864e204997175302b1aebe3e0be9c6699ea5 |
|
06-Nov-2014 |
David Pursell <dpursell@chromium.org> |
update_engine: Allow `cros flash` on base images. A goal of the upcoming debugd dev tools (crbug.com/403170), is to enable a path to modify a base image such that a developer could run `cros flash` on it. Currently update_engine disallows custom omaha URLs and forces a hash check for base builds, which breaks `cros flash`. This CL relaxes the restriction slightly to allow use on a base build as long as the system is in dev mode and the debugd dev tools are also enabled (dev tools are currently enabled only in dev mode when there is no owner). The check is done in update_attempter.cc, which only allows an unofficial Omaha URL if these conditions hold true (unofficial meaning not the main AU server or the AU test server). The other main change is AreHashChecksMandatory() in omaha_response_handler_action.cc, which now allows skipping hash checks for unofficial Omaha URLs. BUG=chromium:428053 TEST=Ran unit tests, `cros flash` on base images in various states. CQ-DEPEND=CL:227431 Change-Id: I8583ce6aa70feac8fe74b7a3992e8a4e761833c3 Reviewed-on: https://chromium-review.googlesource.com/228293 Reviewed-by: Alex Deymo <deymo@chromium.org> Trybot-Ready: David Pursell <dpursell@chromium.org> Commit-Queue: David Pursell <dpursell@chromium.org> Tested-by: David Pursell <dpursell@chromium.org>
/system/update_engine/omaha_response_handler_action.cc
|
74b5f55e6ff608857664fe151f54d78bfe0b75bb |
|
07-Oct-2014 |
Gilad Arnold <garnold@chromium.org> |
update_engine: Relocate inference and storage of P2P related properties. This change moves the inference of P2P related properties from OmahaRequestAction to OmahaResponseHandlerAction, and their storage from OmahaRequestParams to PayloadState. This is needed in order for the UpdateCanStart policy to be able to decide P2P properties, which only happens after the Omaha response is received and processed, and prior to applying the update. Further, P2P properties do not affect the Omaha request, and so there's no reason for them to reside in OmahaRequestParams nor decided as early as OmahaRequestAction. Additional cleanup includes swapping expected/actual arguments to EXPECT macros where appropriate, and removing redundant .Times(1) expectation qualifiers. BUG=chromium:384087 TEST=Unit tests. Change-Id: I6d5b4b44745d5dab7e350bdf019dbf804bf196a1 Reviewed-on: https://chromium-review.googlesource.com/223618 Reviewed-by: Gilad Arnold <garnold@chromium.org> Commit-Queue: Gilad Arnold <garnold@chromium.org> Tested-by: Gilad Arnold <garnold@chromium.org>
/system/update_engine/omaha_response_handler_action.cc
|
072359ca138504065e1e0c1189eb38c09576d324 |
|
18-Jul-2014 |
Alex Vakulenko <avakulenko@chromium.org> |
update_engine: fixed remaining linter and some spelling errors Fixed remaining errors from cpplint as well as some spelling errors mostly in comments. BUG=None TEST=FEATURES=test emerge-link update_engine Change-Id: I484988ab846ac5a3c68c016ddccfb247f225ec27 Reviewed-on: https://chromium-review.googlesource.com/208897 Reviewed-by: Alex Vakulenko <avakulenko@chromium.org> Commit-Queue: Alex Vakulenko <avakulenko@chromium.org> Tested-by: Alex Vakulenko <avakulenko@chromium.org>
/system/update_engine/omaha_response_handler_action.cc
|
d1c4d2dd3daed1d507038046c0355fbafb85260c |
|
05-Jun-2014 |
Gilad Arnold <garnold@chromium.org> |
Change ErrorCode into an enum class. This change is needed in order for us to be able to import ErrorCode symbols from chromeos_update_engine into chromeos_update_manager. Unfortunately, shifting from plain 'enum' into an 'enum class' means that the compiler treats the new class as a distinct type from int, which in turn means that plenty of seamless arithmetic/bitwise operations we used for manipulating error code values throughout the code needed to be retrofitted with static_cast operators. In the future, we should consider imposing a proper abstraction on update engine error codes that'll prevent mingling with value encoding directly and prevent such nastiness. It'll also make things more coherent (types, semantics) and safer. BUG=chromium:358329 TEST=Unit tests. Change-Id: Ie55fa566b764cdab6c4785d995fb6daee4cb32d3 Reviewed-on: https://chromium-review.googlesource.com/203209 Tested-by: Gilad Arnold <garnold@chromium.org> Reviewed-by: Alex Deymo <deymo@chromium.org> Commit-Queue: Gilad Arnold <garnold@chromium.org>
/system/update_engine/omaha_response_handler_action.cc
|
77f79e876a77796fc248d099b6574f05bd23c954 |
|
03-Jun-2014 |
Chris Sosa <sosa@chromium.org> |
Only disable update downloads over expensive connections, not all transfers. Previous to this CL, all network traffic was disabled from the update engine if an update wasn't allowed. Instead, in this CL, we switch to only disable the update application portion (downloading and applying the payload). This is done by moving the detection logic from the mechanism (the network fetcher) to the user of said mechanism i.e. the omaha request/response actions. I have done a little refactoring of the unittests to make this CL easier to test and found 1 bug in the http_fetcher_unittests where we weren't sending either the right URL or handling a server not existing correctly. This CL comes with one caveat: Technically in the previous impl if a download started over wifi then got disconnected / retried and bounced to a different connection type that we couldn't update over, we'd stop the update. This would no longer be true here if the http_fetcher recovered seamlessly. BUG=chromium:379832 TEST=Unittests Change-Id: I6b1a76e4c030d4e384e8ba0b519424a35406aafb Reviewed-on: https://chromium-review.googlesource.com/202435 Tested-by: Chris Sosa <sosa@chromium.org> Reviewed-by: David Zeuthen <zeuthen@chromium.org> Commit-Queue: Chris Sosa <sosa@chromium.org>
/system/update_engine/omaha_response_handler_action.cc
|
1f84723f499b3b309efac11324ed4e6c937341b6 |
|
07-Apr-2014 |
Gilad Arnold <garnold@chromium.org> |
Revise the SystemState hierarchy. * Removed all #includes from SystemState; added includes in .cc files that use the various objects (MetricsLibrary, DevicePolicy, etc). * MockSystemState: - Regulated the set of getters/setters: foo() returns the current Foo object interface; this object can be overridden by set_foo(); mock_foo() or fake_foo() returns the default (internal) mock/fake equivalent, and fails if it is different from foo() (safety). - Make member declaration order consistent with that of API. - Removed MOCK_METHOD declarations for two methods and replaced them with fake getter/setter. This means that MockSystemState is now reduced to a fake, and can be renamed (separate CL). This also means that a few tests have a slightly different semantics now. * All virtual overrides are qualified as such. However, removed the 'const' method qualified from all getters: it made little sense, especially when considering that getters are handing addresses of internal mock members. * Made the UpdateAttempter a contained member of both {Real,Mock}SystemState, resolving initialization dependencies. In general, the invariant is that all members of the SystemState that rely on it being fully populated by the time of their initialization, need to export a separate Init() method, that will be called (by the SystemState implementation constructor or Init() method) only after all members are set. * Made the mock GPIO handler and connection manager contained members of MockSystemState; the destructor could safely be moved. * Cleanup in UpdateAttempter (part of resolving dependencies): - Ordinary member initialization done via default initializers (constants) or initializer list in the constructor (parameters). - Init() method only does work that cannot be done during construction, with appropriate comment documenting the need for it. - Better reuse via constructor delegation. BUG=chromium:358278 TEST=Unit tests. Change-Id: I96ff6fc7e7400b0a9feb6cc8d4ffe97a51000f91 Reviewed-on: https://chromium-review.googlesource.com/193587 Reviewed-by: Gilad Arnold <garnold@chromium.org> Tested-by: Gilad Arnold <garnold@chromium.org> Commit-Queue: David Zeuthen <zeuthen@chromium.org>
/system/update_engine/omaha_response_handler_action.cc
|
75039d7397f03dff77bdf4e26398049ff88edc4c |
|
25-Mar-2014 |
Alex Vakulenko <avakulenko@chromium.org> |
update_engine: update to libbase 242728 Made update_engine link with libchrome-242728 and fixed compile issues due to changes in namespaces and include file layout. Also removed some of suppressed compiler warnings and fixed the issues masked by them (e.g. mismatched printf-like specifiers). Added -Wextra compiler option to enable additional useful warnings to ensure more strict checking... Had to disable "unused-parameter" though since we have a lot of functions (mainly in fakes) that do not use all of their parameters. BUG=chromium:351593 TEST=Unit tests passed. CQ-DEPEND=CL:191721 Change-Id: I1aa63a48d5f1f4ea75ba6b00aec7aa5f3bad15c4 Reviewed-on: https://chromium-review.googlesource.com/191510 Reviewed-by: Alex Vakulenko <avakulenko@chromium.org> Commit-Queue: Alex Vakulenko <avakulenko@chromium.org> Tested-by: Alex Vakulenko <avakulenko@chromium.org>
/system/update_engine/omaha_response_handler_action.cc
|
bc27aace82f59884bd3f2d37064644037ccccfc2 |
|
26-Nov-2013 |
David Zeuthen <zeuthen@chromium.org> |
Add comment about log messages checked in autoupdate_CatchBadSignatures. This is helpful when refactoring to avoid the newly added autoupdate_CatchBadSignatures test failing. BUG=chromium:264352 TEST=None (no code change.) Change-Id: I9da0060ef99d85eaf6454c594decc0db2f6bcafd Reviewed-on: https://chromium-review.googlesource.com/178103 Reviewed-by: Chris Sosa <sosa@chromium.org> Commit-Queue: David Zeuthen <zeuthen@chromium.org> Tested-by: David Zeuthen <zeuthen@chromium.org>
/system/update_engine/omaha_response_handler_action.cc
|
e7f8917f378773fbfee0b2d21f1cb6b3ba8bdcab |
|
31-Oct-2013 |
David Zeuthen <zeuthen@chromium.org> |
Add support for using public key sent by Omaha. This adds support for Omaha to specify what RSA public to use for verifying both the metadata hash signature and the payload itself. For security reasons, we only allow this for non-official builds e.g. for official builds we keep using the key stored on the root file-system. Also, if the key is specified in the Omaha response then we make hash checks mandatory; e.g. if the signatures don't check out, fail the update. See CL:175283 for the devserver changes to transmit the public key and signed metadata hash. BUG=chromium:264352 TEST=New unit tests + unit tests pass + manual testing. Change-Id: I709be02662a484c6284bb78683b973554e482928 Reviewed-on: https://chromium-review.googlesource.com/175285 Reviewed-by: Don Garrett <dgarrett@chromium.org> Commit-Queue: David Zeuthen <zeuthen@chromium.org> Tested-by: David Zeuthen <zeuthen@chromium.org>
/system/update_engine/omaha_response_handler_action.cc
|
056b0abc1273a6eebfd73060a1d0344ef02b8696 |
|
29-Oct-2013 |
J. Richard Barnette <jrbarnette@chromium.org> |
Move IsOfficialBuild() and IsNormalBootMode() into HardwareInterface. This makes the implementation of the two methods part of the HardwareInterface, so that unit tests won't end up with meaningless (and unpredictable) calls to the real functions. BUG=None TEST=unit tests Change-Id: Ia23932634124987c1d6ff0683acb15cf4819bc5e Reviewed-on: https://chromium-review.googlesource.com/175024 Reviewed-by: Chris Sosa <sosa@chromium.org> Commit-Queue: Richard Barnette <jrbarnette@chromium.org> Tested-by: Richard Barnette <jrbarnette@chromium.org>
/system/update_engine/omaha_response_handler_action.cc
|
308429363870cf92a74a60ae8a645aa60b1a3a64 |
|
28-Oct-2013 |
J. Richard Barnette <jrbarnette@chromium.org> |
Move KernelDeviceOfBootDevice() to utils. The function to construct the kernel partition block device from its corresponding boot device uses only string manipulations, and doesn't operate on the underlying hardware. This removes the function from HardwareInterface, in favor of utils. BUG=None TEST=unit tests Change-Id: I94b2c477413c4b484045a696f0ffbc77d9853195 Reviewed-on: https://chromium-review.googlesource.com/174913 Commit-Queue: Richard Barnette <jrbarnette@chromium.org> Tested-by: Richard Barnette <jrbarnette@chromium.org> Reviewed-by: Chris Sosa <sosa@chromium.org>
/system/update_engine/omaha_response_handler_action.cc
|
b3dcdb309615b8ec280584319f37b187924b6694 |
|
05-Sep-2013 |
Chris Sosa <sosa@chromium.org> |
Load the and store rollback version into the correct variable. Somehow missed this and added unittest to help never have this issue again. In this CL I also got rid of the powerwash_prefs_ logic in GetPersistedValue because it was just useless noise in my prev CL that isn't used anymore. BUG=chromium:285381 TEST=unittests that actually catch error. Change-Id: I4ed680c5b5c2e37549d58aa0a7c0d35a62623fe7 Reviewed-on: https://chromium-review.googlesource.com/168073 Tested-by: Chris Sosa <sosa@chromium.org> Reviewed-by: David Zeuthen <zeuthen@chromium.org> Commit-Queue: Chris Sosa <sosa@chromium.org>
/system/update_engine/omaha_response_handler_action.cc
|
bb8bdc7dd7e54afe181045cc17d5a0dbde99739b |
|
03-Sep-2013 |
David Zeuthen <zeuthen@chromium.org> |
p2p: Add HttpPeer to DownloadSource enumeration This way the Installer.DownloadSourcesUsed metric conveys how often p2p is used and new metrics Installer.SuccessfulMBsDownloadedFromHttpPeer and Installer.TotalMBsDownloadedFromHttpPeer gives additional detail. BUG=chromium:284714 TEST=modify unit tests to cover this case + unit tests pass Change-Id: Ia4dff090091a282e1a184c2b18f8290749f5fdeb Reviewed-on: https://chromium-review.googlesource.com/167913 Reviewed-by: Alex Deymo <deymo@chromium.org> Commit-Queue: David Zeuthen <zeuthen@chromium.org> Tested-by: David Zeuthen <zeuthen@chromium.org>
/system/update_engine/omaha_response_handler_action.cc
|
8f191b22a1a1ab2b803d65ee488729206e648695 |
|
06-Aug-2013 |
David Zeuthen <zeuthen@chromium.org> |
p2p: Use p2p for updates This is the main patch for enabling use of p2p for consuming and/or sharing updates via p2p. Refer to the ddoc and other documentation for how this works. BUG=chromium:260426,chromium:273110 TEST=New unit tests + unit tests pass + manual testing Change-Id: I6bc3bddae1e041ccc176969a651396e8e89cb3f0 Reviewed-on: https://chromium-review.googlesource.com/64829 Reviewed-by: David Zeuthen <zeuthen@chromium.org> Commit-Queue: David Zeuthen <zeuthen@chromium.org> Tested-by: David Zeuthen <zeuthen@chromium.org>
/system/update_engine/omaha_response_handler_action.cc
|
fb1020e30511825c1c39f3764f07ef237a6f668e |
|
30-Jul-2013 |
Chris Sosa <sosa@chromium.org> |
Add version information to install plan and GetStatus. As per the TODO this information is useful for debugging and testing changes i.e. I'd like to know what version I'm updating to. GetStatus already supports getting this version but we never populate the field. BUG=chromium:264505 TEST=Unittests + ran update_engine_client -update which uses GetStatus to communicate status. Change-Id: I5332e2f206d92aedba509cd5469e9610c88bcd03 Reviewed-on: https://gerrit.chromium.org/gerrit/63675 Commit-Queue: Chris Sosa <sosa@chromium.org> Reviewed-by: Chris Sosa <sosa@chromium.org> Tested-by: Chris Sosa <sosa@chromium.org>
/system/update_engine/omaha_response_handler_action.cc
|
4243291a6655972fe89d4747a0089834c9e47c20 |
|
13-Jul-2013 |
Alex Deymo <deymo@chromium.org> |
Send an UMA metric when failed to boot into the new partition. When a payload is successfully applied, the /other/ partition is marked as valid and a reboot is needed, the reboot into this new partition can fail due to several reasons. If than happens, the firmware can rollback to the previous partition. When this happens, this fix sends a new UMA metric with the attempt number of this failing payload. In order to test this functionality we need to fake the utils::BootDevice() to emulate a reboot into the same or a different partition. To achieve this, this function is moved to a new "HardwareInterface" that can be faked using the FakeHardware class that can hold similar hardware related functions. Implementations and unittest were refactored as needed. BUG=chromium:243572 TEST=unittests Change-Id: I1a4242df0bd61e2718ab881ead603b1d3705b877 Reviewed-on: https://gerrit.chromium.org/gerrit/61815 Commit-Queue: Alex Deymo <deymo@chromium.org> Reviewed-by: Alex Deymo <deymo@chromium.org> Tested-by: Alex Deymo <deymo@chromium.org>
/system/update_engine/omaha_response_handler_action.cc
|
4dbd47eb03169faac44fce86daffef10cac94b7d |
|
22-Jul-2013 |
Gilad Arnold <garnold@chromium.org> |
AU/unittest: fix to OmahaResponseHandlerAction unit tests The said class uses a fixed named file for communicating data (in this case, a deadline marker) to Chrome, which causes unit tests to fail when run in parallel. This change makes this file parametric for testing purposes, allowing the tests to be run in parallel. Note that we only override the file name for tests that actually examine the file. For other invocations there may still be race conditions when writing to the marker file, but they should not affect the outcome of the tests. BUG=chromium:236465 TEST=Tests successful Change-Id: Ieb2a3ef1b4d9c5d5d2e06cf8e281eb832b2a9ff8 Reviewed-on: https://gerrit.chromium.org/gerrit/62825 Tested-by: Gilad Arnold <garnold@chromium.org> Reviewed-by: Chris Sosa <sosa@chromium.org> Commit-Queue: Gilad Arnold <garnold@chromium.org>
/system/update_engine/omaha_response_handler_action.cc
|
aa18e1641879f2df5993c2b02eb6f50d4443a649 |
|
20-Jun-2013 |
Chris Sosa <sosa@chromium.org> |
Blacklist versions as part of Rollback along with unittests. This CL adds version blacklisting as part of AU Rollback. A few additional things: 1) Since this pref must persist across rollback I have introduced a powerwash_safe_prefs as part of system_state that will persist across powerwashes. 2) Fixed bug where we needed to read the device policy (which is read during an update_check before Rollback would work). 3) Some refactoring to move pref constants to constants. 4) Passing keepimg into our powerwash command so we don't wipe the old partitions. BUG=chromium:252589 chromium:254217 TEST=Unittests + test on device + using rollback with and without powerwash checking preserve state. Change-Id: I991fad944594944425fd9941e10b30a919f2b83b Reviewed-on: https://gerrit.chromium.org/gerrit/59518 Reviewed-by: Chris Sosa <sosa@chromium.org> Tested-by: Chris Sosa <sosa@chromium.org> Commit-Queue: Chris Sosa <sosa@chromium.org>
/system/update_engine/omaha_response_handler_action.cc
|
d317e40be46e1b69f624a8165472c99fe6346a1e |
|
12-Jun-2013 |
Chris Sosa <sosa@chromium.org> |
Implement Rollback to previously booted partitions. This CL implements rollback to whatever partition we ran from before. We expose this functionality via dbus under AttemptRollback and expose a new command-line option to update_engine_client that a developer can use. BUG=chromium:242665 TEST=Unittests, full update, update + rollback and verified. Change-Id: Ie59f90b9a0b777dc1329592449090c70892236bf Reviewed-on: https://gerrit.chromium.org/gerrit/58427 Commit-Queue: Chris Sosa <sosa@chromium.org> Reviewed-by: Chris Sosa <sosa@chromium.org> Tested-by: Chris Sosa <sosa@chromium.org>
/system/update_engine/omaha_response_handler_action.cc
|
21504f0a591cd15a894cad6a6a3aba44673cbf90 |
|
24-May-2013 |
Gilad Arnold <garnold@chromium.org> |
Revert "Revert "AU: do not copy filesystem during full updates"" This reverts commit d1cd325c3135d88498483da811b594ba6b91ce42 The problem that caused all autotests to fail with the original CL has now been rectified; lab devservers were updated to send the correct delta flag in their omaha response. Change-Id: I664afb33f72856572baaa658cbd473c07271af36 Reviewed-on: https://gerrit.chromium.org/gerrit/56600 Reviewed-by: Gilad Arnold <garnold@chromium.org> Tested-by: Gilad Arnold <garnold@chromium.org> Commit-Queue: Gilad Arnold <garnold@chromium.org>
/system/update_engine/omaha_response_handler_action.cc
|
d1cd325c3135d88498483da811b594ba6b91ce42 |
|
23-May-2013 |
Don Garrett <dgarrett@chromium.org> |
Revert "AU: do not copy filesystem during full updates" This reverts commit 81c90628abb268c9e54f655c2493b4495b5cf91e This broke all of the Canaries with NPO update tests. It may be because devserver changes require manual staging into the autotest framework. An example test: http://cautotest/afe/#tab_id=view_job&object_id=3064976 Test Logs: https://storage.cloud.google.com/?arg=chromeos-autotest-results/3064976-chromeos-test/chromeos2-row5-rack1-host9/debug#chromeos-autotest-results%2F3064976-chromeos-test%2Fchromeos2-row5-rack1-host9%2Fautoupdate_EndToEndTest.npo_test_delta%2Fsysinfo%2Fvar%2Flog_diff%2Fupdate_engine UE Logs: [0522/183224:INFO:chrome_browser_proxy_resolver.cc(168)] dbus_g_proxy_call succeeded! [0522/183224:INFO:libcurl_http_fetcher.cc(63)] Starting/Resuming transfer [0522/183224:INFO:libcurl_http_fetcher.cc(74)] Using proxy: no [0522/183224:INFO:libcurl_http_fetcher.cc(52)] We are connected via ethernet, Updates allowed: Yes [0522/183224:INFO:libcurl_http_fetcher.cc(180)] Not setting http(s) curl options because we are in test mode or running a dev/test image [0522/183224:INFO:libcurl_http_fetcher.cc(485)] Setting up timeout source: 1 seconds. [0522/183224:INFO:delta_performer.cc(104)] Completed 0/? operations, 15677/681963 bytes downloaded (2%), overall progress 1% [0522/183224:WARNING:delta_performer.cc(327)] Ignoring missing/incorrect metadata size (0) in Omaha response as validation is not mandatory. Trusting metadata size in payload = 1410 [0522/183224:INFO:utils.cc(824)] Sending error code 32 (kErrorCodeDownloadInvalidMetadataSize) to UMA metric: Installer.DevModeErrorCodes. Flags = TestOmahaUrl, TestImage [0522/183224:WARNING:delta_performer.cc(791)] Cannot validate metadata as the signature is empty [0522/183224:INFO:utils.cc(824)] Sending error code 39 (kErrorCodeDownloadMetadataSignatureMissingError) to UMA metric: Installer.DevModeErrorCodes. Flags = TestOmahaUrl, TestImage [0522/183224:ERROR:delta_performer.cc(852)] Purported full payload contains old partition hash(es), aborting update [0522/183224:ERROR:download_action.cc(102)] Error 6 in DeltaPerformer's Write method when processing the received payload -- Terminating processing [0522/183224:INFO:delta_performer.cc(216)] Discarding 15677 unused downloaded bytes [0522/183224:INFO:update_attempter.cc(724)] Download status: inactive [0522/183224:INFO:multi_range_http_fetcher.cc(155)] Received transfer terminated. [0522/183224:INFO:multi_range_http_fetcher.cc(107)] TransferEnded w/ code 200 [0522/183224:INFO:multi_range_http_fetcher.cc(109)] Terminating. [0522/183224:INFO:prefs.cc(27)] delta-update-failures not present in /var/lib/update_engine/prefs [0522/183224:INFO:action_processor.cc(68)] ActionProcessor::ActionComplete: DownloadAction action failed. Aborting processing. [0522/183224:INFO:action_processor.cc(73)] ActionProcessor::ActionComplete: finished last action of type DownloadAction [0522/183224:INFO:update_attempter.cc(578)] Processing Done. [0522/183224:INFO:utils.cc(673)] Setting cgroup cpu shares to 1024 [0522/183224:INFO:update_attempter.cc(963)] CPU shares = 1024 [0522/183224:ERROR:update_attempter.cc(934)] Update failed. Change-Id: I69d3b93711707d9429201865346fd50117338718 Reviewed-on: https://gerrit.chromium.org/gerrit/56351 Commit-Queue: Don Garrett <dgarrett@chromium.org> Reviewed-by: Don Garrett <dgarrett@chromium.org> Tested-by: Don Garrett <dgarrett@chromium.org>
/system/update_engine/omaha_response_handler_action.cc
|
81c90628abb268c9e54f655c2493b4495b5cf91e |
|
25-Jan-2013 |
Gilad Arnold <garnold@chromium.org> |
AU: do not copy filesystem during full updates The filesystem copying stage is redundant during full updates, where the partition is being entirely overwritten regardless of its previous content. It is also a very wasteful step, causing intensive I/O and kernel buffer pressure, and known to (sometimes) cause jank and otherwise have detrimental effects on our user experience. This CL eliminates filesystem copying for full updates: 1) The decision is based on whether the Omaha response indicates that this is a full update. 2) To be safe, we also ensure that the payload manifest does not contain old partition hashes, which is indicative of a delta update. Note that it is generally desirable to base the decision solely on #2 above (and ignore #1 altogether). However, this will require more extensive re-engineering of the update flow, as filesystem copying currently happens prior to the manifest being downloaded. BUG=chromium:189855 TEST=Full and delta updates run correctly on x86-alex Change-Id: Ic0dc6e32913cfb96019606624ec6b87c2e5b3ebb Reviewed-on: https://gerrit.chromium.org/gerrit/43665 Commit-Queue: Gilad Arnold <garnold@chromium.org> Reviewed-by: Gilad Arnold <garnold@chromium.org> Tested-by: Gilad Arnold <garnold@chromium.org>
/system/update_engine/omaha_response_handler_action.cc
|
53173b964f6f43c89dbaba41875fcadd7077b2ea |
|
18-May-2013 |
Jay Srinivasan <jaysri@chromium.org> |
Download via HTTP only if enterprise policy allows. In order to rollout HTTP-downloads for AU to stable channel, we want to be a bit more conservative to preseve the defense in depth we have now with HTTPS. So, we're introduced a new enterprise policy which should be explicitly enabled in order for the payloads to be downloaded via HTTP. This CL adds the support for honoring such a policy in update engine. BUG=chromium:235562 TEST=New unit tests added, existing ones updated and they all pass. TEST=Tested on ZGB with and without policy and it works as expected. Change-Id: I356efbe237b10031161a57c70cb851c521915a76 Reviewed-on: https://gerrit.chromium.org/gerrit/55805 Reviewed-by: Chris Sosa <sosa@chromium.org> Tested-by: Jay Srinivasan <jaysri@chromium.org> Commit-Queue: Jay Srinivasan <jaysri@chromium.org>
/system/update_engine/omaha_response_handler_action.cc
|
a99981fda75fe0b17e96c700e3ddc93eca1cebe5 |
|
29-Apr-2013 |
David Zeuthen <zeuthen@chromium.org> |
Rename ActionExitCode to ErrorCode Nowadays ActionExitCode is used throughout the codebase so use a more generic name to reflect this. BUG=chromium:216507 TEST=unit tests pass Change-Id: I23d1d7e2676443251dbc42ed137fd018aadfa8a3 Reviewed-on: https://gerrit.chromium.org/gerrit/49512 Reviewed-by: Don Garrett <dgarrett@chromium.org> Commit-Queue: David Zeuthen <zeuthen@chromium.org> Tested-by: David Zeuthen <zeuthen@chromium.org>
/system/update_engine/omaha_response_handler_action.cc
|
be45bef9e283188b00e7def8967f81843669a7f1 |
|
10-Apr-2013 |
Chris Sosa <sosa@chromium.org> |
Add update reboot metric to the update engine. This change add the Installer.UpdateNumReboots metric. This records the number of reboots that occurred while an update was being attempted. It uses a marker file stored in tmp to discover whether or not it's already recorded the reboot. BUG=chromium:226766 TEST=Unittests | ran an update on a test machine and rebooted/resumed and checked about:histograms to confirm numbers. Also restart update-engine to verify it didn't double count that. Change-Id: I5d2af9d5b62a9d974c7c6243a89cb3359051b650 Reviewed-on: https://gerrit.chromium.org/gerrit/47710 Tested-by: Chris Sosa <sosa@chromium.org> Commit-Queue: Chris Sosa <sosa@chromium.org> Reviewed-by: Chris Sosa <sosa@chromium.org>
/system/update_engine/omaha_response_handler_action.cc
|
19409b74019d787100b768306e75ab3e5882898d |
|
13-Apr-2013 |
Jay Srinivasan <jaysri@chromium.org> |
Add metrics to report the number of bytes downloaded per protocol. This CL adds these two basic metrics: 1. The number of megabytes downloaded using each protocol (or source in general, as we want to consider HTTP downloads from server and possibly a peer in future as two different sources) for each successful update. The totals across all protocols will equal the payload size exactly. 2. The total number of megabytes downloaded since the last update attempt. If there are no errors, this should be same as above. Otherwise, this will be larger and will help us to compute the update efficiency. BUG=chromium:225953 TEST=Unit tests pass, new Unit tests added. TEST=chrome://histograms shows metrics correctly. Change-Id: Ic02e218f46568427df99a8a9df2011860aee84f3 Reviewed-on: https://gerrit.chromium.org/gerrit/48069 Reviewed-by: Chris Sosa <sosa@chromium.org> Commit-Queue: Jay Srinivasan <jaysri@chromium.org> Tested-by: Jay Srinivasan <jaysri@chromium.org>
/system/update_engine/omaha_response_handler_action.cc
|
d29695df35b7192faef4009d42a62c37bdd90a8f |
|
09-Apr-2013 |
Jay Srinivasan <jaysri@chromium.org> |
Refactoring: Move prefs constants out to the constants.h/cc Adding/removing the set of keys used by various parts of the Update Engine code does not affect the implementation of the prefs module, hence separating them. BUG=chromium:229090 TEST=Unit tests pass. Change-Id: Id774b726a47b461e563e2e413527054e4da0c012 Reviewed-on: https://gerrit.chromium.org/gerrit/47593 Reviewed-by: Gilad Arnold <garnold@chromium.org> Tested-by: Jay Srinivasan <jaysri@chromium.org> Commit-Queue: Jay Srinivasan <jaysri@chromium.org>
/system/update_engine/omaha_response_handler_action.cc
|
1c0fe79c7ef2b43946d756b54c8505d2bf48b93b |
|
29-Mar-2013 |
Jay Srinivasan <jaysri@chromium.org> |
Cancel the current download if user chooses a different channel. In my earlier CL, to keep the implementation simple, we disallowed changing a channel until the previous change completed in its entirety. Given that the UI is not going to be updated for M27, such a restriction turned out to be very confusing when playing around with channel changing. So, we decided to implement a simple form of canceling the download if the user selected a different channel while we're downloading the bits. This implementation can easily be extended to support a general form of cancel in the future, if required. This CL also adds validation of libchromeos API calls when interpreting the policy values. It also cleans up some bogus error messages that were logged earlier when we abort a download. BUG=chromium:222617 TEST=All scenarios pass on ZGB. Unit Tests pass. Change-Id: I7cd691fe461d9ce47314299f6e2598944650ee33 Reviewed-on: https://gerrit.chromium.org/gerrit/46095 Commit-Queue: Jay Srinivasan <jaysri@chromium.org> Reviewed-by: Jay Srinivasan <jaysri@chromium.org> Tested-by: Jay Srinivasan <jaysri@chromium.org>
/system/update_engine/omaha_response_handler_action.cc
|
ae4697c073b84b260990a141acd53c6806da0708 |
|
19-Mar-2013 |
Jay Srinivasan <jaysri@chromium.org> |
Enhanced channel changing behavior This CL adds a new DBUS API to UpdateEngine called SetTargetChannel to change the current channel of the device with an option to indicate whether to do eventually or immediately. The API will be called with the option to do it immediately in a subsequent CL in Chrome UI. For now the old API (set_track) has been wired up to call the new API to produce the old behavior (i.e. change eventually). The old API will be removed after Chrome UI code stops using it. It's the UI's responsibility to ask the user for confirmation for the powerwash that may happen in some cases and call the API with the appropriate value whether or not the powerwash should happen. For now, we're restricting the changing of channels to only those devices that are on canary-channel or running test builds. This restriction will be lifted off once the UI work is ready to give warning to the users about the powerwash that may happen when they move to a more stable channel. We also enforce ReleaseChannelDelegated and ReleaseChannel policies correctly now as follows: * If ReleaseChannelDelegated is false, SetTargetChannel will fail as we need to honor (only) the ReleaseChannel value in this case. * If ReleaseChannelDelegated is true, we'll allow the SetTargetChannel call to specify. In this case, we'll ignore the value of ReleaseChannel, if any. BUG=chromium-os:39095 TEST=Tested on ZGB by going from canary to dev-channel with and without powerwash. TEST=Existing unit tests have been updated and they pass. TEST=New unit tests have been added. Change-Id: Ifbf806a06e1c30d2f318e94d73735d1812049abd Reviewed-on: https://gerrit.chromium.org/gerrit/44619 Commit-Queue: Jay Srinivasan <jaysri@chromium.org> Reviewed-by: Jay Srinivasan <jaysri@chromium.org> Tested-by: Jay Srinivasan <jaysri@chromium.org>
/system/update_engine/omaha_response_handler_action.cc
|
55f50c24c2624487b803ba2f93588494cc69e523 |
|
11-Jan-2013 |
Jay Srinivasan <jaysri@chromium.org> |
Segregate UMA metrics for production scenarios from test scenarios. Currently we separate the UMA metrics only by one category: whether the device is in dev mode or not. In addition, we need to exclude the noise from these two categories: 1. Most of our testing on MP-signed images which are performed with autest. 2. All our hwlab tests run in non-dev mode but they use dev-signed images with dev-firmware keys. So this CL defines additional bit fields to represent these states and if any of these three flags are set, the UMA metric is sent to a DevModeErrorCodes bucket. Thus the NormalErrorCodes bucket will have only the production errors and thus we can monitor more effectively. BUG=chromium-os:37613 TEST=Updated unit tests, ran on ZGB for all scenarios. Change-Id: Id9cce33f09d1cc50cb15e67c731f7548940cbc24 Reviewed-on: https://gerrit.chromium.org/gerrit/41103 Reviewed-by: Chris Sosa <sosa@chromium.org> Commit-Queue: Jay Srinivasan <jaysri@chromium.org> Tested-by: Jay Srinivasan <jaysri@chromium.org>
/system/update_engine/omaha_response_handler_action.cc
|
6f6ea00aa8c4cf54b6842be32ca1226854c24f78 |
|
14-Dec-2012 |
Jay Srinivasan <jaysri@chromium.org> |
Support for processing multiple URLs in update_engine. Main changes: 1. Added a new PayloadState class which encapsulates all the persisted state we use for multiple URLs, back-off (TBD), etc. 2. Added support for handling multiple URLs stored in the OmahaResponse in OmahaRequestAction and OmahaResponseHandlerAction code. 3. Added support for picking the right URL in OmahaResponseHandlerAction and putting it in the install_plan. This way, the rest of the code that uses the install_plan is oblivious to the presence of multiple URLs :-) 4. Added support for advancing to next URL when an update fails. The full error classification is a new work item (chromium-os:37206). Right now, it's a basic round-robin on every error. 5. Updated the conditions for determining when hash checks are mandatory. Previously since there was only one URL, if it was HTTPS, the checks were waived. Now, even if there's one HTTP URL, we make hash checks mandatory even if other HTTPS URLs are present. 6. Added new unit tests for PayloadState and the new logic added to other places. Noisy changes: 1. Instead of passing PrefsInterface to OmahaRequestAction and OmahaResponseHandlerAction, we're now passing SystemState which will now contain PrefsInterface and the newly added PayloadState object that these actions need to do their work. 2. Renamed a bunch of setters/getters to set_x() and x() instead of SetX() and GetX() methods - this was pending from Gilad's old CR. As I'm adding new methods in the correct style, I went ahead and fixed it to avoid the confusing styles. 3. Updated all existing unit tests to reflect these changes. BUG=chromium-os:36807 TEST=All Single/Multiple URL scenarios work fine on my ZGB as expected. TEST=Old and new unit tests run fine. Change-Id: Id31f9ccb220471f3ec3a475f624dc03c16119144 Reviewed-on: https://gerrit.chromium.org/gerrit/39638 Commit-Ready: Jay Srinivasan <jaysri@chromium.org> Reviewed-by: Jay Srinivasan <jaysri@chromium.org> Tested-by: Jay Srinivasan <jaysri@chromium.org>
/system/update_engine/omaha_response_handler_action.cc
|
738fdf37c15284b60dac703408b8de19eef9c6a3 |
|
08-Dec-2012 |
Jay Srinivasan <jaysri@chromium.org> |
Make hash checks mandatory for HTTP downloads. Currently we've made all the checks for metadata size, metadata signature and operation hashes as optional. While they are still optional if we use HTTPS for downloading the payload, we want to make them mandatory in case of HTTP, so as to support HTTP downloads. In this CL, we make these checks mandatory if the Omaha response has a HTTP URL. This will not affect any scenarios of our test team because they always use HTTPS URLs for payload URLs. But this would break the dev tools and our hardware test lab scenarios because they use HTTP URLs and do not generate the required manifest signature yet. So we waive this requirement for dev/test images even though they use HTTP. This CL will not have any effect until we decide to add a HTTP rule in Omaha, which serves as a safety knob till we are confident with our testing. BUG=chromium-os:36808 TEST=Existing unit tests pass. Added new unit tests for most new code. TEST=Ran manual tests on ZGB for every type of hash failure for HTTP. TEST=Tested image_to_live to make sure hash checks are waived as expected. Change-Id: I8c4408e3052635ccf4bee0c848781733c1f8e984 Reviewed-on: https://gerrit.chromium.org/gerrit/39293 Reviewed-by: Gaurav Shah <gauravsh@chromium.org> Commit-Ready: Jay Srinivasan <jaysri@chromium.org> Reviewed-by: Jay Srinivasan <jaysri@chromium.org> Tested-by: Jay Srinivasan <jaysri@chromium.org>
/system/update_engine/omaha_response_handler_action.cc
|
f4318709ff5bd808a5fb8dd360acd9b66253a24e |
|
24-Sep-2012 |
Jay Srinivasan <jaysri@chromium.org> |
Support needed for generating metadata signature in paygen The metadata is the first portion of a payload that contains the following: 1. magic string ("CrOS") 2. version number 3. length of the manifest protobuf 4. manifest protobuf itself <payload blobs begin here> <payload signature as the last blob> Currently we have a manifest signature which protects only #4 above. In this CL we're extending the scope of manifest signature to include the rest of the metadata (1-4). The reason we need to do this is to protect the version value in HTTP as we're going to use it in future to have the flexibility to change the protobuf format of the manifest. Besides this change, this CL also contains: 1. Renaming of manifest_size and manifest_signature to metadata_size and metadata_signature respectively to reflect the above change and keep consistent terminology throughout. Also it renames protobuf_offset and protobuf_length to manifest_offset and manifest_size to increase the contextual semantics of the protobuf. 2. Addition of a new command-line option --out_metadata_hash_file in delta_generator so that au_generate can use it in a subsequent CL to get the SHA256 hash of the payload metadata in order to get it signed with the signer. 3. Reusing LoadPayload in unit tests to get rid of some hardcoding. Also updated delta_performer to localize such hardcoded constants within that class and not have callers worry about those values. BUG=chromium-os:33603 TEST=Tested on ZGB. Reran existing unit tests. Change-Id: Iace5aebe8f7d054a0fa3a224a588ef52d85f510b Reviewed-on: https://gerrit.chromium.org/gerrit/33726 Commit-Ready: Jay Srinivasan <jaysri@chromium.org> Reviewed-by: Jay Srinivasan <jaysri@chromium.org> Tested-by: Jay Srinivasan <jaysri@chromium.org>
/system/update_engine/omaha_response_handler_action.cc
|
51dcf260754837962dd22db3b7babee181471e7d |
|
14-Sep-2012 |
Jay Srinivasan <jaysri@chromium.org> |
Verify AU payload manifest signature if present. In order to support downloads over http for a number of reasons, we need to secure http downloads. The first step in this process is to verify the signature of the manifest itself before parsing. This can be done even for https-based downloads in order to provide defense-in-depth against a SSL attack. This CL adds the required verification logic in update_engine, if such a manifest signature is present in the Omaha response. Until the delta generator is modified in a subsequent check-in to update the manifest and payload with the required signature, none of this new code will have any effect. The delta generator change to populate non-zero values for these new fields will follow in subsequent CLs. BUG=chromium-os:33602 TEST=Tested on ZGB to make sure existing functionality works fine. Added new unit tests. Change-Id: I2d8b09c23faf87049893b1dee97a34e1f300aded Reviewed-on: https://gerrit.chromium.org/gerrit/32844 Commit-Ready: Jay Srinivasan <jaysri@chromium.org> Reviewed-by: Jay Srinivasan <jaysri@chromium.org> Tested-by: Jay Srinivasan <jaysri@chromium.org>
/system/update_engine/omaha_response_handler_action.cc
|
7ed561bfe6019ed4b988142e97505d7c643e119c |
|
04-Oct-2011 |
Darin Petkov <petkov@chromium.org> |
AU: Remove support for old-style updates. This code is basically untested, unused and a security risk. So, remove... BUG=chromium-os:12542 TEST=unit tests, tested VM update Change-Id: Ibed0582b09497acef9debdf88658cddc2b5cecce Reviewed-on: http://gerrit.chromium.org/gerrit/8728 Tested-by: Darin Petkov <petkov@chromium.org> Reviewed-by: Andrew de los Reyes <adlr@chromium.org> Commit-Ready: Darin Petkov <petkov@chromium.org>
/system/update_engine/omaha_response_handler_action.cc
|
abc7bc0f5d88f110b463191bb8384f95d3c4230a |
|
23-Feb-2011 |
Darin Petkov <petkov@chromium.org> |
If a public key is present, disallow old style full payloads. This is necessary to ensure that if a public key is present the payload is signed and the signature passes verification. BUG=chromium-os:11760 TEST=unit tests, tested on device Change-Id: I6af61ead0e918c0b971dbcfeabcab3be03e6eb97 Review URL: http://codereview.chromium.org/6574009
/system/update_engine/omaha_response_handler_action.cc
|
6c11864907e9a92f8069c77c08650102e0b34e0d |
|
21-Oct-2010 |
Darin Petkov <petkov@chromium.org> |
AU: propagate a deadline form the update check response to Chrome. Currently, this is done through the file system. BUG=3284 TEST=unit tests Change-Id: I0e579ef6ccd7832ca22a248e71f2689c27159056 TBR=resubmitting due to git issues
/system/update_engine/omaha_response_handler_action.cc
|
9b23057b7f9ad6c366d92a59fcffcc87375bae08 |
|
08-Oct-2010 |
Darin Petkov <petkov@chromium.org> |
AU: Resume interrupted update attempts. BUG=7390,7520 TEST=unit tests Change-Id: I9baf72aa444dd855409f865f03fb665e91f8d03d Review URL: http://codereview.chromium.org/3620013
/system/update_engine/omaha_response_handler_action.cc
|
0406e40b8e414792cfc89ea32d57f947330964f0 |
|
07-Oct-2010 |
Darin Petkov <petkov@chromium.org> |
AU: Optimize checkpointing a bit and decide on new update vs. resume. BUG=7390 TEST=unit tests, gmerged on device Change-Id: Ibed6082fe697e6b28b03fb1cc39d700826bf2bfe Review URL: http://codereview.chromium.org/3541016
/system/update_engine/omaha_response_handler_action.cc
|
73058b421f91e04cc605c2a113e0010009a63594 |
|
07-Oct-2010 |
Darin Petkov <petkov@chromium.org> |
AU: Start checkpointing update progress. Checkpoint the manifest metadata size and the update check response hash in the preference store. Also checkpoint the next operation and data offset. Add methods for getting/setting hash context. BUG=7390,7394 TEST=unit tests Change-Id: I25291bf598ac9b0f1033e11cfe59df45b1f6eeab Review URL: http://codereview.chromium.org/3521016
/system/update_engine/omaha_response_handler_action.cc
|
c1a8b426be9542bc880923711ca508ea3f84000e |
|
19-Jul-2010 |
Darin Petkov <petkov@chromium.org> |
For actions, switch bool success into an exit code. This way we can signal specific error conditions and then send appropriate events to Omaha from the UpdateAttempter. BUG=560 TEST=unit tests, gmerged and looked at logs Review URL: http://codereview.chromium.org/3022008
/system/update_engine/omaha_response_handler_action.cc
|
3270f7411f55b872db385d0edffdfed18a684121 |
|
16-Jul-2010 |
Andrew de los Reyes <adlr@chromium.org> |
AU: Changes for deltas on traditional bios machines. BUG=None TEST=Attached unittests/tested on image - Fix uninitialized variable err in action processor unittest - Let Omaha dictate if an update is a delta or full update - Bug fix in delta generator for differently-sized images - More logging when applying delta updates - Fix infinite loop in http fetcher unittest - log each HTTP connection to know when a dropped connection is reestablished. - Detect when speed goes below a threshold and reestablish HTTP connection (currently < 10bytes/sec for 90 contiguous seconds). - Fix stack overflow in libcurl http fetcher. - optimize out a lot of needless CPU usage in libcurl http fetcher (turns out adding a glib main loop source uses a lot of CPU). - subprocess: pass PATH, log stdout/stderr - postinstall runner: support for ext3 and ext4 target filesystems. Review URL: http://codereview.chromium.org/2805027
/system/update_engine/omaha_response_handler_action.cc
|
6a5b3229b44c1f81ee153829e9b501e547f29926 |
|
13-Jul-2010 |
Darin Petkov <petkov@chromium.org> |
Rename UpdateCheckAction|Params to OmahaRequestAction|Params. Also, renamed UpdateCheckResponse to OmahaResponse. BUG=560 TEST=unit tests, gmerge'd on device. Review URL: http://codereview.chromium.org/2981007
/system/update_engine/omaha_response_handler_action.cc
|
63b96d74b2ffe5999243ab5c33f588030bcb42ce |
|
10-May-2010 |
Andrew de los Reyes <adlr@chromium.org> |
AU: DBus support. A few changes to support dbus in the Update Engine daemon: - SConstruct: build marshaller for the dbus signal. - Update Attempter: respond to dbus calls and broadcast status on dbus signal. - Update Engine Client: flag to listen for status updates. - Also, cleanup outdated code in Omaha Response Handler. BUG=None TEST=attached unittests/on device tests Review URL: http://codereview.chromium.org/2037002
/system/update_engine/omaha_response_handler_action.cc
|
f98bff879c8e90840582f6a60a93918465f2d8b9 |
|
06-May-2010 |
Andrew de los Reyes <adlr@chromium.org> |
AU: Minor fixes to get it to do full update on real device - Link w/ gtest only for unittests. - filesystem_copier_action: always send install plan on the output pipe on success, even if no copy was performed. - omaha_response_handler: properly choose install partition based on new GPT partition spec. - More useful logging to match memento_updater (which update URL is used, dump of the request/response for the update check). - Fixed a bug where I wasn't bonding the proper actions together in update_attempter. BUG=None TEST=attached unittests/did full update on Eee PC Review URL: http://codereview.chromium.org/2044001
/system/update_engine/omaha_response_handler_action.cc
|
1e338b8d8289e1abbee16c628612a10e0eaaca93 |
|
22-Jan-2010 |
Andrew de los Reyes <adlr@chromium.org> |
AU: Gut code for old updater. New protobuf for v2 updater. Review URL: http://codereview.chromium.org/545072
/system/update_engine/omaha_response_handler_action.cc
|
4fe15d017c145aca449c2248420c1b4ec8c23758 |
|
11-Dec-2009 |
Andrew de los Reyes <opensource@google.com> |
AU: Try delta updates first, then full updates Also, some bug fixes. Review URL: http://codereview.chromium.org/492008
/system/update_engine/omaha_response_handler_action.cc
|
3defe6acb3609e70e851a6eff062577d25a2af9d |
|
04-Dec-2009 |
adlr@google.com <adlr@google.com@06c00378-0e64-4dae-be16-12b19f9950a1> |
Missed new files in last commit Review URL: http://codereview.chromium.org/465067 git-svn-id: svn://chrome-svn/chromeos/trunk@336 06c00378-0e64-4dae-be16-12b19f9950a1
/system/update_engine/omaha_response_handler_action.cc
|