> > I need to talk to Marcus about that, to recheck, that there isn't much that
> > really needs to be fixed.
> No! You and Marcus _NEVER_ will find _every_ bug!
We never claimed that. However we both know probably best where some
conceptual problem lie deep within the code, especially in very obscure
areas, which were pretty often written by one of us.
These are not bugs in the sense of "it doesn't work", but rather small
deficiencies in interfaces that would make some possible future
enhancements hard.
> Only a _community_ can do that. Make _public pre-releases_ available
We have CVS and daily snapshots. Everyone can review the code.
This is not about me and Marcus doing some kind of conspiracy. It's just
that we had some issues that need sorting out on our schedule in the past.
But o.k. - as you want to know it, I'll tell you about the most prevalent
issue we worried about the last time we talked:
Security. LibGGI is - due to its dynamic loading mechanism and its external
configurabilty via the environment - very unsuitable to be run suid.
While most people here will agree, that there isn't much use in making
LibGGI progs suid, SVGAlib users might think otherwise as well as some
lazy people that would like to make something like ggipasswd or similar,
without doing "the right thing" and split it into a front- and a backend.
I see two possible solutions:
1. Moan at ggiInit, if eid!=id. Teach people not to do that. Bad for the
SVGAlib target maybe.
2. Check through all of the code, replacing all file operations with "safe"
versions that work on the uid of the calling user, checking all fork()s
and stuff to start things with the right uid (like the pipe-feature in
the file-target), etc. .
> - EARLY AND OFTEN - and wait for feedback from the user-community!
> This is much more efficient. You will see.
Technically this has been done the last few weeks ... except that noone
announced something like a "feature freeze - please test everything".
I had assumed that would be done automatically by the people here, when they
see a CVS update bring significant changes.
> > When we agreed on that, making a release would be
> > nothing but keeping our hands off the code until the next snapshot
> > generation, if we adopt the model from 3.
> OK. Please don't forget to post a actual job list permamently for the
> final release. Each point should be small enough, so that it can
> ideomatically be done within a few days...
Don't think there will be much to do.
> > 7. Someone suggested a big IRC meeting.
> Yes! But please don't forget to post the log to the ML... ;-) see my
> earlier mail.
Yeah - we've done that always anyway.
CU, Andy
--
= Andreas Beck | Email : <[EMAIL PROTECTED]> =
