Semantic of secrets storage option

[Lamarque Vieira Souza]

Em Saturday 02 April 2011, Andrey Borzenkov escreveu:
> 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.

-- 
Lamarque V. Souza
http://www.geographicguide.com/brazil.htm
Linux User #57137 - http://counter.li.org/
http://planetkde.org/pt-br
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kde-networkmanager/attachments/20110407/8c9e6a20/attachment.htm