Review Request 110328: Add config option to silently create initial password-less wallet

[Thomas Lübking]

> On May 25, 2013, 5:25 p.m., Àlex Fiestas wrote:
> > I'm 100% against this patch, it is a no go.
> > 
> > What we have to provide is a way for distributions to open the wallet in a SECURE way without asking the user for a password. Distros are free to use this patch but then they should rename kwallet because it won't be doing what it was design to do.
> 
> Rex Dieter wrote:
>     By that logic, kwallet shouldn't support password-less operation *at all*, yet it does.  (In case its not obvious, I don't agree with your assertions).   That said, discussion of the security implications should best be made onlist, not on reviewboard.
> 
> Àlex Fiestas wrote:
>     There is a proper way of doing this which is opening the wallet (and creating it if not created already) with a PAM module. Anything else is just a hack. Feel free to start a discussion about this on list, but until then this patch has my -1.
>     
>     BTW I looked into the PAM module, it is easy to do and I will do it for 4.12 (was going to do it for 4.11 but it was already frozen).
> 
> Àlex Fiestas wrote:
>     Oh and btw, NO, kwallet should NOT support pasword-less operations at all, and if it does is because we lack PAM integration I guess.

You can either trick the GUI to enter an empty password or edit the config by hand.

---

Kwallet however does not do what it suggests (to me) anyway.
At least if that was anything different from what cryptsetup alongside pam_mount would do (less annoyingly) - which may already be in use to protect plaintext stored passwords (of other applications)

I don't say a higher level of security and authorization is required to protect joe users fartbook login, but atm. kwallet just suggests a level of security that it does not nearly provide - with a pretty annoying lock on top of the pretty weak door.
This would implicitly solve by dropping the pseudo-security and casually have the system provide the required (or nearby not, in the "single user at home" case) and actually present security (encrypted FS)

Otherwise (if kwallet wants to be beyond that) there's quite some workload (*far* beyond PAM) ahead (starting with clients having to authorize themself... not really a trivial task - esp. not if you cannot use the binaries hashkey because users won't like to reconfirm all clients after every update)


- Thomas


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/110328/#review33135
-----------------------------------------------------------


On May 6, 2013, 5:25 p.m., Eike Hein wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/110328/
> -----------------------------------------------------------
> 
> (Updated May 6, 2013, 5:25 p.m.)
> 
> 
> Review request for KDE Runtime and Harald Sitter.
> 
> 
> Description
> -------
> 
> This patch adds a UI-less config option to kwalletd that makes it create the initial local wallet silently with an empty password instead of prompting the user to enter one.
> 
> It's a change desired by downstream consumers Kubuntu and Netrunner, and perhaps others, and recreates a modification they used to carry for KDE 3. Their goal is to make KWallet mostly invisible to the user during routine operations, but still have users benefit from encrypted password storage behind the scenes.
> 
> As such the config option is intended to be set by distributions. The new behavior is disabled by default.
> 
> In the interest of keeping the delta between upstream and downstream as small as possible I'd say it makes sense to pick this up.
> 
> 
> Diffs
> -----
> 
>   kwalletd/kwalletd.h e8e74c3 
>   kwalletd/kwalletd.cpp fa9fc11 
> 
> Diff: http://git.reviewboard.kde.org/r/110328/diff/
> 
> 
> Testing
> -------
> 
> Test package for Kubuntu by Harald Sitter, operation verified at runtime.
> 
> 
> Thanks,
> 
> Eike Hein
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20130616/f3033435/attachment.htm>