In this week's KDE CVS-Digest (experimental layout): KDevelop adds extension support.
Kommander improves signal and slot editor.
Kwallet is now asynchronous.
JuK adds support for GStreamer 0.8.
KPasswordDialog adds password strength meter.
Dot Categories:
Comments
Great to see that Kwallet is now asynchronous, now I only have just one tiny wish : make Kwallet usable. Allowing a passwordless wallet could just do that.
http://bugs.kde.org/show_bug.cgi?id=78505
1) Kwallet was always asynchronous. Just KHTML didn't use the asynchronous interface. That's what I added this week.
2) Passwordless wallets was committed about 10 minutes ago. It's still unbeleivably stupid to use such a thing though. Maybe in a few weeks I'll release tools for automated downloading passwordless wallets in a stealth fashion (think: Linux spyware). Should be fun.
About password-less wallet, as it is told in the bug report, it's a security feature that do not have sense in some cases. What about the option to leave the wallet opened? If someone could access your desktop, he will get every password of yours.
And if someone could get his hands over an unprotected wallet, well, he have already broken your ~ security walls.
But what if somebody happens to be root or otherwise have read access to the wallet without having to break any security walls? In that case this guy can also use the stored data, if the wallet is not password-protected.
And even if somebody breaks in from the internet, why should this mean that everything is lost anyway so just let him open the wallet?
Why not make pgp keys with no passphrases then? If somebody already has gained access to my hard disk/wherever i keep my key, why not also let him use it? :)
But what if somebody happens to be root or otherwise have read access to the wallet without having to break any security walls? In that case this guy can also use the stored data, if the wallet is not password-protected.
And even if somebody breaks in from the internet, why should this mean that everything is lost anyway so just let him open the wallet?
Why not make pgp keys with no passphrases then? If somebody already has gained access to my hard disk/wherever i keep my key, why not also let him use it? :)
If someone is root on your system, they could just install a keylogger and get your password when you next login.
Do you know of any key [free] logger for Linux? I'd like to get my hands on one.
Woohoo!!, thanks a lot! (and at the same time shame on you, because of you I now can't wait until kde 3.4 is released). KDE 3.4 is going to be awesome, new kpdf, improved khtml and passwordless kwallet, just to name a few.
How realistic is it that wallet can be downloaded from my computer? Only by using an exploit (somewhere else)? How secure are other passwordless wallets (e.g. Firefox, IE)?
> How secure are other passwordless wallets (e.g. Firefox, IE)?
Let me refrase that question; how easy can other passwordless wallets be downloaded from my computer (e.g. Firefox, IE)?
> shame on you
Your nice words are truly appreciated.
wow, you don't know what a joke (although a little bit sarcastic) is, right?
Please don't quote a half sentence and rip it out of the context.
If you read the entire sentence (before hitting reply) you see that I really appreciate his work.
LOL, maybe he was being sarcastic too.
I also can't wait for 3.4 btw. Though I am quite pleased with 3.3.1.
> It's still unbeleivably stupid to use such a thing though.
I second that. I don't even understand why this is added. You can already configure KWallet to ask for the password just once for the whole KDE session, already insecure and easy enough IMO.
Best regards,
> I don't even understand why this is added.
Some people care more about usability then security.
Considering that providing a password once during your whole KDE session makes the whole thing unusable is the very kind of reasoning which made Windows the virus trashcan it is now.
Simplifying things as Windows did made the users get a lot of bad habits. I don't think it's a good idea at all for Linux to make the same mistake.
Best regards,
Hello,
please understand that at work many of us don't have any secret passwords at all. In many cases, the passwords are for not-exactly public downloads for and from subcontractors, shared support database accounts, identifications of myself for the intranet email, etc.
None of this is secret because I have to have no privacy at work.
So why protect it with a password?
See it this way, privacy is good and there I want to protect my passwords very well. I wouldn't save my private passwords at work though. There kwallet is only something to save me time. Even entering the password once or twice a day is wasted time in my use case.
At home I see your point.
Yours, Kay
Se my bug report [92826]: http://bugs.kde.org/show_bug.cgi?id=92826
Nevermind :-|
The reason KWallet has passwords isn't to annoy the user, it's to encrypt the password file on the hard disk. So what happens if (God-forbid), your computer gets hacked, and some random cracker gets access to all of the passwords in your wallet file. Now all the subcontractors that you have access to have been put into danger because it's too hard to type a password once per session. :(
If you need people at work to know your passwords, just give them your passwords. But there's no reason nowadays to have any kind of sensitive information sitting on your hard disk in plaintext.
So although I'm not going to fault George for implementing this, I think it's a bad idea.
Regards,
- Michael Pyne
If someone have access to your password file, he could easily bruteforce it in a few days, so if a cracker gain access to your home directory, you are alredy f*cked.
The weak point, in this case, is not the password-less wallet but the rest of the system. And anyway, noone is asking for an only-passwordless wallet a-la IE, we are only asking for an option (even with a big red warning reminder saying it's your OWN risk and NOT activated by default) to use it.
Hello,
I repeat: These are not exactly high profile secrets being exchanged. It's more an issue of making things not anonymous ftp but rather login protected. Or giving people the chance to identify themselves in their postings on support database.
Nothing at risk there, often the password is designed to be easy to remember, sometimes even more or less obvious to guess.
If you are not working on calls for tender, or doing something like accouting, management and stuff, you don't have anything secret, but still a lot of passwords to deal with. I guess it's like 10 in my case.
So what. Why not just work well in this context and don't bother me with things at all.
Kay
Because KWallet is _a pain in the ass_. After KMail also started using it, it locks up the desktop on bootup, which mean entering two passwords every time I log in (how does that make sense?). If someone breaches my local-account I have a lot bigger problem than loosing the low-security passwords kept in KWallet.
So turn it off, like it gives you the option to do right when you first run it? You sound like Homer Simpson at the batting cage. Constantly being hit by baseballs but not knowing enough to just move out of the way.
George, you hit the nail right on the head! Keep it up.
Cb..
George, why not a pam module or something similar for kwallet instead of passwordless mode? That way the user can enter one password on login, instead of likely the same password twice. (They may be different, but usually not.)
Cheers,
Sheldon.
I completely agree. I would love to have this as an option. Just a pam module that the sysadmin has to put in himself to take the first password and ATTEMPT to unlock the wallet with it on login. Is this possible?
You guys have to start to think about what provides security and what doesn't.
Hasseling the user doesn't increase security.
If you ask for a password once per KDE-session and the wallet is open for the whole session, there is ABSOLUTELY NO DIFFERENCE from a security POV compared to no password at all.
It's just a little bit more annoying which seems to give some people the delusion that when it's annoying, it must also be secure.
Which of course is pure nonsense.
> If you ask for a password once per KDE-session and the wallet is open for the
> whole session, there is ABSOLUTELY NO DIFFERENCE from a security POV compared
> to no password at all.
Sorry, but this is UNTRUE. It seems you did not consider all the use cases.
If I left my workstation with my screen lock on (or if it's just off), what would you try in order to get to my plaintext passwords? If there's no password you could just boot the machine from a CD, for example, and get my unencrypted kwallet, if there is a password you would still need to crack it.
And what about the rest of your home files? Why aren't you using an encrypted filesystem if you are living in a such unsecure environment and your data has to be protected?
What does that have to do with the fact that the two situations
a) passwordless kwallet and
b) encrypted kwallet with infinite timeout
are not equal under all scenarios? Roland said they were and I disagreed.
What I meant if that some untrusted one have phisical access to your box, you're not safe at all, KWallet with password or without
> You can already configure KWallet to ask for the password
> just once for the whole KDE session
Considering our uptimes, isn't this just as "stupid"? I don't consider it "stupid" either way, though. I personally don't use kwallet, but that's not my point. It's a great life-saver for people that it applies to (and, as has been pointed out, for general "useability"). So either save it "forever", or for days/weeks/etc. What's the difference?
M.
> It's still unbeleivably stupid to use such a thing though.
I for one think self proclaimed "security experts" are unbelievably stupid for thinking there are no other concerns than security.
Maybe you are smart enough to realize that some people don't give much about having their slashdot account compromised.
Maybe you are smart enough to realize that some people are the only ones who use their personal accounts and don't install unoffical software?
> Maybe you are smart enough to realize that some people don't give much about having their slashdot account compromised.
> Maybe you are smart enough to realize that some people are the only ones who use their personal accounts and don't install unoffical software?
Maybe these people should be smart enough to disable KWallet if they don't need it? Some people are smart enough to actually take advantage of the fact that KWallet encrypts passwords on disk, which makes KWallet useful for more that just storing Slashdot passwords.
Yes, but if I disable KWallet I have to remember all my passwords, and this is not definitely usable.
Passwordless wallets maybe are a bit more insecure, they're a hell of a lot more usefull. I personaly hate it that everytime I fire up something that accesses KWallet I have to give my password. Yes, I do use the "remember password this session"-option, but it still is one time too many.
Apple's Keychain is great in that aspect: you don't see it, but it's just there in the background unlocked when I log in. That's what KWallet should be: invisible.
Isn't it possible to unlock the wallet the same way Keychain does it: when I log in? That way it would stay secret for other users yet be convenient to use.
I really enjoy your work btw, wish I could do what you can.
Would it be possible for KWallet to look in a plugged in USB Flash keychain so people could plug in their key and then all of their KWallet information is released? That way when you pull out the keychain KWallet will check for the key and it won't be there and no access
but when you have the key plugged in, each time KWallet wants to use information stored in it, it will check the USB keychain for the PGP key and if its there it will allow the user to access the information..
does this sound like a good idea? It would be the best feature ever IMO.... I know at least the people I work with would adopt something like this for better security and more convenience (and coolness factor of unlocking your computer with a USB Key)
:)
What if KWallet would use PAM (which would use pam_ssh)? With the right setup you can already just enter the passphrase of your private key in ~/.ssh/ to login to you computer. pam_ssh then launches ssh-agent so that you´ll never have to enter your passphrase again when it´s needed.
Now if KWallet would support PAM you´d only have to login once at system startup! And ssh-agent should be considered to be save, shouldn´t it?
And yes, this would be even better than the password-less wallet, cause it would take the best from the 2 choices
I´ve created a wishlist item in the KDE bug databse: http://bugs.kde.org/show_bug.cgi?id=92845
what kde/kdm/X really needs is a login where you select from a user name tied to a private, password protected key at the login screen which is used to encrypt every small (under a meg, configurable?) file in your home directory, or the directory itself. Including all stored passwords, config files, ect. And if you then felt the need you could have other ssh keys passwordless in your file system, or use the same login key from X.
If anyone knows how to do anything like this please post.
"Same thing for myint == 0, this is more readable than !myint"
Actually I have mixed feelings about this. And I explain. When working with Logic everyone simplifies P <=> True to P, and P<=>False to ~P. It actually makes things much easier to read. Also in Pascal and other languages, students are taught to simplify P = True to P and P = false to not P.
So why do I have mixed feelings about it? Because David Faure actually as a point in the context of C/C++/Matlab etc, which (unfortunately) mix booleans and integer datatypes. Lets look at booth versions of the code for P integer (k-n) and P boolean (k>n).
1a) while (k-n){...} // P is an integer
2a) while (k>n){...} // P is a boolean
1b) while (k-n == 1){...} // P is an integer
2b) while (k>n == 1){...} // P is a boolean
I expect most people to agree that 2a) and 1b) are the easiest to read. Only this ones would typecheck in languages that do not mix booleans with integers. In C++ you can also have
2b') while (k>n == true){...}
which would typecheck too, but which is not more readable then 2a).
"1b) while (k-n == 1){...} // P is an integer"
Opss, make that
1b) while (k-n != 0){...} // P is an integer
I think readable may have much to do with the context. There may be a large number of conditions that are checked, and being more verbose can help the feeble mind keep it all straight.
It is a matter of style. Some prefer one way, others prefer another.
Reminds me of a story from my youth. My father had a garage full of tools that he used to feed us hungry hordes. It seemed disorganized and random until I took something to use. I would put it back on the nearest flat surface, and invariably my father would ask where it was. He had a system which made little sense to anyone else, but it worked for him.
Derek
Yes, of course I understand you ;) I don't think this is the case though. Your examples reflect my own reasoning:
You say "isNull()" is ok, for instance. Well, this is a boolean expression. It's also easy to read "!isNull()", right?
Then you stated:
"Same thing for myint == 0, this is more readable than !myint, when the int
can take several values and we're only testing against 0 here, but maybe
1 and 2 later on. There is nothing to gain by writing !myint here, only loss of readability."
"Several values" reflects usage of "actual" integer values, not booleans. In this case you suggest not using them as booleans.
You also say:
"But changes like
- while ( ( wdg = it.current() ) != 0 ) {
+ while ( ( wdg = it.current() ) ) {
don't make it faster, and do hurt readability (the changed line looks to me
like it might be a typo for wdg == it.current(), whereas the original line
didn't have that problem."
Why doesn't the original line doesn't have that problem? Couldn't it be?
while ( ( wdg == it.current() ) != 0 )
Maybe because, since it's a boolean expression you'd write it like:
while (wdg == it.current())
Bools as Ints are just a very old and poor design decisions, which just add to the confusion with no benefits whatsoever. We can avoid them on our own, but it's a shame the compiler won't help.
> 1a) while (k-n){...} // P is an integer
> 2a) while (k>n){...} // P is a boolean
These are not equivalent. A while loop will iterate will the expression is != 0. So, it should be:
1a) while (k-n){...} // P is an integer
2a) while (k!=n){...} // P is a boolean
> 1b) while (k-n == 1){...} // P is an integer
> 2b) while (k>n == 1){...} // P is a boolean
These are nowhere near equivalent. 2b) is true for many (k,n) pairs for which 1b) is false.
Regards,
- Michael Pyne
Yes, I did correct that ;)
http://dot.kde.org/1099721820/1099742242/1099742691/
I see that JuK has added GStreamer support. However it is GStreamer 0.8. My distro (which was released ealy 2004) has only GStreamer-0.6. Why are not GStreamer version <0.8 supported? It is the same with amaroK (it's worse with amaroK CVS as aRts support is completely broken)
Is aRts dead for KDE 3.4?
JuK has had GStreamer support for years. It was GStreamer 0.6 until this update; I just updated the bindings to use 0.8. GStreamer 0.8 came out in March and it's relatively easy to install it side-by-side with 0.6.
For whatever reason, juk never picks up gstreamer in my /usr/local/lib