latest kudzu changes

[John (J5) Palmieri]

On Mon, 2004-08-16 at 19:50, Steve G wrote:
> >It could use a security-minded person or three looking over it, if
> >anyone with the skills is interested. 
> 
> I'm interested. I usually have to code review every single package and fix it
> anyways. I'm still carrying over 200 patches to rawhide. Alan picked up a few,
> but they were mostly BuildRequires.
> 
> >dbus is a place to put a lot of things that the kernel guys would rather
> >see done in userspace. 
> 
> My biggest concern is that its too intertwined with X/Qt/GTK. I can already see
> that I'm going to have to do surgery to untangle them. I know this is the wrong
> list to discuss design philosophy of hal & dbus, but the actual daemons should be
> one package and the viewers/gui's/addon's another package. Not as a i386 rpm, but
> as a source rpm. I have absolutely no time to code review gtk and all that it
> brings.

For all intents and purposes they are not hard requirements.  I just
disabled gtk in the packages.  HAL needs glib but that shouldn't be a
concern.  Separating at the source level make no sense to me since they
can be turned off in the RPM with a simple configure switch.  What
surgery would you have to do?

> >So even though it is userspace, we're going to have to make it a hard 
> >requirement and stick it pretty early in the boot process, probably.
> 
> I really wished this went in after fc3. I got the feeling there's problems that
> need more time to find before trusting in a hostile environment. I just started
> reviewing udev and already have 2-3 patches with security implications.

dbus has been in since fc1.  Pushing this integration off another
release means more time for people to ignore it and not test it.  You
are free to wait until you feel you have had time to review it before
you put it into whatever environment you have setup.  We welcome the
extra pair of eyes.  

--
J5