Bug 399268

This is in my opinion correct behaviour. When you try to connect to a new connection, we pre-configure it with setting that the password will be stored in KWallet, because during that time it's available and using KWallet is safer option then storing the password unencrypted in NM. Then if you ignore creating a wallet, you block our secret agent to use KWallet. NM then tries to activate this connection and from obvious reasons our secret agen asks KWallet for the password, because we told to NM that it's stored there, but fails and the only way how to get it is to present a dialog to enter the password. From NM perspective, it has no idea whether the password was provided by KWallet or from the dialog.

(In reply to Jan Grulich from comment #1)
> because we told to NM that it's stored there,

We told to NM that it's stored in KWallet when it's not stored there?

It's definitely a bug. It's annoying when password was asked twice (what the hay, I just entered it, why you're asking again?!)

When creating a new connection, you feed NM with connection parameters, in case KWallet is available we specify that the secrets will be stored by our secret agent. You are not supposed to ignore KWallet configuration, if you don't want to use KWallet, then disable it and your secrets will be by default stored in NM.

(In reply to Jan Grulich from comment #3)
> in case KWallet is available we specify that the secrets will be stored by our
> secret agent

Why do we specify that when KWallet is available?
We can't be sure that user accepts the KWallet dialog, so we can't specify this. It's too early.

We can specify that the secrets will be stored in KWallet when they are *actually* stored in there. Not when KWallet is available.

So you suggest by default saving the secrets unencrypted to NM, which is not secure at all? Given that secrets saving goes through NM to our secret agent, there is no way how to first "try" to save them to KWallet. Well, we could perform all of this when Plasma is started to test whether KWallet is available, but you really don't want to bother users everytime with a dialog to unlock KWallet when Plasma starts or when KCM module for NM configuration is opened.

(In reply to Jan Grulich from comment #5)
> So you suggest by default saving the secrets unencrypted to NM, which is not
> secure at all?

I suggest *checking* whether the secrets were saved in KWallet and pre-configure the connection with setting that the password *will be* stored in KWallet if and only if they actually were saved.
Without this check it will be *inconsistent* at least. First we need to make sure that the secrets will be saved *under any conditions*, including user input.

> you really don't want to bother users everytime with a dialog
> to unlock KWallet when Plasma starts or when KCM module for NM configuration
> is opened.

But you want to bother users with a dialog to provide Wi-fi password twice every time they connect to new network.

What we can possibly do is when we fail to retrieve secrets from KWallet, we can update the connection specifying that the secrets should be stored system-wide in NM.

But system-wide means unencrypted?

(In reply to Christoph Feck from comment #8)
> But system-wide means unencrypted?

Yes. It's either that or not storing secrets at all and keep asking users to configure KWallet.

> When KWallet is used [...] and kwallet creation is refused
Why not just remove KWallet if you don't want to use it? Seems odd to keep the packages around so it can torture you with requests to create a wallet.



That said, if the user refuses to use KWallet, that's a pretty good sign that they don't care about security at all and the best we can do is store the password unencrypted on their disk somewhere. :(

(In reply to Nate Graham from comment #10)
> > When KWallet is used [...] and kwallet creation is refused
> 
> That said, if the user refuses to use KWallet, that's a pretty good sign
> that they don't care about security at all and the best we can do is store
> the password unencrypted on their disk somewhere. :(

What about that case?
User tries to create a connection with an encrypted network provided by hotel which will be used for a day or two.

There is no sense to store a password in the wallet, because connection is temporary.
And there is no sense to remove kwallet from system.

I forgot to tell about that there is no difference between refusing to create a wallet and refusing to use a wallet (enter wallet password)

(In reply to Oleg Solovyov from comment #11)
> What about that case?
> User tries to create a connection with an encrypted network provided by
> hotel which will be used for a day or two.
> 
> There is no sense to store a password in the wallet, because connection is
> temporary.

What is the problem with just storing the hotel wifi password in the wallet? Why is this an issue?

(In reply to Nate Graham from comment #12)
> (In reply to Oleg Solovyov from comment #11)
> 
> What is the problem with just storing the hotel wifi password in the wallet?
> Why is this an issue?

I think it's redundnant to store "almost onetime password" in the wallet :D

(In reply to Oleg Solovyov from comment #13)
> (In reply to Nate Graham from comment #12)
> > (In reply to Oleg Solovyov from comment #11)
> > 
> > What is the problem with just storing the hotel wifi password in the wallet?
> > Why is this an issue?
> 
> I think it's redundnant to store "almost onetime password" in the wallet :D

"Redundant" is probably not the word you're looking for since that implies that it is stored twice, which I don't think is happening here.

What's the *problem* with storing a hotel wifi password in the wallet?

(In reply to Nate Graham from comment #14)
> (In reply to Oleg Solovyov from comment #13)
> What's the *problem* with storing a hotel wifi password in the wallet?

It's unnecessary to store it in the wallet.
Unlike home password:
1) You don't need to keep the hotel wifi password encrypted because everyone can reveal it at reception
2) After few days, since you leave the hotel, you won't need to store the password anymore.

You are describing why it isn't *necessary*, but not why it is a *problem*.

I am suggesting that you store the hotel password in the wallet anyway, because even though it may not feel *necessary*, doing so doesn't cause any *problems*, and in fact, allows you to *avoid* the problem described in this bug report.