Re: External event loop for glib?

[Bill Huey <billh mag ucsd edu>]

> 1. requires quite lot of work that is not productive.  Moreover, the
> non-existence of glib documentation would make this somewhat guesswork.
> 
> 2. has the GLPL problems as well as the trouble with missing
> documentation.
> 
> 3. has the following problems: (1) glib is not documented well and thus
> transition to use glib event loop is difficult. (2) the exact semantics of

The rationality behind (3) is ridiculous. You've got the full source code
and the code base isn't that large, so that in itself should server as
adequate documentation for the code.  The stuff that might be complicated
is just straight X lib stuff, while everything else are wrapper around
preexisting APIs within Unix.

About 70 percent of computer programming is reading other people's screwed up
or not so screwed up code. Glib is simply not that difficult to read.

> event loops in the case of callbacks changing the file descriptor
> requests, signal catching etc. can vary. Moreover, before glib is
> rigorously documented telling what the event loop actually does, we cannot
> trust our software to run in the hands of glib. Our event loop captures
> signals and is callback-safe. How can we trust that glib is? Generally, we
> can't trust glib's event loop for security-critical software in its
> current form (SSH Communications Security Inc. develops high-quality
> computer security software).
> 
> Therefore it seems that I'm inclined to choose 4. While requiring some
> extra work for IPC, I avoid
> 
> - the problems caused by the event loop differences
> - the problems of using one more external library in security-critical
>   software
> - the problems of Xlib exit(3)ing when X connection drops or something
>   other stupid happens

Uh, chunk of shared memory isn't going to prevent "buffer overflow" tactics
since it's another unauthenticated chunk of memory. Threads are their for a good
reason in a common process memory space and you should use it. Any other method
is rather backward in a old fart Unix guru kind of way. I don't have anything
against old Unix fart since I'm probably going to be their in about 10 years.


You really need to look at the code and judge for yourself if the code base
is secure enough. This is on of the primaril reason of what doing security
is about. I suggest you excersize your knowledge. Alan Cox might of help
since he's taken responsibility (from the an email that's a year old) for doing
the GTK security audit.


> *IF* GTK allowed one to use its own event loop (which I think wouldn't
> require that much effort) then perhaps my choice could be different. Of
> the current alternatives, this is perhaps the best one.
> 
> I'm still interested to hear any comments about this.
> 
> -- 
> Antti Huima
> SSH Communications Security Oy


bill