Kernel Traffic
Latest | Archives | People | Topics
Wine
Latest | Archives | People | Topics
GNUe
Latest | Archives | People | Topics
Czech
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic
 

KDE Traffic #52 For 25 May 2003

By Russell Miller

Table Of Contents

Introduction

Greetings, welcome to issue #52. As of next weel, kfm-devel will join the list of lists that will be reported on. This week I'm beginning to report on interesting threads in The Dot (though there are none this week. Aaaand.. this week we get a newsflash. Well, it's a nice, cool, and sunny holiday weekend here in Iowa, and I want to spend as little of it indoors as I possibly can, so on with the show...

Mailing List Stats For This Week

We looked at 670 posts in 2928K.

There were 209 different contributors. 108 posted more than once. 88 posted last week too.

The top posters of the week were:

1. Newsflash!

 Subject: "Newsflash!"

And, in the tradition that Juergen started, and I'm happy to continue, we have - NEWSFLASH. *cue newsy music here*

Dateline - KDE. KDE 3.1.2 has been released. Looks like there are lots of neat bugfixes and a few nice security fixes. I'm looking forward to 3.2 myself - I'll let you know where that stands as soon as people leave the thread alone long enough for me to report on it. :P :)

Fabrice Mous has asked me to make a quick note on KDE fundraising. Although KDE is a volunteer-run organization, KDE e.V could always use some extra funds for various (and, I'm sure, legitimate :-)) purposes. If you have any suggestions on how this could be accomplished, I'm sure they'd be happy to hear from you. If anyone would care to let me know what kind of things raised funds could be used for, I'll be glad to post that feedback in a future newsflash. And buying coolo a new car is definitely NOT something I will put in here. :-)

I was pointed to an interesting kde-related website here. A little (well, a lot) sparse on content, but anything that pokes good natured fun at the KDE developers/apps we all know and love is ok in my book. Maybe if we poke at the authors a little more or send contributions it'll rise up from the dead. If you've got other interesting sites, feel free to let me know. If I like them, they'll get a mention here.

2. KSSL based S/MIME plugin available

9 May 2003 - 16 May 2003 (25 posts) Archive Link: "KSSL based S/MIME plugin available"

People: Stefan RompfBernhard ReiterMark MutzWaldo BastianIsmail Donmez

This thread took place on kmail and kde-core-devel.

Stefan Rompf said:

I've committed my KSSL based S/MIME crypto plugin to kdenonbeta/kssl-smime. The README is attached to this mail.

Everybody who uses a recent KDE from CVS and S/MIME might be interested. Comments and suggestions are welcome.

To which Bernhard Reiter responded:

Just reading the README it is openssl based and links to it. This would mean there is licensing problem.

AFAIK openssl's license is not compatible with the GNU GPL.

KMail is under GNU GPL thus cannot be linked together. Wether this is done by a loadable module or not does not make a huge difference in tjhis case.

If someone distributes a binary with that module and openssl that person will most likely violate KMail's license and which would subsequently permanently (until the license holder of KMail explicitely forgive that) loose the right to use KMail.

This is the one of the reasons why the Agypten project wrote its own S/MIME implementation.

To which Mark Mutz replied:

This thread prompted me to check gnutls' status again.

They've finally made it LGPL and beta instead of GPL and alpha. It seems to appraoch v1.0.0 rapidly now (check the ChangeLog). It even supports OpenPGP certificates for TLS (though that part of the library is GPL).

The only issue I can see is that they seem to have no support for SSLv2 (and that they need testing, which a gnutls-using konq would surely provide en masse).

So, maybe it's finally time to get rid of OpenSSL and it's problems? IIRC, even George was swearing about the OpenSSL's BIC and licensing issues.

To which Waldo Bastian replied:

I think it would be a good idea to at least add support for gnutls then, yes. kssl opens openssl dynamically, so it should be feasible to do the same with gnutls and select the actual library to use at runtime.

Oh joy, I love them already: "Additionaly GnuTLS provides an emulation API for the widely used OpenSSL1.3 library, to ease integration with existing applications."

Also, Ismail Donmez had this interesting idea:

Thats very easy to solve get Kmail developers add this to license

"OpenSSL expception : Kmail can be linked against openssl exclusively"

All in all an interesting discussion. There was general agreement this this is a problem, and as you can see above, several potential solutions exist. It will be interesting to see which one comes out ahead.

(ed. [Russell Miller] It'll be even more interesting to see whether an exception for openssl in the kmail license works. This seems to directly contrast using the most functional software for the job against keeping the codebase unpolluted with non-free software. What I would find most interesting would be what the political implications of making such an exception would be. While I don't dispute the benefits that "Free Software" has brought to the table, the proponents of pure free software (especially in the guise of the GPL and FSF) are not known for their tolerance of the "pollution" of free software. Something to think about before the final decision is made. )

3. Change file permissions using octal numbers

15 May 2003 - 16 May 2003 (48 posts) Archive Link: "[Patch] #29984 Change file permissions using octal numbers"

People: Dominik SeichterTim Jansen

Dominik Seichter started this quite incredible thread with the following quote:

The patch adds a line edit to the permission page of the properties dialog. The user can enter any octal number in the line edit to change the file permission like he would do when using chmod. Additionally the file permissions selected by the user are shown as an octal number.

The attached patch is tested against HEAD and works flawlessly for me when applied to kdelibs. May I commit it? Are there any comments for improvements?

Which set off quite a firestorm of comments, some for, and some against. Both camps came up with quite good arguments. Out of this came an interesting message from Tim Jansen that appears to have struck quite a nice balance and everyone who responded seemed to be able to agree with:

I have a proposal for a re-design. You can find a .ui and png here:

http://www.tjansen.de/other/file_properties.png http://www.tjansen.de/other/accesspermissionsexamples.ui

The files show four different replacements for the "Access Permissions" frame of the original properties dialog. The content depends on the type of the file (executable, directory) because the flags have different meanings for different file types.

The upper left frame is intended for regular files that are not executable. All combo boxes have only three entries: "Forbidden" (---), "Can Read" (r) and "Can Read and Write" (rw). If a special flag is set or an unusual combination is used (like w), the advanced mode is used (lower right). When you click on "Is Executable" the content of the combo boxes will be converted to those on the right side. The transitions are "---"->"---", "r"->"rx" and "rw"->"rwx". When the user clicks on "Advanced Permissions" a dialog with the old bit matrix appears, and possibly the octal value.

The upper right frame is an example for executable files. The combo boxes have three entries: "Forbidden" (---), "Can Execute" (rx) and "Can Execute And Modify" (rwx). When "Is Executable" is unmarked all x marks will be removed, and the content of the combo box changes to those of the upper left frame.

The lower left frame shows a regular directory. The combo boxes have three entries: "Forbidden" (---), "Can View Content" (rx) and "Can View and Modify Content" (rwx). Additionally there is a checkbox for setting the sticky flag.

The upper right frame shows the properties for a file with unusual permissions like "wx"or "w" or anything with a special flag set. The user can only use the Advanced Permissions. If the user changes the flags back to a supported combination, she will get the regular permissions frame.

If the user has no right to modify a file the comboboxes and the checkbutton will be disabled, and the label of the lower right frame says something like "You are not allowed to change the permissions".

This author is really not sure which will be committed, but it appears that at least one will.

4. KDE CVS Commit Policy

18 May 2003 (1 post) Archive Link: "KDE CVS Commit Policy"

People: Cornelius Schumacher

Cornelius Schumacher said:

At http://developer.kde.org/policies/commitpolicy.html you will now find the KDE CVS Commit Policy.

This policy has been created and discussed on the kde-policies mailing list and should reflect what the KDE developer community considers to be the rules for commits to the KDE CVS repository. The document doesn't contain any new rules. It just collects what previously was scattered around at various locations or wasn't written down at all.

The document will hopefully be a useful guideline for new developers and a gentle reminder for old ones.

 

 

 

 

 

 

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.