[kde-networkmanager] KNetworkmanager KWallet integration improvements

[Will Stephenson]

Valentine,

Timo (Hoenig) forwarded me your patch as I'm responsible for most of the 
recent work on the KWallet and KConfig code.

Firstly thank you very much for contributing.  I am testing your patch to see 
if it we can use it vs the existing codebase for possible updates to the 
current SUSE.

I've just committed portions of it to KDE SVN.  The reason I haven't committed 
the whole thing is that I am in the process of refactoring KNetworkManager to 
make it clearer and more structured, so I can use more of the design in KDE 
4.  

One of the goals was to prevent opening the wallet on app start, which was 
already working, so I have kept my implementation of that.  I have integrate 
your isModified() design and your idea to update the stored network on 
NMConnected, that was very helpful.

You can find the refactoring branch at 
https://anonsvn.kde.org/home/kde/branches/work/knm-make-it-cool

There are a couple of gotchas you should know about at the moment, switching 
to wired network causes the bus to disconnect us, and there's a double-delete 
crash on exit.

Thanks again for the patch, look forward to hearing from you

Will Stephenson

On Monday 12 June 2006 08:45, Valentine Sinitsyn wrote:
> Dear Thomas,
>
> First of all, thank you and all other Novell programmers for the great
> KNetworkManager project! I hope it will be integrated into mainline
> KDE soon.
>
> I found that KWallet integration fixes are on your to-do list and,
> since password dialog for opening wallet was annoying me so much I
> decided to try to help implementing this feature. You can find the
> patch against latest SVN code in the attachment. It's not as beautiful
> as it ought to be - but I tried to preserve all the original KNM
> interfaces (i.e. "const" modifiers etc) as much as possible. Let me briefly
> explain design ideas:
>
> We want KNM to open wallet and read a secret (a "key") only when it's
> actually needed - i.e. when NM daemon requests it via
> getKeyForNetwork() method. It is obvious that a key is a property of
> an Encryption class and should be persisted along with it. But, there
> are two issues:
>
> 1. If Encryption object has the key, it should be persisted at the
> same time as other encryption data (i.e. in ::persist method) but not vice
> versa - in fact, the main thing we are going to do is to restore a key
> only when it's needed, not when we are trying to find out what was a
> ciphersuite, WEP bits or whatever.
> 2. In order to save a key is the storage, we need to know ESSID which
> (obviously) is the property of Network object, not Encryption object.
>
> The solution implemented is as follows: keep a pointer to a "parent"
> Network object in Encryption object (in the very same way QObjects do) and
> have a separate method to persist/store a key (using
> KNetworkManagerStorage). The connection between Network and Encryption
> is established not in constructor but when Network::setEncryption() is
> called as it is the only way to associate Network and Encryption from the
> outside.
>
> Then, when NM asks us for a key, we should look for it:
> 1. in Encryption object for the Network under consideration
> 2. in the secure storage (if it's there)
> 3. ask the user
> The second item suggests that we should have a method which returns
> "true" when there is a key in the wallet and "false" when not. The logic is
> simple: when Encryption is persisted (along with key, obviously), try
> to persist the key in the storage and set some property of the
> persisted network ("KeyStored" in my implementation) to the result
> value. So, if putting a key in the storage was successful, KeyStored
> will be "true" and when the Encryption object would be restored from the
> disk it will know that it has something in the wallet ;-)
>
> The third item suggest that we should put a newly entered key in the
> wallet, but *when* should we do it? We should save the key when we
> successfully connect to the selected network since it will be the proof
> of correctness of the key (also, you will not get zero timestamps when
> connection fails). You can just put storeNetwork/storeCredentials pair
> in KNetworkManagerTray::slotNMConencted but it is also not good - if
> the user does not enter any new info, storing a key or network is
> useless (nothing is different between memory and on-disk variants).
> The proposed solution is to "teach" Network/Encryption classes to look
> after modifications made on them (as documents in word processors do)
> and provide isModified() method to check if there are any
> modifications. The object is considered to be
> modified when one of the "persisting" fields are changed - for
> instance, ESSID or corresponding Encryption object for the Network.
> "_dirty" flag is responsible for all of this.
>
> So that's how it works. If you need any additional information, don't
> hesitate to contact me. Thanks again for a great program!
>
> Best regards,
> Valentine Sinitsyn