Older blog entries for tjansen (starting at number 12)

SOAP

A few points on the SOAP discussion:

• SOAP itself does not mandate transmission over HTTP. You could, for example, use BEEP as a transport.
• SOAP over HTTP was definitely designed to get through firewalls and HTTP proxies. This is the reason why people use HTTP and not a superior transport like BEEP (that would allow communication from the server to the client without pulling). If it did not use HTTP all those web services would not work for many problems, it would require a huge change in the infrastructure. Basically everybody who can access the web only over a www proxy could not use those web services.
• If your problem with SOAP is that you can not prevent a user/client from using it, read my last entry - you can not effectively limit the user's communication anyway.
• if your problem with SOAP is tunneling the firewall on the server side: you dont want SOAP to run on port 80, use another port. If you dont want to use HTTP, you are free to use another protocol. You will lose a lot of users/customers, of course, because many of them wil not be able to use it.
• I also don't buy the 'build an abstraction layer around the interface' argument. Basically SOAP is the abstraction layer. If you write one yourself you write more new and unproven code and introduce more potential security leaks. And, of course, you will lose a lot of time that you can also spend on making your code more secure.
• If your problem with SOAP is that it makes it too easy for server developers to shoot themselves in the foot: if you really take a COM object and make it available via SOAP without a security audit then, well, it is your fault. But the technology is not bad only because it allows stupid people to do stupid things. If that was true Unix would be the worst of all operating systems...

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...

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..

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.

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.