Not all libsecret calls trigger an unlock of the keyring |
||||||||||
Issue descriptionLibsecret methods are inconsistent in their ability to unlock the required keyring. secret_service_lookup should unlock as necessary, but suffers from a quirk (see issue 660005). secret_service_search will generate collections, individual items of which may have to be unlocked afterwards. It also suffers from issue 660005. secret_service_store will trigger the unlocking of the keyring. Currently, Password Manager and OSCrypt do not attempt to unlock all the returned items. So far, this bug was invisible, because Password Manager's reaction to not loading the expected entries is to repopulate the keyring. The calls to secret_service_store would unlock the keyring and operations will appear normal from then on. Unfortunately, OSCrypt's reaction to not finding the old encryption key is to generate a new key and store it. This appears to not happen in M55, possibly because the migration from a deprecated schema is taking the hit for the bug [verification pending].
,
Oct 24 2016
,
Oct 24 2016
,
Oct 24 2016
,
Oct 24 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/51e9b147713a497adcb228ae729a799872a35237 commit 51e9b147713a497adcb228ae729a799872a35237 Author: cfroussios <cfroussios@chromium.org> Date: Mon Oct 24 14:28:31 2016 Unlock all libsecret items in Password Manager and OSCrypt The various libsecret methods have different contracts w.r.t. unlocking keyring items. Of the currently used methods, only secret_service_store will trigger unlocking as necessary. As a result, operations fail in various ways until someone performs the first store operation. With the CL, the libsecret native backend of Password Manager is set to explicitly request unlocking of items on every call. OSCrypt avoids using secret_service_lookup, which apparently ignores locked items. BUG= 657828 , 631171 Review-Url: https://codereview.chromium.org/2441653002 Cr-Commit-Position: refs/heads/master@{#427067} [modify] https://crrev.com/51e9b147713a497adcb228ae729a799872a35237/chrome/browser/password_manager/native_backend_libsecret.cc [modify] https://crrev.com/51e9b147713a497adcb228ae729a799872a35237/chrome/browser/password_manager/native_backend_libsecret_unittest.cc [modify] https://crrev.com/51e9b147713a497adcb228ae729a799872a35237/components/os_crypt/key_storage_libsecret.cc [modify] https://crrev.com/51e9b147713a497adcb228ae729a799872a35237/components/os_crypt/key_storage_libsecret_unittest.cc [modify] https://crrev.com/51e9b147713a497adcb228ae729a799872a35237/components/os_crypt/libsecret_util_linux.cc [modify] https://crrev.com/51e9b147713a497adcb228ae729a799872a35237/components/os_crypt/libsecret_util_linux.h
,
Oct 28 2016
,
Oct 28 2016
,
Oct 28 2016
dvadym@ you mentioned a problem with missing unlock prompts if the keyring is locked during runtime. Can you check how that relates to this bug? I think your issue may also be fixed by this.
,
Oct 28 2016
I meant issue 508458 . It looks quite similar to this bug. Could you please check that fix for this issue, also fixes that one?
,
Oct 28 2016
Issue 508458 has been merged into this issue.
,
Oct 31 2016
,
Nov 1 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/3251aa60e867fa743741efbbe1fda61686ea30ca commit 3251aa60e867fa743741efbbe1fda61686ea30ca Author: thomasanderson <thomasanderson@google.com> Date: Tue Nov 01 00:07:03 2016 Unlock all libsecret items in Password Manager and OSCrypt The various libsecret methods have different contracts w.r.t. unlocking keyring items. Of the currently used methods, only secret_service_store will trigger unlocking as necessary. As a result, operations fail in various ways until someone performs the first store operation. With the CL, the libsecret native backend of Password Manager is set to explicitly request unlocking of items on every call. OSCrypt avoids using secret_service_lookup, which apparently ignores locked items. BUG= 657828 , 631171 Review-Url: https://codereview.chromium.org/2441653002 Cr-Commit-Position: refs/heads/master@{#427067} NOTRY=true NOPRESUBMIT=true Review-Url: https://codereview.chromium.org/2463263002 Cr-Commit-Position: refs/branch-heads/2883@{#401} Cr-Branched-From: 614d31daee2f61b0180df403a8ad43f20b9f6dd7-refs/heads/master@{#423768} [modify] https://crrev.com/3251aa60e867fa743741efbbe1fda61686ea30ca/chrome/browser/password_manager/native_backend_libsecret.cc [modify] https://crrev.com/3251aa60e867fa743741efbbe1fda61686ea30ca/chrome/browser/password_manager/native_backend_libsecret_unittest.cc [modify] https://crrev.com/3251aa60e867fa743741efbbe1fda61686ea30ca/components/os_crypt/key_storage_libsecret.cc [modify] https://crrev.com/3251aa60e867fa743741efbbe1fda61686ea30ca/components/os_crypt/key_storage_libsecret_unittest.cc [modify] https://crrev.com/3251aa60e867fa743741efbbe1fda61686ea30ca/components/os_crypt/libsecret_util_linux.cc [modify] https://crrev.com/3251aa60e867fa743741efbbe1fda61686ea30ca/components/os_crypt/libsecret_util_linux.h |
||||||||||
►
Sign in to add a comment |
||||||||||
Comment 1 by cfroussios@chromium.org
, Oct 21 2016