Keyring locks itself when Chrome starts |
||||
Issue descriptionChrome Version: 61.0.3163.100 OS: Linux What steps will reproduce the problem? (1) Keyring setup: The default keyring is different from the Login keyring and it's set to unlock automatically. (2) The Login keyring is unlocked (thus allowing other keyrings to unlock automatically) (3) Run Chrome What is the expected result? The default keyring unlocks automatically. What happens instead? The Login keyring locks itself. A prompt to unlock the default keyring appears. Some calls to keyring fail with a timeout regardless. OSCrypt appears to initialize correctly (i.e. its calls don't timeout).
,
Oct 17 2017
,
Oct 17 2017
If I manually unlock the default keyring, everything works normally. I suspect Chrome is doing something that causes panic in the part of Keyring that reads from the Login keyring to unlock the default keyring. Vaclav, how did your change affect how calls are made to Keyring? Are we making calls in parallel now?
,
Oct 18 2017
Thanks for investigating this, Christos. My change did move the NativeBackendGnome/GKRMethod's background tasks from the DB thread to some less-specified but sequenced task runner. NativeBackendGnome/GKRMethod itself should still not call to Keyring in parallel itself (since the task runner is sequenced). But perhaps there are other callsites for Keyring withing OSCrypt which could end up calling Keyring from another task runner and in parallel with NativeBackendGnome/GKRMethod? If so, we might just want OSCrypt to vend the background task runner, and NativeBackendGnome take it from OSCrypt instead of creating its own.
,
Jan 26 2018
,
Nov 29
vabr going hobby only -> reducing involvement. Please contact me directly in urgent matters. |
||||
►
Sign in to add a comment |
||||
Comment 1 by cfroussios@chromium.org
, Oct 17 2017