In this week's KDE-CVS-Digest:
KHotKeys now has a GUI. KOrganizer now supports todo attachments.
Kexi has a PostgreSQL driver. Bug fixes in KHTML layer support and
rendering engine. Many bugfixes in KMail,
Kopete and
KOrganizer.
Dot Categories:
In this week's KDE-CVS-Digest:
KHotKeys now has a GUI. KOrganizer now supports todo attachments.
Kexi has a PostgreSQL driver. Bug fixes in KHTML layer support and
rendering engine. Many bugfixes in KMail,
Kopete and
KOrganizer.
Comments
Also, is Kexi scheduled to officially debut in koffice 1.4?
It's planned to be released "when it's ready", independent from a KOffice release.
this is corretly only partly.
what we do want to do is releasing a first technical preview before koffice 1.4 (which might be koffice 2.0) somewhen mid jannuary and the next not 1.3 koffice release.
lucijan
I'm looking forward to having a KDE password repository, but from what I've heard about KWallet, some people don't like it. Is it ready for release? Does it have a nice simple GUI that doesn't get in your way, and is it well-integrated with KDE?
Don't rely on [outdated] opinions of other people, try it yourself!
I'm not going to go to all the hassle of compiling KDE just to try out KWallet. (OTOH, if you can point me to .deb packages of a recent KDE CVS that I can install concurrently with my working KDE 3.1, I'd be happy to try them out, but I think I'd have heard of such a thing already if it existed...) I don't want to rely on outdated opinions of other people, I'd much rather rely on up-to-date opinions of other people. ;-) Hence the question.
If you're not going to then you have no reason to complain.
Oh come on. Are you being dense on purpose? I'm not complaining, I'm asking. There's a difference. Plus, I don't see why compiling KDE is a prerequisite to complaining about KDE. Constructive criticism from users is and should be welcomed by the KDE team.
Compiling is no prerequisite but being a user of something you criticise.
try the orth's cvs debs (see http://opendoorsoftware.com/cgi/http.pl?p=kdecvs) while there not installable next to working kde 3.1, they all depend on kde-cvs snapshot and are thus easily removed should you experience real problems (hasn't happened yet, as he takes care to only do snapshots when cvs is relatively stable)
Hey, cool. I might give those a try. I better back up my ~/Mail and ~/.kde first though.
good idea =)
cvs has been pretty unstable over the last few weeks for me.. but it was rock stable in the beginning of october. It's starting to stabalize again though, as beta1 is coming.
Firstly, to answer your question, I quite like KWallet. It's really useful and well integrated with quite a few KDE apps. Secondly, there are debs of kde-cvs. AFAIK orth does them. I dunno when to find them though. Hope this helps you
In the version I've tried, KWallet is a usability nightmare, it asks for the password all the time and I couldn't find a way to turn that off.
Perfect would be if it would ask for the password only once per KDE-session.
But I'm confident that that will be fixed in KDE3.2-final or 3.2.1
that's what it does in the current kde-cvs ask for password only once per session .
KWallet asks me for a password very often, for example whenever I start Kopete (and when I restart Kopete I have to enter the password again), when I login on a website for the first time in this KDE session and when I login using a FTP or HTTP authentication for the first time in a KDE session.
I really do not like this, after logging in to KDE the wallet should give the passwords to an application without of asking me, if it has been the same application that stored the password!
In a "Perfect World (TM)" I think it
shouldn't ask to _enter_ a password
but ask me if I want to "spend" the
password from my wallet in some system dialog box
which cannot be automatically answered by ANY application
(it should be in some special protection layer if that
makes any sense)
This is much safer than completely automatically spending
the password. Even if it can't have a special protection
I would prefer this solution in contrast to not being asked
at all or asked to enter the password at first login.
I'd be very suspicious if I'm playing Kolf and suddenly something
is requesting my banking site password. This would make the whole
thing much less prone to trojan attacks.
Don't know if this is planned to be implemented or already implemented
in CVS though.
Read my posting again, I think the password should only be given to an application if it has been stored by this application! So if Kopete wants to access my website form passwords this should be denied (or alternatively I should be asked whether I want to allow it).
I understood that but one website might access passwords of a totally
different website anyway because they all run in Konqueror.
Or some app might pretend to be Konqueror and temporarily replace it.
Mmm, come to think about it, there are a lot of security issues...
Well, I'm quite sure the KDE developers will finally get to a solution that
can be trusted - they are certainly a lot more savvy about all those
security pitfalls than I am. And the fact that it's open source ensures
that it won't be the dreaded "security by obscurity" solution.
Hi,
how do you identify the application in a reliable way?
Yours, Kay
I'd say by it's location, because to exchange an application you usually need to be root. Well, this of course means that you have to trust your administrator...
Use gpg or some form of tickets. Similar to the way services authenticate against kerberos servers...
"once per session" is already annoying...
Agreed, I want to use my computer without entering any password. Is this annoying mandatory "once per session" going to disapear?
Another agreement. I just want KWallet to let me save usernames and passwords in a secure manner, so people can't get them off the hard disc. People already have to login to see my information come up without a password; that's plenty of security for me.
Without a password storing anything in a secure manner is not possible. All you can do is obscure data, e.g. by encrypting with a password that's stored in the source code or in another file. But for anyone who has access to the source code/the other file and your obscured data it's a trivial task to "decrypt" your data.
Simply use an empty password if entering a password annoys you.
Thanks for your reply. I don't mean I don't want to have a password, but I already enter one when I log in Linux. I don't want to enter another password for kwallet. Is it possible to use my linux account/password automatically with KWallet?
One way to achieve something like that would be Kwallet integration into KDM, 'spying' the password from there. I don't know whether that's such a good idea though.
As John Herdy said, I don't think you quite understood what I meant. I don't want to have to use a password at all with KWallet; it seems like an unecessary fuss for me. I am quite happy with Mozilla's behaviour, whereby once you've logged in, you can launch Mozilla and have access to all of the data you've allowed it to store, so you go to a site with a login form and ther username and password are automatically filled in without any extra fuss.
I don't want to have to login, start up KDE and then put in another password to make KWallet work. The login authentification is plenty for me.
> I don't want to have to login, start up KDE and then put in another password > to make KWallet work. The login authentification is plenty for me.
same.. after it prompts for the password once, it should have a checkbox IMHO that says "Fill In Passwords Automatically".. kwallet as of cvs two weeks ago was just down right annoying because of this. We are all pretty much on multi-user systems, so the only times I should have to put in passwords imho is in login :)
I second that.
Not inputting any password for KWallet would equal to allow KWallet to save all passwords in clear text, I can't imagine anyone really wanting that. The other solution I mentioned above, taking the password you input when logging in into the system, is risky as well since that would allow one further app to see strictly confidential passwords in clear text, risking both the user account and the KWallet password collection at once.
To save yourself from inputting two passwords a session how about allowing your user to login without password or even automatically while keeping the password collection in KWallet secure by actually using a password for that?
I think KWallet is quite nice - both the idea as such and how it's been done so far.
What would be quite cool is if one would be able to store passwords on a Smartcard. (Ever heard of ActivCard? They have something similar...)
Maybe it's just me and this is even already possible... ;-) (I suppose a conventional USB memory stick should work, but I didn't try/investigate).
I'm more interested on what kwallet is based. I really don't need a "kde only" secure password container.
Is there anything for it to be based on anyway?
Sure - databases & encryption software. I really don't know if there is anyone, who wrote a lib and cmd tool for this purpose; But I think a widely accessible lib rary would be far better, than a isolated kde solution.
http://www.gnomedesktop.org/pollBooth.php?op=results&pollID=46
:-)
Its a GNOME website isn't it?
And anyway, I too think that OO.org is the best in terms of features, but Koffice has great advantages when it comes to integration, speed and ease of use.
well, duh.. it's at gnomedesktop, and koffice 1.3 isn't out yet, which has a much better kword =)
I live with hundreds of minor annoying bugs in 3.1 and like most people I'm not in a position to file a bug report about them. The KDE development process just doesn't cater for it. The chances are they've mostly been fixed in HEAD but we don't have time to compile the whole of CVS (+break my current installation) just to check for that odd one which might slip through to 3.2.
I look forward to the first binary (.deb) release so the rest of us can see the great progress that the l33t h4x0r's slap us down for not appreciating, and maybe even file a few bug reports....
(any chance of a milestone release structure next time guys?)
oh yeah, and great work on khotkeys, which sorely misses a GUI in 3.1!
Don't understand why you're not in a position to file a bug report I'm afraid. Why do you say that?
By not filing the reports there is a chance the bugs will still be there in 3.2, you know?
I've got issues with KWin mouse focus, konqueror tabs and (every day) more and more websites rendering.
But those are all issues I know have been addressed in HEAD, and I hope very much totally fixed.
There never were and never will be "binary releases" from KDE: http://www.kde.org/download/packagepolicy.php
I've read it and it says:
«we work with various third-parties to ensure that as many binary packages as possible are built.»
Then you have also read "The KDE Project itself only releases and supports the source code packages." That KDE helps other to create packages doesn't make them the maintainer of them.
Hi,
then use Konstruct. If you know which -dev packages you need to install that's an easy way to run KDE 3.2 Alpha2. Soon Beta 1 will be out and I will update with it. I doubt there will be official debs before the final release.
The Alpha2 has substantial usability bugs. Kontact, KWallet are not usable yet. Konqueror has a few problems in part related to rendering, in part to Authentification and so on. But I still love it over 3.1 for its speed and usability.
Yours, Kay