Re: The situation of KWallet, and what to do about it?

[Valentin Rusu]

* Thomas Pfeiffer  [2016-07-13 11:41:14 +0200]:

> 
> On Linux we could use GNOME Keyring, but if we don't want that, we'd of
> course still have to implement our own backend. The advantage would be that
> it would be much easier to replace that at any point without having to adapt
> applications.
> 

There alre already well established solutions for password management
that tend to become widespread. We should provide KDE API for the main
one or two of them, and avoid re-inventing the wheel here. Users will
only be very happy if they can integrate their favourite password
manager with KDE.

The KDE API may compatible with KWallet's API, so existing application
won't need porting.


-- 
Valentin Rusu
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: The situation of KWallet, and what to do about it?

[Kevin Krammer]

On Wednesday, 2016-07-13, 11:41:14, Thomas Pfeiffer wrote:
> On 11.07.2016 22:29, Mark Gaiser wrote:

> > As far as i can tell, QtKeyChain isn't a keychain at all, it's a wrapper
> > around platform specific keychains that provides a unified interface for
> > keychain functionality. It itself doesn't implement a keychain (or it does
> > on windows?).
> 
> Yes, QtKeychain wraps available keychains from the platform it runs on.
> However: "Since Windows does not provide a service for secure storage
> QtKeychain uses the Windows API function CryptProtectData to encrypt the
> password with the user’s logon credentials. The encrypted data is then
> persisted via QSettings."
> 
> On Linux we could use GNOME Keyring, but if we don't want that, we'd of
> course still have to implement our own backend. The advantage would be that
> it would be much easier to replace that at any point without having to
> adapt applications.

If QtKeychain, or any other multiplatform API, can use the SecretService API 
on Linux, then we could just require such an implementation to be available 
and let the distributors decide whether they want to fulfill that with gnome-
keyring (assuming it is-a SecretService daemon).

Cheers,
Kevin
-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring


signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: The situation of KWallet, and what to do about it?

[Martin Graesslin]

On Friday, July 15, 2016 10:22:32 AM CEST Elvis Angelaccio wrote:
> 2016-07-14 1:11 GMT+02:00 Albert Astals Cid :
> > El dijous, 7 de juliol de 2016, a les 18:43:57 CEST, Elvis Angelaccio va
> > 
> > escriure:
> >> Hi,
> >> thanks for raising this topic!
> >> 
> >> 2016-07-07 12:36 GMT+02:00 Thomas Pfeiffer :
> >> > Hi everyone,
> >> > I'm addressing both the Plasma team and kde-devel because this issue
> >> > affects Plasma as well as many applications, and Valentin as the
> >> > current
> >> > maintainer of KWallet as well as KSecretService, a potential
> >> > replacement
> >> > for it.
> >> > 
> >> > KWallet plays a central role in Plasma and many KDE applications as the
> >> > central password storage. However, it being very old and not having
> >> > been
> >> > actively developed for a long time, it has lots of problems, including:
> >> > 
> >> > - It has weak security, as it does not restrict applications accessing
> >> > it
> >> > by default, and even when it does, it does so simply based on
> >> > application
> >> > name which allows any malicious process to impersonate an allowed one
> >> > - The initial setup has huge usability problems, as it forces users to
> >> > make
> >> > a choice on a very advanced technical level (encryption methods, no
> >> > less!),
> >> > and the option it suggests (GPG) is a nightmare to set up for ordinary
> >> > users - It does support unlocking via PAM, but does not tell users what
> >> > they need to do to make that work, which results in most users having
> >> > to
> >> > enter the KWallet password at each system start, which many find very
> >> > annoying (we get lots of negative feedback for that)
> >> > - It works only with KDE Frameworks-based applications
> >> > - One cannot easily write a QML GUI for it, making it unsuitable for
> >> > mobile
> >> > 
> >> > Valentin has been working on KSecretService for quite a while, which is
> >> > based on the freedesktop Secrets API [1] that is also supported in
> >> > GNOME
> >> > Keyring, and would solve many (and ideally all) of the above problems.
> >> > However, Valentin told me he does not have the time to work on
> >> > KSecretService any more.
> >> > 
> >> > This means we have to find a solution to these problems. The options I
> >> > see
> >> > currently are
> >> > - Improve KWallet (unlikely to fix all the problems without massive
> >> > changes
> >> > in it, though)
> >> > - Find someone to finish and maintain KSecretService
> >> > - Build a wrapper around one of the other existing keyring technologies
> >> > - Each application (and each Plasma component that stores passwords)
> >> > implements its own encrypted password storage
> >> > 
> >> > 
> >> > - We make encrypted password storage optional and non-default (easiest
> >> > solution, but not exactly in line with KDE's vision)
> >> 
> >> I disagree on this point. Even if KWallet were free of usability
> >> issues, it would still provide a false sense of security. The user
> >> thinks that his/her passwords are safe, while in fact they are not.
> > 
> > How exactly the passwords are not safe?
> 
> The default behavior is to keep wallets "open" once they have been
> decrypted. If a wallet is open, any process can trivially retrieve
> clear-text passwords from it using the KWallet API. I wanted to back my
> claim with some code, so I created a small PoC in [1]. All an attacker has
> to do is to guess the name of a wallet (and only if the default
> 'kdewallet' name is not used!).
> 
> I could also mention that KWallet accepts an empty master password,
> which alone is already bad enough.

yeah, once the wallet is open it's as secure as a simple plain-text file on an 
encrypted home. If the home is not encrypted kwallet does offer an advantage 
over a simple plain-text file.

If we assume that "if it runs, it's trusted" then everything is fine as well. I 
can see ways how this can be secure with containerized apps and e.g. dedicated 
privs the user has to acknowledge to have it read wallets. E.g. that a 
containerized app has to ask for password for application foo. This could 
offer a user a good and informed decision on whether to grant it or not.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: The situation of KWallet, and what to do about it?

[Elvis Angelaccio]

2016-07-14 1:11 GMT+02:00 Albert Astals Cid :
> El dijous, 7 de juliol de 2016, a les 18:43:57 CEST, Elvis Angelaccio va
> escriure:
>> Hi,
>> thanks for raising this topic!
>>
>> 2016-07-07 12:36 GMT+02:00 Thomas Pfeiffer :
>> > Hi everyone,
>> > I'm addressing both the Plasma team and kde-devel because this issue
>> > affects Plasma as well as many applications, and Valentin as the current
>> > maintainer of KWallet as well as KSecretService, a potential replacement
>> > for it.
>> >
>> > KWallet plays a central role in Plasma and many KDE applications as the
>> > central password storage. However, it being very old and not having been
>> > actively developed for a long time, it has lots of problems, including:
>> >
>> > - It has weak security, as it does not restrict applications accessing it
>> > by default, and even when it does, it does so simply based on application
>> > name which allows any malicious process to impersonate an allowed one
>> > - The initial setup has huge usability problems, as it forces users to
>> > make
>> > a choice on a very advanced technical level (encryption methods, no
>> > less!),
>> > and the option it suggests (GPG) is a nightmare to set up for ordinary
>> > users - It does support unlocking via PAM, but does not tell users what
>> > they need to do to make that work, which results in most users having to
>> > enter the KWallet password at each system start, which many find very
>> > annoying (we get lots of negative feedback for that)
>> > - It works only with KDE Frameworks-based applications
>> > - One cannot easily write a QML GUI for it, making it unsuitable for
>> > mobile
>> >
>> > Valentin has been working on KSecretService for quite a while, which is
>> > based on the freedesktop Secrets API [1] that is also supported in GNOME
>> > Keyring, and would solve many (and ideally all) of the above problems.
>> > However, Valentin told me he does not have the time to work on
>> > KSecretService any more.
>> >
>> > This means we have to find a solution to these problems. The options I see
>> > currently are
>> > - Improve KWallet (unlikely to fix all the problems without massive
>> > changes
>> > in it, though)
>> > - Find someone to finish and maintain KSecretService
>> > - Build a wrapper around one of the other existing keyring technologies
>> > - Each application (and each Plasma component that stores passwords)
>> > implements its own encrypted password storage
>> >
>> >
>> > - We make encrypted password storage optional and non-default (easiest
>> > solution, but not exactly in line with KDE's vision)
>>
>> I disagree on this point. Even if KWallet were free of usability
>> issues, it would still provide a false sense of security. The user
>> thinks that his/her passwords are safe, while in fact they are not.
>
> How exactly the passwords are not safe?

The default behavior is to keep wallets "open" once they have been decrypted.
If a wallet is open, any process can trivially retrieve clear-text
passwords from it using the KWallet API. I wanted to back my claim
with some code, so I created a small PoC in [1]. All an attacker has
to do is to guess the name of a wallet (and only if the default
'kdewallet' name is not used!).

I could also mention that KWallet accepts an empty master password,
which alone is already bad enough.

[1]: 
https://quickgit.kde.org/?p=scratch%2Felvisangelaccio%2Fkwalletleak-poc.git=tree

Cheers
Elvis

>
> Cheers,
>   Albert
>
>> If we don't have enough manpower to develop and mantain a proper
>> keychain in Plasma, we should tell our users. This way they can make
>> sure that, for example, the unsafely stored Wi-Fi passphrase is not
>> used for other accounts. This is already closer to our vision than the
>> current situation.
>>
>> My vote is: we either do it right, or we give up. If someone steps up
>> to fix this problem, great. Otherwise we should start to slowly port
>> away from KWallet.
>>
>> > So, what do we do?
>> >
>> > Cheers,
>> > Thomas
>>
>> Cheers,
>> Elvis
>>
>> > https://www.freedesktop.org/wiki/Specifications/secret-storage-spec/secret
>> > s-api-0.1.html
>
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: The situation of KWallet, and what to do about it?

[Albert Astals Cid]

El dimecres, 13 de juliol de 2016, a les 11:41:14 CEST, Thomas Pfeiffer va 
escriure:
> On Linux we could use GNOME Keyring, but if we don't want that, we'd of
> course still have to implement our own backend. 

We could implement our own backend, and call it ... kwallet? :D

SCNR

Cheers,
  Albert
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: The situation of KWallet, and what to do about it?

[Albert Astals Cid]

El dijous, 7 de juliol de 2016, a les 12:36:26 CEST, Thomas Pfeiffer va 
escriure:
> Hi everyone,
> I'm addressing both the Plasma team and kde-devel because this issue affects
> Plasma as well as many applications, and Valentin as the current maintainer
> of KWallet as well as KSecretService, a potential replacement for it.
> 
> KWallet plays a central role in Plasma and many KDE applications as the
> central password storage. However, it being very old and not having been
> actively developed for a long time, it has lots of problems, including:
> 
> - It has weak security, as it does not restrict applications accessing it by
> default, and even when it does, it does so simply based on application name
> which allows any malicious process to impersonate an allowed one

This is basically because "Linux sucks" and no other solution different than 
kwallet can do it better unless you go to a "full lockdown" mode of who and 
how you can start applications (i.e. like on the Ubuntu Phone only upstart can 
start applications).

Yes, it is unfortunate but it has to do with the fact that we don't control 
the OS we run on.

Cheers,
  Albert
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: The situation of KWallet, and what to do about it?

[Albert Astals Cid]

El dijous, 7 de juliol de 2016, a les 18:43:57 CEST, Elvis Angelaccio va 
escriure:
> Hi,
> thanks for raising this topic!
> 
> 2016-07-07 12:36 GMT+02:00 Thomas Pfeiffer :
> > Hi everyone,
> > I'm addressing both the Plasma team and kde-devel because this issue
> > affects Plasma as well as many applications, and Valentin as the current
> > maintainer of KWallet as well as KSecretService, a potential replacement
> > for it.
> > 
> > KWallet plays a central role in Plasma and many KDE applications as the
> > central password storage. However, it being very old and not having been
> > actively developed for a long time, it has lots of problems, including:
> > 
> > - It has weak security, as it does not restrict applications accessing it
> > by default, and even when it does, it does so simply based on application
> > name which allows any malicious process to impersonate an allowed one
> > - The initial setup has huge usability problems, as it forces users to
> > make
> > a choice on a very advanced technical level (encryption methods, no
> > less!),
> > and the option it suggests (GPG) is a nightmare to set up for ordinary
> > users - It does support unlocking via PAM, but does not tell users what
> > they need to do to make that work, which results in most users having to
> > enter the KWallet password at each system start, which many find very
> > annoying (we get lots of negative feedback for that)
> > - It works only with KDE Frameworks-based applications
> > - One cannot easily write a QML GUI for it, making it unsuitable for
> > mobile
> > 
> > Valentin has been working on KSecretService for quite a while, which is
> > based on the freedesktop Secrets API [1] that is also supported in GNOME
> > Keyring, and would solve many (and ideally all) of the above problems.
> > However, Valentin told me he does not have the time to work on
> > KSecretService any more.
> > 
> > This means we have to find a solution to these problems. The options I see
> > currently are
> > - Improve KWallet (unlikely to fix all the problems without massive
> > changes
> > in it, though)
> > - Find someone to finish and maintain KSecretService
> > - Build a wrapper around one of the other existing keyring technologies
> > - Each application (and each Plasma component that stores passwords)
> > implements its own encrypted password storage
> > 
> > 
> > - We make encrypted password storage optional and non-default (easiest
> > solution, but not exactly in line with KDE's vision)
> 
> I disagree on this point. Even if KWallet were free of usability
> issues, it would still provide a false sense of security. The user
> thinks that his/her passwords are safe, while in fact they are not.

How exactly the passwords are not safe?

Cheers,
  Albert

> If we don't have enough manpower to develop and mantain a proper
> keychain in Plasma, we should tell our users. This way they can make
> sure that, for example, the unsafely stored Wi-Fi passphrase is not
> used for other accounts. This is already closer to our vision than the
> current situation.
> 
> My vote is: we either do it right, or we give up. If someone steps up
> to fix this problem, great. Otherwise we should start to slowly port
> away from KWallet.
> 
> > So, what do we do?
> > 
> > Cheers,
> > Thomas
> 
> Cheers,
> Elvis
> 
> > https://www.freedesktop.org/wiki/Specifications/secret-storage-spec/secret
> > s-api-0.1.html


___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: The situation of KWallet, and what to do about it?

[Thomas Pfeiffer]

On 11.07.2016 22:29, Mark Gaiser wrote:
On Mon, Jul 11, 2016 at 9:58 PM, Thomas Pfeiffer > wrote:


On 07.07.2016 19:50, Kevin Ottens wrote:

There's two sides to that problem in fact, use from applications and the
service provided by our workspace.

I think that for applications the answer is neither KSecretService nor
KWallet, etc. For the goal of making it easier for our applications to 
be
shipped on more platforms, what we want in fact is to port them away 
from
anything platform specific to something like QtKeyChain:
https://inqlude.org/libraries/qtkeychain.html


This way, the actual storage becomes a workspace decision. That could 
keep
being KWallet if improved, or KSecretService, or a simple D-Bus service
wrapping libsecret... For sure it would at least simplify things on the
KWallet/KSecretService side, they wouldn't need to be frameworks anymore
(QtKeyChain or equivalent would play that role) just to expose a D-Bus 
API
(likely the Secret Service one in the end).


Oh, indeed, that would absolutely make sense! Deploying and using
applications which use KWallet outside of Plasma must be a pain right now.

So how do we make that happen? Deprecate the KWallet framework and
recommend to use QtKeyChain instead, and then in parallel decide which
bakcend to use for QtKeyChain in Plasma?


I don't get that. How is deprecating KWallet paves the way to make something 
new with QtKeyChain?


Of course deprecating KWallet alone does not do anything, but I think it will be 
necessary to "motivate" application developers to port away from it.


As far as i can tell, QtKeyChain isn't a keychain at all, it's a wrapper 
around platform specific keychains that provides a unified interface for 
keychain functionality. It itself doesn't implement a keychain (or it does on 
windows?).


Yes, QtKeychain wraps available keychains from the platform it runs on.
However: "Since Windows does not provide a service for secure storage QtKeychain 
uses the Windows API function CryptProtectData to encrypt the password with the 
user’s logon credentials. The encrypted data is then persisted via QSettings."


On Linux we could use GNOME Keyring, but if we don't want that, we'd of course 
still have to implement our own backend. The advantage would be that it would be 
much easier to replace that at any point without having to adapt applications.




Or do you mean deprecating/removing the *graphical* KWallet part and 
re-implementing that in top of QtKeyChain?


Yes, that's what I mean.


Using QtKeyChain would be interesting imho. Specially if that itself is 
extended to use other web backends as keychain.


Yes, that would be great!
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: The situation of KWallet, and what to do about it?

[Kevin Ottens]

Hello,

On Monday, 11 July 2016 20:51:43 CEST Sune Vuorela wrote:
> On 2016-07-07, Kevin Ottens  wrote:
> > There's two sides to that problem in fact, use from applications and
> > the=20
> > service provided by our workspace.
> 
> One issue that I'm a bit puzzled about is the following scenario:
> 
> A user uses KMail for emails.
> But switches between various desktop environments.
> 
> Would he need to configure KMail in all of them?

Depends how much effort we want to put into something like that really. Worst 
case scenario: he'd have to retype passwords in the various desktop 
environments. Best case scenario we magically find out that it'd find more 
passwords with a different backend and so nothing to retype.

Personally, I'd put no effort in dealing with that.

I have two reasons for that:
1) I don't think many users do that or should do that. Nowadays, most perceive 
the workspace as part of the OS stack.
2) On Linux, I'd expect those things to converge at one point (could be years 
of course[*]) and you'd have only one of the potential storages picked by the 
distro at installation, all the apps would use that one, whatever workspace 
you're running (talking about something I witnessed, I think it will be a bit 
like what happened with hardware detection: everyone has a wrongly designed 
solution, then hal emerged, then udisks and friends, everyone use those now).
 
Regards.

[*} But whatever solution we pick forward it'll take months to get there and 
be used by all our applications anyway.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud supporter of KDE, http://www.kdab.com



signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: The situation of KWallet, and what to do about it?

[Kevin Ottens]

Hello,

On Monday, 11 July 2016 21:58:34 CEST Thomas Pfeiffer wrote:
> On 07.07.2016 19:50, Kevin Ottens wrote:
> > There's two sides to that problem in fact, use from applications and the
> > service provided by our workspace.
> > 
> > I think that for applications the answer is neither KSecretService nor
> > KWallet, etc. For the goal of making it easier for our applications to be
> > shipped on more platforms, what we want in fact is to port them away from
> > anything platform specific to something like QtKeyChain:
> > https://inqlude.org/libraries/qtkeychain.html
> > 
> > This way, the actual storage becomes a workspace decision. That could keep
> > being KWallet if improved, or KSecretService, or a simple D-Bus service
> > wrapping libsecret... For sure it would at least simplify things on the
> > KWallet/KSecretService side, they wouldn't need to be frameworks anymore
> > (QtKeyChain or equivalent would play that role) just to expose a D-Bus API
> > (likely the Secret Service one in the end).
> 
> Oh, indeed, that would absolutely make sense! Deploying and using
> applications which use KWallet outside of Plasma must be a pain right now.

Never tried, but I'd suspect it is indeed.

> So how do we make that happen? Deprecate the KWallet framework and recommend
> to use QtKeyChain instead, and then in parallel decide which bakcend to use
> for QtKeyChain in Plasma?

Probably something like that yes. Note that I'm not sure how active the 
QtKeyChain project is right now, so that might be something to evaluate I 
guess.

> >> https://www.freedesktop.org/wiki/Specifications/secret-storage-spec/secre
> >> ts-> api-0.1.html> 
> > 0.1 being outdated, you probably want to link that one:
> > https://standards.freedesktop.org/secret-service/
> 
> Ah yes, indeed.
> 
> > Hope that somewhat made sense and helps.
> 
> It made sense to me at least :)

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud supporter of KDE, http://www.kdab.com



signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: The situation of KWallet, and what to do about it?

[Mark Gaiser]

On Mon, Jul 11, 2016 at 9:58 PM, Thomas Pfeiffer 
wrote:

> On 07.07.2016 19:50, Kevin Ottens wrote:
>
>> There's two sides to that problem in fact, use from applications and the
>> service provided by our workspace.
>>
>> I think that for applications the answer is neither KSecretService nor
>> KWallet, etc. For the goal of making it easier for our applications to be
>> shipped on more platforms, what we want in fact is to port them away from
>> anything platform specific to something like QtKeyChain:
>> https://inqlude.org/libraries/qtkeychain.html
>>
>
> This way, the actual storage becomes a workspace decision. That could keep
>> being KWallet if improved, or KSecretService, or a simple D-Bus service
>> wrapping libsecret... For sure it would at least simplify things on the
>> KWallet/KSecretService side, they wouldn't need to be frameworks anymore
>> (QtKeyChain or equivalent would play that role) just to expose a D-Bus API
>> (likely the Secret Service one in the end).
>>
>
> Oh, indeed, that would absolutely make sense! Deploying and using
> applications which use KWallet outside of Plasma must be a pain right now.
>
> So how do we make that happen? Deprecate the KWallet framework and
> recommend to use QtKeyChain instead, and then in parallel decide which
> bakcend to use for QtKeyChain in Plasma?


I don't get that. How is deprecating KWallet paves the way to make
something new with QtKeyChain? As far as i can tell, QtKeyChain isn't a
keychain at all, it's a wrapper around platform specific keychains that
provides a unified interface for keychain functionality. It itself doesn't
implement a keychain (or it does on windows?).

Or do you mean deprecating/removing the *graphical* KWallet part and
re-implementing that in top of QtKeyChain?

Using QtKeyChain would be interesting imho. Specially if that itself is
extended to use other web backends as keychain.

>
>
>
>>> https://www.freedesktop.org/wiki/Specifications/secret-storage-spec/secrets->
>>> api-0.1.html
>>>
>>
>> 0.1 being outdated, you probably want to link that one:
>> https://standards.freedesktop.org/secret-service/
>>
>
> Ah yes, indeed.
>
> Hope that somewhat made sense and helps.
>>
>
> It made sense to me at least :)
>
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: The situation of KWallet, and what to do about it?

[Thomas Pfeiffer]

On 07.07.2016 19:50, Kevin Ottens wrote:

There's two sides to that problem in fact, use from applications and the
service provided by our workspace.

I think that for applications the answer is neither KSecretService nor
KWallet, etc. For the goal of making it easier for our applications to be
shipped on more platforms, what we want in fact is to port them away from
anything platform specific to something like QtKeyChain:
https://inqlude.org/libraries/qtkeychain.html



This way, the actual storage becomes a workspace decision. That could keep
being KWallet if improved, or KSecretService, or a simple D-Bus service
wrapping libsecret... For sure it would at least simplify things on the
KWallet/KSecretService side, they wouldn't need to be frameworks anymore
(QtKeyChain or equivalent would play that role) just to expose a D-Bus API
(likely the Secret Service one in the end).


Oh, indeed, that would absolutely make sense! Deploying and using applications 
which use KWallet outside of Plasma must be a pain right now.


So how do we make that happen? Deprecate the KWallet framework and recommend to 
use QtKeyChain instead, and then in parallel decide which bakcend to use for 
QtKeyChain in Plasma?



https://www.freedesktop.org/wiki/Specifications/secret-storage-spec/secrets-> 
api-0.1.html


0.1 being outdated, you probably want to link that one:
https://standards.freedesktop.org/secret-service/


Ah yes, indeed.


Hope that somewhat made sense and helps.


It made sense to me at least :)
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: The situation of KWallet, and what to do about it?

[valentin rusu]

Hello,

Thanks for including this address in this thead. I'm curently on the go and 
I'll try to quicly reply here.

I confirm that I do not curently have lots of time and also there are all these 
KWallet problems that are built-in and require rewriting. You did a great job 
enumerating them here. Also, these last years we saw lots of others options 
out-there, questioning the very idea of implementing something like 
ksecretservice. I won't enumerate the options here but those listed by Kevin 
are only a subset of them. So, yeah, we should ask ourselves if we need a 
special password handling utility, and force users of some web-compatible 
solution out-there to adopt ours in addition to their preferred one.


On July 7, 2016 8:50:08 PM GMT+03:00, Kevin Ottens  wrote:
>Hello,
>
>On Thursday, 7 July 2016 12:36:26 CEST Thomas Pfeiffer wrote:
>> I'm addressing both the Plasma team and kde-devel because this issue
>affects
>> Plasma as well as many applications, and Valentin as the current
>maintainer
>> of KWallet as well as KSecretService, a potential replacement for it.
>> 
>> KWallet plays a central role in Plasma and many KDE applications as
>the
>> central password storage. However, it being very old and not having
>been
>> actively developed for a long time, it has lots of problems,
>including:
>> 
>> - It has weak security, as it does not restrict applications
>accessing it by
>> default, and even when it does, it does so simply based on
>application name
>> which allows any malicious process to impersonate an allowed one
>> - The initial setup has huge usability problems, as it forces users
>to make
>> a choice on a very advanced technical level (encryption methods, no
>less!),
>> and the option it suggests (GPG) is a nightmare to set up for
>ordinary
>> users - It does support unlocking via PAM, but does not tell users
>what
>> they need to do to make that work, which results in most users having
>to
>> enter the KWallet password at each system start, which many find very
>> annoying (we get lots of negative feedback for that)
>> - It works only with KDE Frameworks-based applications
>> - One cannot easily write a QML GUI for it, making it unsuitable for
>mobile
>> 
>> Valentin has been working on KSecretService for quite a while, which
>is
>> based on the freedesktop Secrets API [1] that is also supported in
>GNOME
>> Keyring, and would solve many (and ideally all) of the above
>problems.
>> However, Valentin told me he does not have the time to work on
>> KSecretService any more.
>> 
>> This means we have to find a solution to these problems. The options
>I see
>> currently are
>> - Improve KWallet (unlikely to fix all the problems without massive
>changes
>> in it, though)
>> - Find someone to finish and maintain KSecretService
>> - Build a wrapper around one of the other existing keyring
>technologies
>> - Each application (and each Plasma component that stores passwords)
>> implements its own encrypted password storage
>> - We make encrypted password storage optional and non-default
>(easiest
>> solution, but not exactly in line with KDE's vision)
>> 
>> So, what do we do?
>
>There's two sides to that problem in fact, use from applications and
>the 
>service provided by our workspace.
>
>I think that for applications the answer is neither KSecretService nor 
>KWallet, etc. For the goal of making it easier for our applications to
>be 
>shipped on more platforms, what we want in fact is to port them away
>from 
>anything platform specific to something like QtKeyChain:
>https://inqlude.org/libraries/qtkeychain.html
>
>This way, the actual storage becomes a workspace decision. That could
>keep 
>being KWallet if improved, or KSecretService, or a simple D-Bus service
>
>wrapping libsecret... For sure it would at least simplify things on the
>
>KWallet/KSecretService side, they wouldn't need to be frameworks
>anymore 
>(QtKeyChain or equivalent would play that role) just to expose a D-Bus
>API 
>(likely the Secret Service one in the end).
>
>>
>https://www.freedesktop.org/wiki/Specifications/secret-storage-spec/secrets->
>api-0.1.html
>
>0.1 being outdated, you probably want to link that one:
>https://standards.freedesktop.org/secret-service/
>
>Hope that somewhat made sense and helps.
>
>Regards.
>-- 
>Kévin Ottens, http://ervin.ipsquad.net
>
>KDAB - proud supporter of KDE, http://www.kdab.com
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: The situation of KWallet, and what to do about it?

[Kevin Ottens]

Hello,

On Thursday, 7 July 2016 12:36:26 CEST Thomas Pfeiffer wrote:
> I'm addressing both the Plasma team and kde-devel because this issue affects
> Plasma as well as many applications, and Valentin as the current maintainer
> of KWallet as well as KSecretService, a potential replacement for it.
> 
> KWallet plays a central role in Plasma and many KDE applications as the
> central password storage. However, it being very old and not having been
> actively developed for a long time, it has lots of problems, including:
> 
> - It has weak security, as it does not restrict applications accessing it by
> default, and even when it does, it does so simply based on application name
> which allows any malicious process to impersonate an allowed one
> - The initial setup has huge usability problems, as it forces users to make
> a choice on a very advanced technical level (encryption methods, no less!),
> and the option it suggests (GPG) is a nightmare to set up for ordinary
> users - It does support unlocking via PAM, but does not tell users what
> they need to do to make that work, which results in most users having to
> enter the KWallet password at each system start, which many find very
> annoying (we get lots of negative feedback for that)
> - It works only with KDE Frameworks-based applications
> - One cannot easily write a QML GUI for it, making it unsuitable for mobile
> 
> Valentin has been working on KSecretService for quite a while, which is
> based on the freedesktop Secrets API [1] that is also supported in GNOME
> Keyring, and would solve many (and ideally all) of the above problems.
> However, Valentin told me he does not have the time to work on
> KSecretService any more.
> 
> This means we have to find a solution to these problems. The options I see
> currently are
> - Improve KWallet (unlikely to fix all the problems without massive changes
> in it, though)
> - Find someone to finish and maintain KSecretService
> - Build a wrapper around one of the other existing keyring technologies
> - Each application (and each Plasma component that stores passwords)
> implements its own encrypted password storage
> - We make encrypted password storage optional and non-default (easiest
> solution, but not exactly in line with KDE's vision)
> 
> So, what do we do?

There's two sides to that problem in fact, use from applications and the 
service provided by our workspace.

I think that for applications the answer is neither KSecretService nor 
KWallet, etc. For the goal of making it easier for our applications to be 
shipped on more platforms, what we want in fact is to port them away from 
anything platform specific to something like QtKeyChain:
https://inqlude.org/libraries/qtkeychain.html

This way, the actual storage becomes a workspace decision. That could keep 
being KWallet if improved, or KSecretService, or a simple D-Bus service 
wrapping libsecret... For sure it would at least simplify things on the 
KWallet/KSecretService side, they wouldn't need to be frameworks anymore 
(QtKeyChain or equivalent would play that role) just to expose a D-Bus API 
(likely the Secret Service one in the end).

> https://www.freedesktop.org/wiki/Specifications/secret-storage-spec/secrets-> 
> api-0.1.html

0.1 being outdated, you probably want to link that one:
https://standards.freedesktop.org/secret-service/

Hope that somewhat made sense and helps.

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud supporter of KDE, http://www.kdab.com



signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: The situation of KWallet, and what to do about it?

[Elvis Angelaccio]

Hi,
thanks for raising this topic!


2016-07-07 12:36 GMT+02:00 Thomas Pfeiffer :
> Hi everyone,
> I'm addressing both the Plasma team and kde-devel because this issue affects
> Plasma as well as many applications, and Valentin as the current maintainer
> of KWallet as well as KSecretService, a potential replacement for it.
>
> KWallet plays a central role in Plasma and many KDE applications as the
> central password storage. However, it being very old and not having been
> actively developed for a long time, it has lots of problems, including:
>
> - It has weak security, as it does not restrict applications accessing it by
> default, and even when it does, it does so simply based on application name
> which allows any malicious process to impersonate an allowed one
> - The initial setup has huge usability problems, as it forces users to make
> a choice on a very advanced technical level (encryption methods, no less!),
> and the option it suggests (GPG) is a nightmare to set up for ordinary users
> - It does support unlocking via PAM, but does not tell users what they need
> to do to make that work, which results in most users having to enter the
> KWallet password at each system start, which many find very annoying (we get
> lots of negative feedback for that)
> - It works only with KDE Frameworks-based applications
> - One cannot easily write a QML GUI for it, making it unsuitable for mobile
>
> Valentin has been working on KSecretService for quite a while, which is
> based on the freedesktop Secrets API [1] that is also supported in GNOME
> Keyring, and would solve many (and ideally all) of the above problems.
> However, Valentin told me he does not have the time to work on
> KSecretService any more.
>
> This means we have to find a solution to these problems. The options I see
> currently are
> - Improve KWallet (unlikely to fix all the problems without massive changes
> in it, though)
> - Find someone to finish and maintain KSecretService
> - Build a wrapper around one of the other existing keyring technologies
> - Each application (and each Plasma component that stores passwords)
> implements its own encrypted password storage


> - We make encrypted password storage optional and non-default (easiest
> solution, but not exactly in line with KDE's vision)

I disagree on this point. Even if KWallet were free of usability
issues, it would still provide a false sense of security. The user
thinks that his/her passwords are safe, while in fact they are not.
If we don't have enough manpower to develop and mantain a proper
keychain in Plasma, we should tell our users. This way they can make
sure that, for example, the unsafely stored Wi-Fi passphrase is not
used for other accounts. This is already closer to our vision than the
current situation.

My vote is: we either do it right, or we give up. If someone steps up
to fix this problem, great. Otherwise we should start to slowly port
away from KWallet.


>
> So, what do we do?
>
> Cheers,
> Thomas

Cheers,
Elvis


>
>
> https://www.freedesktop.org/wiki/Specifications/secret-storage-spec/secrets-api-0.1.html
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: The situation of KWallet, and what to do about it?

[Luca Beltrame]

In data giovedì 7 luglio 2016 13:17:12 CEST, Martin Graesslin ha scritto:

Hello Martin,

> Adding some more:
[...]

I think we should not forget that there's kwallet (the framework) and 
kwallet{manager} (the frontend).

I also think that Kwallet is very much ingrained in a lot of KDE software, so 
that rules out (IMO) the option for a drastic change there. I do believe, as 
Thomas stated, that we *need* to have a wallet available in the workspace. 

That said, some review would be in order in particular with regards to the 
encryption used (see the recent breakage that occurred "just" fixing a compiler 
warning).

(FYI, I'm using Kwallet with a GPG-based YubiKey, but I agree this is *not* an 
acceptable, or easy enough, solution for our userbase),

> - if one doesn't unlock the wallet fast enough applications start asking for
> the password. So getting a coffee while desktop starts results in thousands

This is no longer the case, IIRC dfaure has raised the timeout to 45 minutes.

> For Plasma I would like to see unlocking the wallet integrated into the
> desktop shell in some way. That would fix problems like the incorrect

That would mean probably having Plasma providing a sort of "frontend" to the 
framework? To be honest, I have no idea if there's any separation of GUI and 
wallet layers in the kwallet-framework code.


-- 
Luca Beltrame - KDE Forums team
KDE Science supporter
GPG key ID: A29D259B

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: The situation of KWallet, and what to do about it?

[Martin Graesslin]

On Thursday, July 7, 2016 12:36:26 PM CEST Thomas Pfeiffer wrote:
> Hi everyone,
> I'm addressing both the Plasma team and kde-devel because this issue affects
> Plasma as well as many applications, and Valentin as the current maintainer
> of KWallet as well as KSecretService, a potential replacement for it.
> 
> KWallet plays a central role in Plasma and many KDE applications as the
> central password storage. However, it being very old and not having been
> actively developed for a long time, it has lots of problems, including:
> 
> - It has weak security, as it does not restrict applications accessing it by
> default, and even when it does, it does so simply based on application name
> which allows any malicious process to impersonate an allowed one
> - The initial setup has huge usability problems, as it forces users to make
> a choice on a very advanced technical level (encryption methods, no less!),
> and the option it suggests (GPG) is a nightmare to set up for ordinary
> users - It does support unlocking via PAM, but does not tell users what
> they need to do to make that work, which results in most users having to
> enter the KWallet password at each system start, which many find very
> annoying (we get lots of negative feedback for that)
> - It works only with KDE Frameworks-based applications
> - One cannot easily write a QML GUI for it, making it unsuitable for mobile

Adding some more:
- kwallet dialog allows keyloggers on X11 (in defence of KWallet, I only know 
of pinentry which handles this properly at the cost of severely degraded user 
experience)
- kwallet does not protect against ptrace (I didn't add the protection, due to 
the keylogger rendering it point less)
- kwallet dialog windows sometimes are placed at the bottom of the stack due 
to focus stealing prevention (this happens for example with akonadi/other 
daemons)
- kwallet shows total giberish like "kded requested to open the wallet"
- if one doesn't unlock the wallet fast enough applications start asking for 
the password. So getting a coffee while desktop starts results in thousands of 
password windows.

> 
> Valentin has been working on KSecretService for quite a while, which is
> based on the freedesktop Secrets API [1] that is also supported in GNOME
> Keyring, and would solve many (and ideally all) of the above problems.
> However, Valentin told me he does not have the time to work on
> KSecretService any more.
> 
> This means we have to find a solution to these problems. The options I see
> currently are
> - Improve KWallet (unlikely to fix all the problems without massive changes
> in it, though)
> - Find someone to finish and maintain KSecretService

how much work is still needed?

> - Build a wrapper around one of the other existing keyring technologies
> - Each application (and each Plasma component that stores passwords)
> implements its own encrypted password storage
> - We make encrypted password storage optional and non-default (easiest
> solution, but not exactly in line with KDE's vision)

For Plasma I would like to see unlocking the wallet integrated into the 
desktop shell in some way. That would fix problems like the incorrect stacking 
order and we can easily protect against keyloggers, etc. Especially on Wayland 
I would like KWin having more control of entering passwords (KWin should know 
that a password is entered and make it impossible to steal focus then).

Cheers
Martin

Now going to use the secure pinentry, by clicking send

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

The situation of KWallet, and what to do about it?

[Thomas Pfeiffer]

Hi everyone,
I'm addressing both the Plasma team and kde-devel because this issue affects 
Plasma as well as many applications, and Valentin as the current maintainer of 
KWallet as well as KSecretService, a potential replacement for it.


KWallet plays a central role in Plasma and many KDE applications as the central 
password storage. However, it being very old and not having been actively 
developed for a long time, it has lots of problems, including:


- It has weak security, as it does not restrict applications accessing it by 
default, and even when it does, it does so simply based on application name 
which allows any malicious process to impersonate an allowed one
- The initial setup has huge usability problems, as it forces users to make a 
choice on a very advanced technical level (encryption methods, no less!), and 
the option it suggests (GPG) is a nightmare to set up for ordinary users
- It does support unlocking via PAM, but does not tell users what they need to 
do to make that work, which results in most users having to enter the KWallet 
password at each system start, which many find very annoying (we get lots of 
negative feedback for that)

- It works only with KDE Frameworks-based applications
- One cannot easily write a QML GUI for it, making it unsuitable for mobile

Valentin has been working on KSecretService for quite a while, which is based on 
the freedesktop Secrets API [1] that is also supported in GNOME Keyring, and 
would solve many (and ideally all) of the above problems.
However, Valentin told me he does not have the time to work on KSecretService 
any more.


This means we have to find a solution to these problems. The options I see 
currently are
- Improve KWallet (unlikely to fix all the problems without massive changes in 
it, though)

- Find someone to finish and maintain KSecretService
- Build a wrapper around one of the other existing keyring technologies
- Each application (and each Plasma component that stores passwords) implements 
its own encrypted password storage
- We make encrypted password storage optional and non-default (easiest solution, 
but not exactly in line with KDE's vision)


So, what do we do?

Cheers,
Thomas


https://www.freedesktop.org/wiki/Specifications/secret-storage-spec/secrets-api-0.1.html
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel