[kde] Kmail passwords
Hi All I have a problem that is annoyin to say the least I older versions of Kmail it would very happily store the mail passwords in the config file now it does not althou i tell it to store them system versions as in sig block but just in case KDE Development Platform: 4.7.4 (4.7.4) 64 bit every time i close down the system and restart it i have to re enter ALL the passwords for Kmail (thats 11 passwords) . I do not like the Kwallet thing and do not wish to use it at allhow do i convince Kmail to behave Thanks pete . -- Powered by Kernel: 3.2.1-1-ARCH KDE Development Platform: 4.7.4 (4.7.4) 18:40:41 up 4:32, 5 users, load average: 0.00, 0.01, 0.05 ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
Re: [kde] Kmail passwords
On Monday, 2012-01-23, Duncan wrote: Meanwhile, of course, with 4.8 kde is introducing the new ksecrets framework, designed to be api compatible with gnome-keyring (tho the backends are different), Just to clarify: secret service is actually a new API for services providing secure local storage. One implementation of such a service is gnome-keyring, though a lot of GNOME based programs still use the old, gnome-keyring specific, API. There is some progress on a KDE based implementation for both the service and the client part of a secret service setup. The service component will at some point be run as part of a KDE workspace setup, offering its services to any client application developed for the secret service API. The client library will allow KDE applications to access any other service implementation, e.g. when the KDE application is running in a setup which uses gnome-keyring as the storage service. The KWallet API will be implemented in terms of the new API, thus making KWallet using applications use the currently running secret service. and over the next several kde versions, it's likely various apps will switch to ksecrets from kwallet, leaving kwallet deprecated, altho I'm guessing it'll remain available thru the kde4 series. Indeed. But whether it'll be in kde 5 or whether ksecrets will take over for kde5 and they'll drop kwallet, remains to be seen. I don't think this is a question of if. It is more a question of whether we will see a stand-alone or shared service implementation being used by common workspace setups. In any case this won't change anything for the thread starter until there is a service implementation that does not store the data in an encrypted file but in plain text based file(s). Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
Re: [kde] [Okular-devel] [Bug 267350] filling out a PDF form saves data to some file i ~/.kde/share/apps/okular/docdata/
On Tuesday, 2012-01-17, Duncan wrote: Kevin Krammer posted on Sun, 15 Jan 2012 18:08:31 +0100 as excerpted: On Sunday, 2012-01-15, Dan Armbrust wrote: Hmm. Most software with autocompletion support does that. E.g. browsers, email programs. They also ask your permission first. Interesting. Neither Konqueror, Firefox, KMail or Thunderbird have asked me whether I wanted to store form data. Can you attach a screenshot of an application asking that? I don't know about asking, but it's a preferences setting. I was mainly puzzled by the fact that there are obviously applications asking for it versus just being a switchable preference. Would be interesting to see how that question looks like. There's also the private browsing or whatever the app decides to call it, mode, where everything (cookies, form completion, browsing history, etc) is forgotten, tho that normally has to be specifically toggled on. Indeed, hence the suggestion to pursue a form completion data handling similar to those examples. And they have an off switch. And, they definitely don't autocomplete fields which are know to contain private info - aka - passwords. Unless you go through another dialog telling it to remember the password. And they give you a menu option to clear it. And, most browsers now have a don't remember anything mode. Okular has none of those. Right, hence the recommendation for lobby for an implementation doing that. Actually, I wonder if this idea could get a bit more traction in view of the new ksecrets thing? Unlikely, this is just a new implementation of already existing functionality. The currently proposed KSecret API is also still a bit weird ;-) That's where I'd try to take it at this point, since ksecrets IS new and shiny and fascinating! =:^) Not from an application developer's point of view, sorry :-) However I don't see any facts supporting the claim of virus like behavior. Hiding users data without permission and without the users knowledge certainly is virus like behavior. No, virus behavior is attaching itself with the purpose of distribution and spreading. I don't think Okular is doing either. It seems he's using virus not in the technically narrow virus sense, but in the broader malware sense, inclusive of trojans, etc. If storing data to prefill form fields would be considered malware, people would have a hard time browsing the Internet since malware removal tools would have deinstalled all incarnations of browsers already. While okular really can't be considered a virus in the technically narrow sense (as you pointed out), certainly, the argument here is that it's behaving like a trojan, so if one accepts an extremely fuzzy definition of virus that really means something more like malware in general. I' am still not convinced. How does Okular behave like a trojan? What is the function it is pretending to do in order to hide the function it was designed to do and which function would that be? I would recommend lobbying for secure storage of form completion data like other form completing programs do. I doubt it would help. I wouldn't be so sure. Same here, particularly with the new ksecrets angle to explore. If I were an okular dev I think I might jump on this one just for the opportunity to play with that! =:^) My take is that asking for a more secure implementation of a feature, especially since there are role models for how that works, has magnitudes more chances of being considered worth while than asking for removable of a feature that is considered useful by others inspite of not ideal implementation. BTW, Kevin, any wild guess or informed opinion on how long kde4 will continue with the semi-annual feature updates, given kde5 in the wings? My guess is at least 4.10 but I find even 4.11 likely. An important fact here is that while during KDE4 times the split of names or terminology around KDE products was mostly cosmetic, KDE5 will very likely make actual use of the new disambiguation. The current work on KDE frameworks is not only a matter of making KDE libraries less interdependent, it also serves as a starting point for separation of development cycles. I.e. it is almost certain that there will be a release of KDE frameworks before any of the KDE application products are rebased onto them. Some application developers will of course starting to port earlier, e.g. when technolog preview releases become available, but that will largely depend on specifiy API usages of those apps (applications using fewer APIs or only very core APIs can expect fewer changes between a TP release and the final one). Of course as others have said, I expect kde5 to be a rather minor deal compared to kde4, and that it'll be handled rather better. An extremely important difference IMHO is that while there will be some changes in implementation (e.g. due to
Re: [kde] [Okular-devel] [Bug 267350] filling out a PDF form saves data to some file i ~/.kde/share/apps/okular/docdata/
If storing data to prefill form fields would be considered malware, people would have a hard time browsing the Internet since malware removal tools would have deinstalled all incarnations of browsers already. One minor point. A PDF viewer is not web browser. Its much more like a document editor. That is how users expect it to behave - like other document editors. Don't you suppose folks would find it a little unsettling if LibreOffice just silently saved anything you typed into it, without asking, in a hidden location, every time you even opened a document with it? Because that is exactly what Okular does. I only brought the webbrowsers into the conversation to point out that other software that stores user data for auto-form filling always gives the user control over said data. My take is that asking for a more secure implementation of a feature, especially since there are role models for how that works, has magnitudes more chances of being considered worth while than asking for removable of a feature that is considered useful by others inspite of not ideal implementation. And another point. Nobody has stepped forward to defend the current feature. Because the feature, in its current form is almost completely useless. The only possible thing I can think of that it does is not lose your work if you close Okular, go out to lunch, then come back and continue working. But storing your work - aka - filled form data for any significant amount of time? No. Its useless. You don't even know where it stored it. You can't back it up. You can't tie it to the actual document you were working on. You can't send it to anyone else. The feature does more harm than good. It would be better if it didn't even give the illusion of allowing you to save data typed into form fields - because it doesn't. It doesn't even _tell_ you that it didn't actually put the data into the form. You won't find out until you send the document to a coworker, and they tell you it is blank. The only thing this feature will lead to is a horrible user experience. That was why I suggested just shutting it off. Or redirecting it to /dev/null. But the maintainers of Okular refuse to even talk about it. So, here we are, 2 years later, with it still behaving in the same brain-dead way. ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
[kde] Trees wont expand / collapse in some apps?
Has anyone else noticed that tree views no longer expand or collapse properly with mouse clicks in some applications? I first noticed this in Eclipse - see this bug for a better write up - https://bugs.eclipse.org/bugs/show_bug.cgi?id=368297 - but now I have also noticed that it impacts other applications like Handbrake. Strangely, tree views still work properly in Dolphin. ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
Re: [kde] [Okular-devel] [Bug 267350] filling out a PDF form saves data to some file i ~/.kde/share/apps/okular/docdata/
Kevin Krammer posted on Mon, 23 Jan 2012 01:43:30 +0100 as excerpted: My guess is at least 4.10 but I find even 4.11 likely. An important fact here is that while during KDE4 times the split of names or terminology around KDE products was mostly cosmetic, KDE5 will very likely make actual use of the new disambiguation. The current work on KDE frameworks is not only a matter of making KDE libraries less interdependent, it also serves as a starting point for separation of development cycles. Thanks. I had read hints about kde5 and seen mentions of kde frameworks, but really had little clue on kde5 and about zero on frameworks, so your answers and informed opinion here gave me quite a bit to chew on. Meanwhile, the educated guess about 4.10 almost certainly and 4.11 probably... at least gives me enough feel of the situation so I don't feel quite as out there speculating about say 4.11 as a time-frame. It seems your feel for where 4.x goes in terms of versioning isn't /that/ far from where I was thinking, since 4.10 seemed reasonably safe, and 4.11 a good chance, tho I suspect (as I think I said) that the 6-month releases may slow a bit by the time it comes out as the focus switches to 5/frameworks. And the point about the 34 dcop/dbus switch (among other service changes in that version bump) not reoccurring with 45/frameworks makes sense. I had seen the same general point expressed before, but your wording of it seemed clearer, either because I /had/ seen the point before so you got the benefit of repetition, or because it /was/ clearer, I can't rightly say which. Actually probably some of both! =:^) Beyond that, there's enough new there that as I said, I'll have to chew a bit to absorb it, tho at this point I'm inclined to say I agree with what I understand of it so far. Thanks again! =:^) -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
Re: [kde] Trees wont expand / collapse in some apps?
Dan Armbrust posted on Sun, 22 Jan 2012 20:04:33 -0600 as excerpted: Has anyone else noticed that tree views no longer expand or collapse properly with mouse clicks in some applications? I first noticed this in Eclipse - see this bug for a better write up - https://bugs.eclipse.org/bugs/show_bug.cgi?id=368297 - but now I have also noticed that it impacts other applications like Handbrake. Strangely, tree views still work properly in Dolphin. AFAIK, eclipse is java based, not kde or even qt, and handbrake gtk based, so why would you be asking about them on a kde mailing list, when as you said yourself, the only kde-based app you mention, dolphin, continues to work just fine? I'd suggest asking on either your distro's lists/forums or possibly those of gtk/gnome, as this wouldn't appear to be kde related at all. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
