> 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.
> 
> Thomas Lübking wrote:
>     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)

cryptsetup will crypt all the partition so I/O speed will get decreased a lot.

KWallet does only one thing, preventing access to clear text password for cases 
like a stolen laptop, anything else is a false sense of security.

For the "app access" there is a patch already on the way: 
https://git.reviewboard.kde.org/r/110330/ and I voted to enable it by default.

So, Imho KWallet still has a reason to exists and we should not break it or 
make it easier to break specially since it can be properly fixed with a PAM 
module that I already know how to do (so I will do for 4.12).


- Àlex


-----------------------------------------------------------
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
> 
>

Reply via email to