Semantic of secrets storage option

[Andrey Borzenkov]

Currently when user changes between No store, plain text or encrypted
setting is changed on disk but kded continues to use old value. But
when user edits connection, rc file is reloaded as side effect. So
possible sequence is

- user starts with plain text. Connections secrets are loaded from disk
- user changes to encrypted. kded continues to use plain text and old
secrets for connections loaded up to this point
- user creates new connection. Secrets for this connection are stored
in wallet. kded rereads rc file and now tries to load secrets for
*all* connections from wallet - which are not available there.
- next time kded module is reloaded no secrets are available as well.

What is desired semantic of this option? I see two possibilities

1. all connections use the same secret storage. In this case changing
storage type must move secrets from old to new type

2. global storage is just default for new connection. This implies,
that connection must "remember" where secrets are located. In this
case changing global option will not have any effect on existing
connections. Connection editor needs extra control to select secrets
storage type and we still need to implement moving secrets around.

I think 2 is more appropriate. It also can be logically extended with
NM 0.9 to include remote secrets (stored by NM) as storage type.

Thoughts?

[Lamarque Vieira Souza]

Post by Andrey Borzenkov
Currently when user changes between No store, plain text or encrypted
setting is changed on disk but kded continues to use old value. But
when user edits connection, rc file is reloaded as side effect. So
possible sequence is
- user starts with plain text. Connections secrets are loaded from disk
- user changes to encrypted. kded continues to use plain text and old
secrets for connections loaded up to this point
- user creates new connection. Secrets for this connection are stored
in wallet. kded rereads rc file and now tries to load secrets for
*all* connections from wallet - which are not available there.
- next time kded module is reloaded no secrets are available as well.
What is desired semantic of this option? I see two possibilities
1. all connections use the same secret storage. In this case changing
storage type must move secrets from old to new type
2. global storage is just default for new connection. This implies,
that connection must "remember" where secrets are located. In this
case changing global option will not have any effect on existing
connections. Connection editor needs extra control to select secrets
storage type and we still need to implement moving secrets around.
I think 2 is more appropriate. It also can be logically extended with
NM 0.9 to include remote secrets (stored by NM) as storage type.
Thoughts?

I think 1 is what users expect to happen. But it does not need to happen
all at once, you move the secrets when its connection is used. I am thinking
about the case when the user selects "plain text" but regrets and wants to use
kwallet instead. With 2 he/she would have to delete the connection and
recreate it.

Honestly I would rather prefer removing the "plain text" option but it
seems some users in bugs.kde.org like "plain text" secrets.