Kernel Traffic
Latest | Archives | People | Topics
Wine
Latest | Archives | People | Topics
Git
Latest | Archives | People | Topics
Czech
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Sleeping Cousins
 

KDE Traffic #20 For 10 Aug 2001

By Aaron J. Seigo

Table Of Contents

Introduction

Welcome to KC KDE! KDE2.2 has been released and is now in use by untold numbers of users while the KDE development team plunges forward towards KDE3. While the transition from KDE2 to KDE3 will not be nearly as breathtakingly large (and painful) as that from KDE1 to KDE2, it will still be a significant step forward. This is especially true when it comes to the underlying libraries and their APIs. So while the end users may not directly see many of the improvements, developers should be given an even more consistent and powerful framework than they have at their disposal today. For the users, this library shake-up will translate into a better overall desktop experience.

At the sime time, since the libraries are merely getting an overhaul and not a complete rewrite, application development continues unabated. KDE3 will therefore have the usual number of new features and improvements in the applications that everyone has come to expect in a new release. We hope you enjoy this issue in which we cover several of these developments!

1. State of Javascript in Konqueror

31 Jul 2001 - 2 Aug 2001 (9 posts) Archive Link: "HeirMenus Status Report"

Topics: Konqueror, JavaScript

People: David Joham

Ask KDE users what the weakest link in Konqueror's web browsing technology chain is and many, if not most, will say "Javascript". While the rendering engine already has terrific support for HTML and CSS (and continues to improve) the Javascript engine has not moved as far or as quickly. This isn't to say that it isn't being worked on. Indeed, forward progress can been seen with each release. There is still a ways to go to bring it to the level of support seen in Internet Explorer or Netscape, but that distance is being traversed by the hard work of the kjs developers.

Menus and other GUI elements implemented in Javascript are probably one of the greatest torture tests imaginable for a Javascript implementation, so it was heartening to see David Joham report on HeirMenu and Konqueror:

I thought I would let you all know how the attempt to get the JavaScript HeirMenus working in Konqueror is going.

My current code is at http://www.kimanddavidforever.org/jsmenus/LoadMe.html. You'll note that almost everything is working! Actually, at this point, the code is almost useable in Konqueror. Here's the list of action items from my last Email and their status:

*still to go*

The biggest issue that is facing me now is that Konqueror seems to lose references to its objects a lot. For example, if you go the page above and click on the word "Experts" in the top menubar, you'll get a nice drop down. Scroll through the list for a bit and then move your mouse to the word "Contents". Konqueror should "roll up" the Experts menu and highlight the Contents menu in black. What happens is that I get a JS error at the console that states "JS: Type error. Undefined value".

I can't figure this one out. Mozilla and IE do not have this problem (or at least don't tell me about it). I'm at a little bit of a loss as to what to do. Actually, the main reason for this post is to see if I can't get someone else to take a quick look at the code from Konqueror's JavaScript perspective and let me know if they see anything that might clue us in. Until this gets fixed, the menus are of rather limited use.

One last thing, sometimes it just works in Konqueror. I'll be debugging and trying new things and viola! Everything is great. The error goes away and everything functions just like it should. This usually happens after debugging for a while and after I put in a try catch block around something. However, if I shut Konqueror down and restart *without changing the code* it will usually fail again on the next try. Very frustrating. I get this behavior maybe in one out of a hundred reloads of the page.

David went on to list the may items that had been fixed on the road to getting HeirMenus to work properly in Konqueror along with some known issues that were yet to be addressed. So, while things still aren't perfect, development is moving in the right direction. Kudos to all the kjs developers!

2. Web Form Autocompletion and Sensitive Data

1 Aug 2001 - 3 Aug 2001 (47 posts) Archive Link: "Outstanding critical issue for KDE 2.2"

Topics: KDE 2.2, Security, Auto Form Completion

People: Waldo BastianAndreas PourMoritz Moeller-HerrmannGeorge StaikosKurt GranrorthKurt Granroth

Those in the Linux, BSD and Unix camp often pride themselves on the security of their systems. Securing a server is one thing, but keeping a desktop secure is another matter. This is due to the difference in usage patterns, sophistication of the average user, and the shear diversity of tasks a desktop must accomplish. Just prior to KDE2.2 being rolled out, Waldo Bastian noted one "show stopper" that required fixing. He detailed the problem saying, " I believe that information typed into forms on secure websites (https) can end up on the hard-disk due to auto-completion. This may mean that credit-card information may end up on places where the user does not expect it, which is an unacceptable situation."

It was suggested the autocompletion simply be disabled on SSL secured web forms altogether. Andreas Pour offered his viewpoint saying, " Is that perhaps overkill? From what I gather, passwords are already protected, and the only other item we are concerned about is credit card numbers. Well, those are relatively easy to identify: '^[0-9 -]{6,}$' (this net is too large as well but I would think most other forms with over 5 chars have at least one alpha character). Maybe just disable if that regex matches? I think we will get 1,000,000 bug reports saying "form completion does not work sometimes", and really it would not be unreasonable to consider complete disabling of auto-completion based on http/https a UI bug." With some tweaking the regular expression Andreas suggested was extended to be more inclusive.

However, the debate over what path to actually take continued. Moritz Moeller-Herrmann said, " I very much like not having to type in my account number when I am banking, my hidden password is still safe, my hard disk is not accissible by anyone else. I would hate losing the comfort, please make it an option. Default to off and have people edit the configuration file to switch it on. Fix it in KDE-2.2++" On the other side of that fence George Staikos, who is responsible for much of the SSL and cryptographically signed certificate support in KDE, offered his viewpoint saying, " We have a contract to the user that his data is entirely encrypted except for in RAM when that lock icon appears. If it is not being encrypted, we are liable. It is 100% our fault in that case."

Kurt Granroth offered his view on the matter with the following overview:

Somebody earlier said that "security is not optional". Bullshit. There always has been and always will be a tradeoff between convenience and security... the trick is finding the right balance between the two. Unfortunately, finding the balance is tricky because there are such divergent opinions on how to handle this. You can tell that's the case when the mythical User steps in. As in, "The User wants this" or "The User wants that".

The fact remains is that all sides to the arguement are right. There are loads of users that haven't the first clue where their data is stored locally nor do they care. They simply want their form completion to work as expected. Then there are tons of users that know the security implications of storing sensitive data to disk and want nothing to do with it. Both user opinions are valid and they effectively cancel each other out.

Really, the only long term solution to this that I can see is Yet Another Option. Something like:

Enable Form Completions ( ) Always ( ) Only on unencrypted pages

The other long term option involves having the user enter some password during every browsing session and encrypting the data to disk. I speak for myself when I say that hell will freeze over before I enter a password before all of my browsing sessions (convience vs security again).

Right now, due to the imminent release of KDE 2.2, we are in a no-win situation. If we keep the code as it is right now (doesn't store numbers, stores some other data depending on how the form is coded), we will piss off a decent amount of people who don't want this. If we disable autocompletion for SSL sites, we will piss off an entire other set of people who except it to work always. *sigh*

FWIW, I think we should release as-is. It's more secure than what IE does (the only other place people are used to autocompletion on the web) and should fail only in rare cases. After 2.2, we can beef it up and do it the Right Way.

It was suggested that the language Kurt proposed for the options be strengthened to reflect the trade-off between security and convenience. Of course, one can always simply turn autocompletion off.

3. KIOSlaves for SCP and SFTP

4 Aug 2001 - 6 Aug 2001 (6 posts) Archive Link: "kio_scp"

Topics: KIO, IOSlave

People: David SweetMarc MutzLucas FisherRob Kaper

David Sweet announced:

I started working on the KIOSlave code to implement an scp:// protocol. The goal is to be able to do secure file management on a remote machine (to replace ftp:// in my normal use).

I use ssh and standard shell commands (ls, cat, chmod for example) to get the information needed to implement methods like stat(), listDir(), get(), chmod(), and so on and it's working well so far. Unfortunately, because of work and other projects I just don't have the time to finish kio_scp.

If you're is looking for a project and would like to continue development of kio_scp, I'd be really happy about it (as might others; see http://dot.kde.org/search?body=scp for example). Information is available at http://www.andamooka.org/~dsweet/NYLUGTalk/kioscp.html and the code is at http://www.andamooka.org/~dsweet/NYLUGTalk/kioscp-0.1.tgz

Marcos Dione expressed interest in working on kio_scp while Rob Kaper asked if this KIOSlave was even necessary since there is a kio_sftp in the kdenonbeta CVS module. Marc Mutz said, " There are many implementations deployed that don't have sftp support. scp, however, is older and thus more widely available." With regard to the sftp slave Lucas Fisher said, " The kio_sftp slave is in the kdenonbeta module of the kde cvs server. Right now it works with the latest openssh. I'm working on a class for an version independent interface to as many versions of ssh as possible. This still needs a lot of work." The sftp slave in CVS now supports several ssh versions thanks to Lucas' work.

As more and more KIOSlaves are being written it is becoming apparent that there will be no shortage of them, but It does raise the question of how to organize and manage them as their numbers continue to grow.

4. aRts, soundcardless systems and i18n

5 Aug 2001 (6 posts) Archive Link: "[PATCH] graceful artsd behaviour without soundcard"

Topics: aRts, i18n

People: Stefan WesterfeldStephan KulowThomas DiehlWaldo BastianRalf Nolden

Since aRts is a multimedia architecture supporting more than just sound, one would expect it to run even if a sound device was not available. Until recently this was not the case, as Stefan Westerfeld noted in an email saying, " The most end user visible issue with artsd in KDE2.2 until now probably was that if you had no soundcard, it would now violently complain about this, and an average user might not know what to do about it at all. As artsd would not start without soundcard, for instance noatun would have problems even playing videos without sound, as it absolutely requires artsd to run. The following patch tries to introduce more graceful behaviour."

Waldo Bastian asked if the messages that aRts produced were translated, to which Stefan said, " They are never translated - it's a big shortcoming of artsd right now, that there are no i18n at all anywhere. It doesn't link against kdecore, which is a reason why it's not simply "plug it in and be done". In this particular case, it also saves me from being killed by the translators." Both Ralf Nolden and Thomas Diehl noted that this obviously wasn't acceptable and asked what it would take to fix it and if such a fix could be accomplished for 2.2.1. Stephan Kulow answered this succinctly, " Definitly not. It would require bigger changes."

5. Maildir Support in KMail

6 Aug 2001 (4 posts) Archive Link: "Committing maildir support now?"

Topics: KMail

People: Kurth GranrothKurt Granroth

KMail has seen at least one major feature enhancement in each KDE release, such as IMAP support in KDE2.2. The KMail in KDE3 will be no different. Some time ago Kurt Granroth wrote a patch that gave KMail native support for maildir storage, however it wasn't ready in time to commit before the CVS froze in preparation for releasing 2.2. With that freeze gone however, Kurth Granroth posted to the kmail list saying,

Okay, now that the CVS freeze is done, does anybody object to me committing my (rather massive) changes to give KMail native maildir support?

I've been using the code for some months now with a mixture of maildir and mbox ("local") mailboxes and have had no significant problems. Current KMail users shouldn't notice any difference at all in using KMail.

I've kept my version of KMail pretty well synced up with the main branch. That is, at least once a week, I did a 'cvs update' and then resolved all the merging problems. This ensured that I always had the most up to date fixes on the main KMail. Before I commit any of my code, I will obviously do this again.

And just to reiterate, you will *NOT* have to stop using KMail for any length of time after the commit since the mbox support is functionally IDENTICAL.

6. Yet Another KDevelop Branch

7 Aug 2001 (5 posts) Archive Link: "branch for kdevelop"

Topics: KDevelop, Gideon

People: Roland KrauseRalf Nolden

KDevelop has received wide acclaim as a capable and useful IDE. It could well be the best IDE that is available under an Open Source license today. Version 1.4 was a milestone for KDevelop and 2.0 was a port to KDE2 of that version. Once that was accomplished, development was refocused on large functionality improvements. This effort was code-named Gideon and the bulk of new development has been happening within this branch.

That was to change though when yet another branch was opened by Roland Krause as a short term bridge between 2.0 and the future Gideon release. There was concern that this meant Gideon was being abandonned. However, Roland explained his intentions saying, "the group of developers has split into two fractions. A few people, including me, have decided to integrate kate as the text editor into the current codebase. Ralf agreed that this could be released as KDevelop-2.2 in time with KDE-2.2.1." ... " my priority" [is] " to have a functional IDE, that best suits my needs is currently best accomplished by improving KDevelop-2.0."

KDevelop developer Ralf Nolden supplied his take on the new branch saying, " that the main development *IS* gideon/HEAD, not KDevelop 2 any more. If someone wants to write patches to that or additions to a "dead" branch, I can't keep anyone off to do that. So if Roland is maintaining that inside the CVS, I'm fine with that and another KDevelop bugfix/feature release can be officially done to support the companies and developers who need a fully operational system right away. For new developers though who want to work on kdevelop, I suggest to work on gideon. I myself will stick to gideon now as well as the 2.0 release was the deadline and will be the deadline for the old branch as far as the "big thing" (tm) goes. So there's actually not a splitting, Roland just wants to spend some time hacking up stuff that he thinks didn't get ready for 2.0 and put that in place. Whatever everyone pleases."

So while Gideon may be a superior product, it does have a ways to go yet before it can be called stable and released. In the meantime users of KDevelop will get another stable release in the 2.x line. This is a good example of how a divergence of opinions in a project, when handled properly, can actually benefit the user both in the short and long term.

 

 

 

 

 

 

Sharon And Joy
 

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.