Re: Shipping Vera with 2.4

[Bastien Nocera <hadess hadess net>]

On Thu, 2003-02-27 at 14:51, Michael Meeks wrote:
> Hi Bastien,
> 
> On Thu, 2003-02-27 at 14:14, Bastien Nocera wrote:
> > > 	It's very hard to compare a system that exists, and works
> > > with one that does not.
> > 
> > I've also got my very own thingo to do simple IPC, that I use in totem:
> > $ cat bacon-message-connection.[ch] | wc -l
> >     271
> > 
> > And that replaces the whole of CORBA for simple IPC purposes.
> 
> 	Well yes it's small. The facts that again it's a type-unsafe, "send
> string" API, with no way of ascertaining what the interfaces are, are
> rather unfavourable.
> 
> 	There are also the following bugs/mis-features I saw with a brief
> glance, correct me if I'm wrong:
> 
> 	* missing syscall error handling
> 	* blocking accept
> 	* not handling EINTR
> 	* assuming non-blocking / short reads [ possibly in-spec, 
> 	  perhaps better to use NON_BLOCK ].
> 	* blocking connection write
> 	* no error checking / short write handling on write
> 	* server_cb locks in a tight loop on 'read' error
> 	* looks like it creates an insecure, world writable /tmp
> 	  Unix domain socket -> instant, huge security hazard
> 	* doesn't do collision checking => instant DOS attack.

All the reads are done in another loop, not the gkt+ main one. The unix
domain socket is only user writable, not world writable.

Even with the fixes, the code size and the API would be much simpler
than using orbit and all.

> > > 	I'd point you at the code in eg. gnome-terminal/terminal.c that does
> > > the uniqueness stuff - it's a handful of lines, but of course - if you
> > > want to detect errors, do activation etc. you get to write more lines of
> > > code. Either way it's a fraction of the code.
> > 
> > 110 lines, command-line parsing and relative->full path helper included
> > in Totem so far.
> 
> 	Including several security bugs, the inability to handle signals etc.
> etc.

I don't see any security bugs here. Remember that the goal here was to
have something that was easy to use. IMO, overengineering is a flaw.
Using Orbit to have simple IPC is overkill.

> 	None of that is particularly hard to fix: the message is simple however
> - re-use code, preferably that tested over a long period.
> 
> > > 	Of course - we should have bonobo-activation tracking all apps, and
> > > make that a standard feature of GnomeProgram. But of course, that would
> > > be obstructed as soon as it's suggested - too similar to D/BUS.
> > 
> > That's certainly a better idea than making Gnome apps use bonobo-conf
> > instead of GConf.
> 
> 	As Havoc said the other day - GConf was not designed to store data;
> bonobo-conf however - was. Thus - though it took a long time for the
> truth to come out - in fact bonobo-conf was a very useful tool, (quite
> apart from being able to handle structured data) - you could store data
> in a controlled way.

I meant that it was a better use of time. I wasn't discussing the place
of bonobo-conf in the GNOME food chain.

-- 
/Bastien Nocera
http://hadess.net

#2  0x4205a2cc in printf ("Oh my %s\n", preferred_deity) from
/lib/i686/libc.so.6 printf ("Oh my %s\n", preferred_deity);
Segmentation fault