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!

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

KF5 Kolourpaint

[Albert Vaca]

Hi,

A few weeks ago I was playing with Kolourpaint's sources (I used it as a
test package to port it to Windows), and I think the frameworks branch is
ready to be merged into master.

Is there any reason this can't be done? Is the project just unmaintained?

I wouldn't mind being the maintainer (it probably doesn't need too much
attention) if required.

If nobody disagrees I will merge frameworks into master before 16.08
dependency freeze so the next release can be Qt5-based.

Albert

Re: KF5 Kolourpaint

[Christoph Feck]

> If nobody disagrees I will merge frameworks into master before
> 16.08 dependency freeze so the next release can be Qt5-based.

Kolourpaint is maintained by Martin Koller, he is still doing commits. 
Please ask him about the status before merging.

Christoph Feck

Re: KF5 Kolourpaint

[Luigi Toscano]

On Wednesday, 13 July 2016 18:32:57 CEST Albert Vaca wrote:
> Hi,
> 
> A few weeks ago I was playing with Kolourpaint's sources (I used it as a
> test package to port it to Windows), and I think the frameworks branch is
> ready to be merged into master.
> 
> Is there any reason this can't be done? Is the project just unmaintained?
> 
> I wouldn't mind being the maintainer (it probably doesn't need too much
> attention) if required.
> 
> If nobody disagrees I will merge frameworks into master before 16.08
> dependency freeze so the next release can be Qt5-based.
> 

Afaik it was mentioned in the past and the blocker missing was the Qt5 version 
of qimageblitz. 

-- 
Luigi

Re: KF5 Kolourpaint

[Jeremy Whiting]

Which seems to be waiting on me. I have written rules for qimagblitz
to migrate it from svn to git, but when I try using them
svn-all-fast-export crashes. I probably put something wrong in the
rules that's causing this, but can't seem to see what it is. I'll poke
Nicolas to see if he can take a look and find my mistake. Once
qimageblitz is in git we can release a Qt5 version of it and then
Kolourpaint's kf5 branch can be merged to master.

Sorry for the holdup, I just need to kick myself and get this done.

Jeremy

On Wed, Jul 13, 2016 at 11:05 AM, Luigi Toscano
 wrote:
> On Wednesday, 13 July 2016 18:32:57 CEST Albert Vaca wrote:
>> Hi,
>>
>> A few weeks ago I was playing with Kolourpaint's sources (I used it as a
>> test package to port it to Windows), and I think the frameworks branch is
>> ready to be merged into master.
>>
>> Is there any reason this can't be done? Is the project just unmaintained?
>>
>> I wouldn't mind being the maintainer (it probably doesn't need too much
>> attention) if required.
>>
>> If nobody disagrees I will merge frameworks into master before 16.08
>> dependency freeze so the next release can be Qt5-based.
>>
>
> Afaik it was mentioned in the past and the blocker missing was the Qt5 version
> of qimageblitz.
>
> --
> Luigi
>
>

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

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

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

Re: KF5 Kolourpaint

[Martin Koller]

On Wednesday 13 July 2016 18:32:57 Albert Vaca wrote:
> Hi,
> 
> A few weeks ago I was playing with Kolourpaint's sources (I used it as a
> test package to port it to Windows), and I think the frameworks branch is
> ready to be merged into master.
> 
> Is there any reason this can't be done? Is the project just unmaintained?
> 
> I wouldn't mind being the maintainer (it probably doesn't need too much
> attention) if required.
> 
> If nobody disagrees I will merge frameworks into master before 16.08
> dependency freeze so the next release can be Qt5-based.

For the records: I merged the frameworks branch into master yesterday.
(I'm the current maintainer)

-- 
Best regards/Schöne Grüße

Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?

()  ascii ribbon campaign - against html e-mail 
/\- against proprietary attachments

Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at

Usage of QNetworkAccessManager

[Ben Cooksley]

Hi all,

Just my regular reminder regarding usage of QNetworkAccessManager in
your applications and libraries, especially when it comes to
interacting with kde.org infrastructure.

Unfortunately, from it's first iteration in Qt 4 QNetworkAccessManager
was shipped with a severe and fundamental defect in that it does not
follow HTTP redirects by default. Due to Qt behavioural and other
compatibility promises they can never change this behaviour, not even
in Qt 6.

Please therefore ensure your application handles redirects
appropriately (the form of the code will depend on the version of Qt
in use) if you decide to use QNAM.

Failure to do so can, depending on your code, lead to crashes or hangs
within your applications. If I recall right the Qt Installer Framework
(Qt 4) crashes when it encounters a redirect (it caused the Necessitas
SDK installer to crash anyway).

Not handling redirects restricts the ability of Sysadmin to change
infrastructure as needed - so please ensure you get this right.

If you'd like to avoid all of this: just use KIO - which gets it right
and handles redirects out of the box for you.

Cheers,
Ben