Older blog entries for tjansen (starting at number 11)

22 May 2002 (updated 22 May 2002 at 18:26 UTC) »
SOAP and security
I cannot understand the 'SOAP and Security' discussion. Of course you can use SOAP with HTTP as transport to get through a firewall and it's stupid to make such a fuss about it. When you allow a system behind a firewall to communicate with arbitrary systems outside of the protected network, you can not limit its communication. SOAP just makes it easier for the average programmer to do this, but you can achieve the same thing with REST, emails or even DNS. A firewall may make it a little bit more inconvenient for a user to connect to the outside, for example you can prevent them from using Real Audio apps by blocking the appropriate ports. But if they really want to, they can - theoretically - stream the data over an DNS tunnel.
Beside monitoring, the only good reasons for a firewall are to
  1. block incoming connections to some or maybe even all ports, in order to prevent access to systems and/or protocols that the admin does not want to expose (e.g. X11, NFS, printers).
  2. in the case of application firewalls: make sure that no currupted data is sent, to exploit things like buffer overflows, and maybe to limit the capabilities of the protocol. For example an application firewall could prevent POST requests in HTML. This could be used to 'cripple' the server and turn off unused functionality that may be exploited otherwise. It's just another form of risc reduction.
  3. Block outgoing connections to ports, in order make it inconvenient for users in the secure net to use certain apps. This is more about telling users what they are allowed than actually preventing it, unless you block all ports.
This is what you can expect from a firewall. What you can not expect is to prevent a protocol, that has been designed for transmitting documents and form data, from being used for other purposes.

SOAP itself is not dangerous, and the code that handles SOAP requests is not more dangerous than any CGI script. The input and output just have a more restricted form which should make it rather more secure.

krfb/krdc: After the failure of the windows vncviewer port attempt I tried to port the UNIX vncviewer, with much more success. The thing, now called 'KDE Remote Desktop Connection' or krdc, is not very far from being complete. I am currently working on the fullscreen mode...

6 Apr 2002 (updated 22 May 2002 at 10:09 UTC) »
krfb: Started porting the windows vncviewer, but then decided against it. While it would certainly be possible and less work than the other alternatives it is more work than I had hoped. Porting with the full feature set would probably cost me a whole month (working in my spare time). So I scrapped it, for now, and will spend the rest of the weekend working on the krfb server.
krfb: A few days ago krfb has been moved into the kdenetwork package, so chances are good that it will appear in KDE 3.1. This makes a KDE client even more neccessary, but unfortunately I haven't heard anything from the QT-VNC guy. Right now I am considering to port the windows vncviewer directly to KDE. It doesn't look very difficult and should be easier than taking keystone and rewriting the vncviewer code to fit. But even if I would finish this I know that I will spend endless time maintaining this, which would hurt the other things that I have planed to do... I will see what I can get done this weekend..
11 Mar 2002 (updated 12 Mar 2002 at 10:35 UTC) »

A few weeks ago, on the same evening I wanted to start improving keystone somebody appeared on kde-devel and said that he implemented a QT-based VNC client and wants to port it to KDE. So I gave up the keystone idea, even though I haven't seen the new client yet and I am not sure whether it will actually see the light of day.

Progress on krfb 0.7 is ok, the KControl module is working, the kded module (kinetd) looks good (but wasnt actually tested). Now all that I need is the invitation feature and make sure that everything works. I hope to get 0.7 out this month. After 0.7 a loose code freeze will start, and I only plan to do bugfixes, maybe add some minor features and, of course, documentation and i18n stuff.

krfb: Finished porting to libvncserver, added KNotify support and somebody send me a patch with a DCOP interface that I have integrated, too. In other words: version 0.6 is out.
So now my next task is to add better encodings to keystone and maybe improve its GUI.
krfb: I was almost finished with porting the codecs to krfb and several improvements on the backend when somebody told me about libvncserver. So I scrapped the complete x0rfbserver backend and replaced it with libvncserver. As of today it is almost running, and I am glad that I can worry less about that stuff and can concentrate on other things. As soon as the next krfb version is out I plan to improve keystone so KDE gets an up-to-date vnc client.

KIO/WebDAV: My webdav patch is dead after I discovered that somebody else already wrote one, so I can focus on getting vnc/remote things right.

Many things happened since my last diary entry.. Patrick Mochel submitted his new Linux driver model, which was much more radical than my humble attempt at collecting device data only, and it got into the 2.5 kernel. This made my Device Registry patch pretty obsolete which isn't too bad because I did not want to work on kernel stuff forever.

So I moved on to work on further items of my virtual TODO list to make KDE/Linux a more enjoyable desktop.

By accident I found x0rfbserver, a VNC implementation that shares your X11 session instead of creating a new one. Remote desktop administration was on my TODO list, so I ported it to KDE and created KRfb. It was also a nice little thing to get started with KDE development which I never did before. Two weeks later (we're now around christmas) the port was finished, but I did not want to release it before I got some response from x0rfbserver's author. So I started another small project: WebDAV support for kio_http. I added all the new commands, header fields and status code, but the biggest part, XML parsing of WebDAV responses is still missing. On January 2nd I was fed up waiting for x0rfbserver comments and released the first version officially. I got more reactions than I thought, especially from people who wanted TightVNC support and so I decided to add it. While looking at the RFB protocol implementation of x0rfbserver's rfblib I found many bugs that I had to fix. I also found out that the implementation of the codecs was quite bad (lower compression rates than possible), so I started the porting codecs from TightVNC's winvnc and replace the original ones as well (yes, I am porting from the Windows version, because it is in C++ and the Unix version in C). So far Hextile and RRE are running, I will probably skip CoRRE and start ZLib tomorrow. Then I only need TightVNC and can release KRfb 0.6, maybe even this week, and maybe I have time for the WebDAV stuff again.

effbot: 'panorama' did not say that the CNN/reuters video was 10 years old, nor did they doubt that they shot the video on september 11th. They just showed the whole video, because CNN cut parts of it so it did look like everybody on the street was celebrating even though there were only 10 people. And they showed one persong getting a piece of cake for doing so.
21 Sep 2001 (updated 21 Sep 2001 at 10:24 UTC) »

Originally I wanted to keep out of the WTC-related discussions here because I still consider Advogato a OpenSource-related site... but yesterday they showed something in a german tv magazine that I have to tell the world about.

Remember the CNN pictures of the palestinian people celebrating? German magazine "panorama" showed the complete shot. There you can see that the life over there went on as usual, only a few children celebrating because a guy in a white t-shirt motivates them to do so. It also shows that the old woman who celebrates does so because they offered her cake, and she later denied that she did it because of the WTC attack.
You can watch the clip in Real format here. It's a 10 minute movie in german, so you have been warned. You can find the CNN/palestinian part at 7:40.

devreg: The progress of the device registry is ok but could be better. Coding of the framework is finished, I still have to add the new registration stuff to the drivers and then hope that everything works fine without too much debugging. Beside that I started writing the documentation for driver developers. I think this is the right time to do this since I'm pretty confident that most of the kernel API will be stable from now on.

config fs: I'm planning to abandon my proc fs changes in a future version and instead write new filesystem based on the proc fs code. Proc FS is a mess. While most of the files in /proc are quite convenient to read for human readers they are almost unusuable for software. The problem is not that parsing would be so difficult but that it is impossible to add new fields once you have defined a text format without breaking all software that reads it. Binary files suffer from the same compatibility problems. A few months ago several people convinced me on LKML to go the "one-value-per-file" way for devreg, and the new filesystem will enforce this even more than my proc fs extensions. Every file will be strictly typed (string, int, ulong, enum), dynamic directories will be possible, the type of a file can be retrieved using ioctls, and unlike my current proc changes writing will be supported, too.
The more interesting part of the plan is that I want to support both persistent and non-persistent files. So there will be some daemon waiting, similar to devfsd, for files that have been flagged as persistent and will then store their new values when they have been changed. On initialization of a file the daemon will fill it with a previously stored value. Dynamic directories can have keys that can be used to find the correct one. I'm currently calling this concept config fs. Beside the replacement of proc fs for everything but processes it can be used for the configuration of the kernel and drivers. The current way of configuration definitely sucks, module options are a bad idea for most purposes because you cannot change them at runtime and they are not very useful if your driver handles several devices at the same time. They can only be used for the driver's global configuration, but not for the configuration of driver instances. IMHO module options should disappear for anything but boot-time configuration. The only frightening thing about the config fs idea is how close it is to Win2k's registry. It's a little bit less arcane because you can access it as a filesystem, but beside that there are only few differences between them. It could even make sense to use it for the general configuration of system software. bah...

2 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!