Is this really blocking bug 571003? The solutions to this problem are very likely to be different before and after OSCrypt becomes
 the exclusive owner of communications with keyring/kwallet. I would argue that this bug needs to be addressed after bug 571003 and is blocked by it.

It's tricky. I agree that we need to implement bug 571003 before securing that implementation against unwanted fall-back. But we should not launch the new backend before this bug is addressed. My suggestion is:
1. Implement bug 571003 behind a flag.
2. Fix this bug, mark as closed.
3. Move the implementation fixing bug 571003 from behind the flag and mark bug 571003 as closed.

If you agree with that order, then the current blocking should make sense (the blocking bug is marked as fixed before the blocked bug). Having said that, I'm fine with anything, as long as we don't forget to fix this in time.

I understand your logic behind blocking issue 571003.

A different issue. I think we need some additional clarity on what the new expected behaviour is.

1. Are we going to reject all incoming passwords (i.e. not sync and not offer to save) when full encryption is not supported? That would disable the component for users who are already using password manager.
2. We could attempt to distinguish between the temporary and the permanent unavailability of the password store. I do not know of a 100% reliable way to make that distinction.
3. We could just display a warning that sensitive data may be vulnerable, and attempt to encrypt unencrypted stuff when we get the chance.
4. Other options?

I should also note that the temporary unavailability of a password store has more destructive consequences now than it used to. Various pieces of user data become unavailable without encryption.

Also, other components, which also use encryption, will not automatically follow us in whatever behaviour we choose. Other clients simply fall back to obfuscation. Does it make sense for Password Manager to put in the additional effort to not have obfuscated data?

Thanks for looking into this!

Ad 1., I don't think we should turn the password manager off when there is no encryption, unless there are already passwords stored, which are encrypted. In that situation, turning password manager off prevents entering an inconsistent state when only parts of the store are usable under each store state; also keeping it on would still result in a broken experience (saved passwords inaccessible).

Another thing to watch for would be that we do not propagate the inaccessibility of stored passwords as deletion to sync.

I also don't think it makes sense to put any more effort in handling changes in encryption abilities inside password manager. At the same time I believe there is handling and user-facing messaging to be done, but at the level of os_crypt. Something like:
* If there was no encryption available so far, but suddenly there is, os_crypt should ask the user something like: "It seems that Gnome Keyring became available. Do you want to turn on encryption of your passwords and other pieces of profile data? If you turn encryption on, Gnome Keyring needs to stay available to Chrome in order to access your data."
* If there used to be encryption available before but is no more, os_crypt should announce something like: "Chrome is missing access to KWallet, some profile data including passwords will be unavailable."
These are just rough sketches, we'd need to do more detailed plan to get the UI right (including potentially reducing it for, e.g., syncing users, for whom sync may allow fixing some data loss automatically).

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot