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