internal Encryption error using chrome.lockScreen.data
Reported by
james.ke...@gmail.com,
Oct 27 2017
|
||||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; CrOS x86_64 9901.54.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.74 Safari/537.36 Platform: 9901.54.0 (Official Build) beta-channel eve Steps to reproduce the problem: 1. chrome.lockScreen.data.getContent() 2. Error! "Internal - encryption" 3. What is the expected behavior? Able to retrieve data from lockScreen storage without errors. What went wrong? Perhaps the encryption key changed? Did this work before? N/A Does this work in other browsers? Yes Chrome version: 62.0.3202.74 Channel: n/a OS Version: 9901.54.0 Flash Version: 27.0.0.183 https://cs.chromium.org/chromium/src/extensions/browser/api/lock_screen_data/lock_screen_data_api.cc?l=31
,
Oct 27 2017
,
Oct 27 2017
,
Oct 28 2017
Just ran into this again. It happened after testing a some multi-login scenarios. But after it happened, I couldn't get it to happen again by testing the same kind of scenarios.
,
Oct 28 2017
few more questions: 1. When this happens, does creating new items work (or do you see the error only for getting existing items)? 2. Does this happen when you try to get data just after log in (i.e. does it happen when data is accessed first time within a user session)? 3. More details about scenario where the issue happened might be useful.
,
Oct 28 2017
1. Creating new items does not work. 2. I've only seen this happen twice. We have a listener in our background page (lockScreen.data.onDataItemsAvailable) that works all the time, right after logging in. The two times that I've seen this bug, the Internal Encryption error is returned for any attempt to access lockscreen data at any time--until the app is uninstalled then reinstalled. 3. No idea what I was doing that might have caused it. As I said in comment #4, I thought maybe some ChromeOS multi-login stuff was related, but then I was unable to reproduce.
,
Oct 28 2017
,
Oct 30 2017
if you see this happening again, can you try the following: 1. lock the screen, try to create a data item and set it's content (and log the error if any) 2. unlock the session, if step one succeeded, try to get the item contents 3. try to delete items that cannot be read File feedback (make sure that you reference this bug, so I can look it up).
,
Nov 10 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/ebfb53ef886f1e0c5865a41d4e3b38b7c35336f2 commit ebfb53ef886f1e0c5865a41d4e3b38b7c35336f2 Author: Toni Barzic <tbarzic@google.com> Date: Fri Nov 10 19:48:14 2017 Migrate lock screen data items to new storage location Lock screen item data was incorrectly saved in the same value store for all users (though, given that all data items are encrypted by a user specific encryption key, the app can only read the current user's data items). This fixes the lock screen item storage to use per-user value store, and migrates data items encrypted by the users key from the deprecated value store to the introduces, per-user value store location. PART 1/2: Implement an interface to migrate data items between value stores used by lock screen data API. Bug:779277 Change-Id: Icb9af9e3acd6f112d740e012bb5057f7d3854480 Reviewed-on: https://chromium-review.googlesource.com/754507 Commit-Queue: Toni Barzic <tbarzic@chromium.org> Reviewed-by: Istiaque Ahmed <lazyboy@chromium.org> Reviewed-by: Xiyuan Xia <xiyuan@chromium.org> Cr-Commit-Position: refs/heads/master@{#515640} [modify] https://crrev.com/ebfb53ef886f1e0c5865a41d4e3b38b7c35336f2/extensions/browser/BUILD.gn [modify] https://crrev.com/ebfb53ef886f1e0c5865a41d4e3b38b7c35336f2/extensions/browser/api/BUILD.gn [add] https://crrev.com/ebfb53ef886f1e0c5865a41d4e3b38b7c35336f2/extensions/browser/api/lock_screen_data/lock_screen_value_store_migrator.h [add] https://crrev.com/ebfb53ef886f1e0c5865a41d4e3b38b7c35336f2/extensions/browser/api/lock_screen_data/lock_screen_value_store_migrator_impl.cc [add] https://crrev.com/ebfb53ef886f1e0c5865a41d4e3b38b7c35336f2/extensions/browser/api/lock_screen_data/lock_screen_value_store_migrator_impl.h [add] https://crrev.com/ebfb53ef886f1e0c5865a41d4e3b38b7c35336f2/extensions/browser/api/lock_screen_data/lock_screen_value_store_migrator_impl_unittest.cc
,
Nov 16 2017
,
Nov 16 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/447fc924b3958e5bdd9ad64ede4ffffcd31e5eb4 commit 447fc924b3958e5bdd9ad64ede4ffffcd31e5eb4 Author: Toni Barzic <tbarzic@google.com> Date: Thu Nov 16 20:54:31 2017 Migrate lock screen data items to new storage location Lock screen item data was incorrectly saved in the same value store for all users (though, given that all data items are encrypted by a user specific encryption key, the app can only read the current user's data items). This fixes the lock screen item storage to use per-user value store, and migrates data items encrypted by the users key from the deprecated value store to the introduces, per-user value store location. PART 2/2: Hook up lock screen value store migrator to item storage - ensure data items for an extension are migrated before allowing the lock screen data API access to the extension's data. Bug: 779277 Change-Id: I1cb259d272ea6cf5d4cf6263c0f03246f71f335f Reviewed-on: https://chromium-review.googlesource.com/756327 Commit-Queue: Toni Barzic <tbarzic@chromium.org> Reviewed-by: Xiyuan Xia <xiyuan@chromium.org> Cr-Commit-Position: refs/heads/master@{#517180} [modify] https://crrev.com/447fc924b3958e5bdd9ad64ede4ffffcd31e5eb4/chrome/browser/chromeos/lock_screen_apps/state_controller.cc [modify] https://crrev.com/447fc924b3958e5bdd9ad64ede4ffffcd31e5eb4/extensions/browser/api/lock_screen_data/lock_screen_item_storage.cc [modify] https://crrev.com/447fc924b3958e5bdd9ad64ede4ffffcd31e5eb4/extensions/browser/api/lock_screen_data/lock_screen_item_storage.h [modify] https://crrev.com/447fc924b3958e5bdd9ad64ede4ffffcd31e5eb4/extensions/browser/api/lock_screen_data/lock_screen_item_storage_unittest.cc
,
Dec 15 2017
|
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by jsb...@chromium.org
, Oct 27 2017