Bumping the priority (and editing the bug description) here, since this issue was the cause of issue 866711. Ryan, let's get this fixed the right way for M-70, since it's causing crashes as-is.

The crash that this inelegant design caused has been addressed in crbug.com/866710. While it's still necessary that we improve this design, it'd not a launch blocker that absolutely needs to get into M70. Downgrading priority.

Re: comment #2: The sign-in feature might actually be broken, though.

Originally, the design changed set both a local and remote device in the TPM. Then, when attempting a sign-in, it looked for those two devices and attempted to use them. Somehow, storing these remote devices failed in some cases, so my fix simply returned early if both of the remote devices were unavailable.

If both devices are not available, this means that we won't be able to sign in when we actually should be able to. We should try to investigate this to ensure that sign-in behavior does not regress.

It's not that "storing these remote devices failed in some cases", rather, I failed to implement a critical migration step (failed to accomodate old devices in the TPM not having the new |unlock_key| boolean field). I explained more at https://bugs.chromium.org/p/chromium/issues/detail?id=866710#c10.

AFAICT, the sign-in feature is not fundamentally broken in respect to its TPM persistence mechanism. (but is still poorly designed and should be refactored!) 

Ryan, will you update the bug summary to reflect the cleanup work that needs to happen on this bug?