Issue metadata
Sign in to add a comment
|
chrome.enterprise.platformKeys.getTokens API fails during the first session after enrollment |
||||||||||||||||||||||
Issue descriptionChrome Version: M60.0.3105.0 OS: ChromeOS 9574.0.0 What steps will reproduce the problem? (1) Enroll device in a domain with forced-installed extension "PlatformKeys Test Extension" (ID: hoppbgdeajkagempifacalpdapphfoai) (2) Launch the extension chrome-extension://hoppbgdeajkagempifacalpdapphfoai/main.html (3) Check the "Get user token" status which is the first text field on the page. (4) Click on Generate Key Pair button to generate the Public key. What is the expected result? (3) "OK: Found tokens: user, system." (4) Public key string is genreated. What happens instead? (3) stays at "Getting the user and system token ..." (4) stays at "Generated Key: Generating..." This issue begins from M60.0.3103.0:9566.0.0. Previous versions do not have this issue and work right away in the first session when the extension is installed. The workaround is to not accessing the extension in the first session. This issue does not reproduce after signing out and re-signing in subsequent sessions.
,
May 23 2017
Technical details for reference: - We should definitely wait until cryptohome is ready before starting loading system token - Probably we should only start loading system token if TPM is owned.
,
May 23 2017
CL up: https://chromium-review.googlesource.com/c/512662/ Seems to solve the issue (which I could reproduce) for me.
,
May 23 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/fc674bec51cf121f34d241830b037315f74a7f18 commit fc674bec51cf121f34d241830b037315f74a7f18 Author: Pavol Marko <pmarko@chromium.org> Date: Tue May 23 16:42:28 2017 Skip loading system token on startup if TPM is not ready If the TPM is not ready, don't try to load the system token. It would fail anyway and prevent the TPM initialization process from running on user sign-in (because TPMTokenLoader only performs the initialization process once). Also, delay system token initialization until cryptohome is ready. BUG= 725346 , 655266 TEST=Manual test on Chrome OS: (1) On a freshly resetted device (not enrolled, not owned), the system token is simply not loaded on the sign-in screen (2) On an enrolled device, the system token is loaded on the sign-in screen. Device-wide EAP-TLS networks can connect. In both cases, there should be no errors related to TPM init in /var/log/chrome/chrome. Change-Id: If810287747f05361ffa3a0a06fe9f2c8988ea676 Reviewed-on: https://chromium-review.googlesource.com/512662 Reviewed-by: Maksim Ivanov <emaxx@chromium.org> Reviewed-by: Steven Bennetts <stevenjb@chromium.org> Commit-Queue: Pavol Marko <pmarko@chromium.org> Cr-Commit-Position: refs/heads/master@{#473937} [modify] https://crrev.com/fc674bec51cf121f34d241830b037315f74a7f18/chrome/browser/chromeos/chrome_browser_main_chromeos.cc [modify] https://crrev.com/fc674bec51cf121f34d241830b037315f74a7f18/chrome/browser/chromeos/login/session/user_session_manager.cc [modify] https://crrev.com/fc674bec51cf121f34d241830b037315f74a7f18/chromeos/cert_loader.h
,
May 23 2017
,
May 24 2017
As verified in M60.0.3105.0: 9578.0.0 dev reks, the issue has been fixed and no longer seen after enrollment.
,
May 24 2017
I was wrong. Still seeing the issue in M60.0.3105.0: 9578.0.0 dev snappy and 60.0.3107.0: 9582.0.0 dev snappy. Perhaps the CL is not in yet?
,
May 26 2017
Just checked, according to goldeneye, the CL should be in in: 2017-05-25 02:06 9588.0.0 60.0.3109.0 and later builds :) So it's expected to still have the same behavior in 60.0.3107.0: 9582.0.0.
,
May 27 2017
As verified om M60.0.3111.0:9591.0.0 dev reks and snappy, the issue is no longer seen after enrollment.
,
Jun 7 2017
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by pmarko@chromium.org
, May 23 2017