New behavior of oo7::Keyring API traps users in unusable state

[sophie-h]

This issue is based on oo7::file::UnlockedKeyring::load_unchecked was basically the behavior in previous version.

Accordingly, people do have keyrings in their Flatpaks, that contain secrets encrypted with different Flatpak secrets. Using an app with a recent oo7 version just makes the app unusable without manually deleting the keyring in the Flatpak data for each app.

But even if we consider the legacy keyrings with multiple secrets having disappeared at some point, resetting the users host keyring, will still end up with apps ending up in an unrecoverable state where the keyring in each flatpak has to be deleted manually.

I wonder if the old behavior was really a bad idea for the convenience API.

[bilelmoussaoui]

Accordingly, people do have keyrings in their Flatpaks, that contain secrets encrypted with different Flatpak secrets. Using an app with a recent oo7 version just makes the app unusable without manually deleting the keyring in the Flatpak data for each app.

How can it be encrypted with different flatpak secrets???

[sophie-h]

How can it be encrypted with different flatpak secrets???

Each item in the keyring file is encrypted separately. So there is no problem having different items encrypted with different secrets.

And the secret used for encryption depends on the secret portal, which can of course change if it is changed in the host keyring.

[sophie-h]

This is currently preventing users from using Pika Backup properly (scheduled backup etc), since reading the item fails with PasswordStorage(File(IncorrectSecret)), but also Pika then trying to write a new entry fails equally, while it would be totally possible to just write a new item.

[bilelmoussaoui]

And the secret used for encryption depends on the secret portal, which can of course change if it is changed in the host keyring.

If people change the secret portal, it is up to them to migrate the secret from one portal impl to another.

Each item in the keyring file is encrypted separately. So there is no problem having different items encrypted with different secrets.

That is not really the intent though, to have each item encrypted with a different secret but instead to only unlock/decrypt the item you want and not access the rest at all?

This is currently preventing users from using Pika Backup properly (scheduled backup etc), since reading the item fails with PasswordStorage(File(IncorrectSecret)), but also Pika then trying to write a new entry fails equally, while it would be totally possible to just write a new item.

oo7-cli --app-id com.belmoussaoui.Authenticator repair

can be used to remove any items that can no longer be decrypted with the secret stored in the portal.

[sophie-h]

If people change the secret portal, it is up to them to migrate the secret from one portal impl to another.

If people install a new system and then recover ~/.var from a backup, they hardly know that they have to keep the host keyring in sync with that. We shouldn't punish people for the complexity that we add to things like Flatpak portals.

That is not really the intent though, to have each item encrypted with a different secret but instead to only unlock/decrypt the item you want and not access the rest at all?

Of course, it's not the intent. But it's just something we have to deal with because it's a reality now. It's also not the purpose of the format to decrypt entries when writing to a Keyring. Why is this happening at all?

We could of course say, we rewrite the complete keyring once we hit an entry that can't be decrypted. But I feel like that would be a bit excessive and also would require to decrypt all entries in the keyring to check if they can be decrypted, which will become very slow for larger keyrings.

So I think the only realistic option is to just not touch entries that can't be decrypted.

oo7-cli --app-id com.belmoussaoui.Authenticator repair

can be used to remove any items that can no longer be decrypted with the secret stored in the portal.

Why would anyone have that tool installed right now, and how would they know that they need to use it if a random app throws random keyring errors?

[bilelmoussaoui]

There is an API to call if you don't want end users to install the tool manually and call it. You can get the file backend from the generic keyring and call the repair function yourself.

By checking if the secret is correct and can decrypt the items, you can avoid using a wrong secret to write more items. The low level API allows you to do anything you want but I am not convinced the wrapper API should allow you to do that.

The whole story of secret service is a mess because if you have both kwallet and gnome-keyring around, both would fight eachother and you might have the two portals around as well. All lf these mess is something i am Actively working towards fixing by making our server and portal impl the only default one in major linux distros so none of those problems would ever happen.