'[kc-kde] KDE Traffic #52'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kc-kde
Subject:    [kc-kde] KDE Traffic #52
From:       Russell Miller <rmiller () duskglow ! com>
Date:       2003-05-28 5:01:50
[Download RAW message or body]

KDE Traffic #52 For 25 May 

By Russell Miller 

Table Of Contents

Printer-Friendly Format
Text Format
XML Source
Introduction
Mailing List Stats For This Week
Threads Covered

1.
Newsflash!

2.
9 May  - 16 May 
(25 posts)
KSSL based S/MIME plugin available

3.
15 May  - 16 May 
(48 posts)
Change file permissions using octal numbers

4.
18 May 
(1 post)
KDE CVS Commit Policy

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:

34 posts in 229K by Waldo Bastian

25 posts in 64K by Ingo "Klöcker"

21 posts in 56K by Stephan Kulow

19 posts in 86K by Ingo =?iso-8859-1?q?Kl=F6cker?=

17 posts in 92K by Helge Deller

Full Stats

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  - 16 May  (25 posts) Archive Link: "KSSL based S/MIME plugin available"
 People: Stefan Rompf, Bernhard Reiter, Mark Mutz, Waldo Bastian, Ismail 
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  - 16 May  (48 posts) Archive Link: "[Patch] #29984 Change file 
permissions using octal numbers"
 People: Dominik Seichter, Tim 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  (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. 

-- 
Randomly generated fortune cookie:
You can tell how far we have to go, when FORTRAN is the language of 
supercomputers. -- Steven Feiner

Russell Miller - rmiller@duskglow.com - Somewhere near Sioux City, IA.

_______________________________________________
kc-kde mailing list
kc-kde@mail.kde.org
http://mail.kde.org/mailman/listinfo/kc-kde

[prev in list] [next in list] [prev in thread] [next in thread] 