Re: Syslog-sec-misc @ SF: syslog-sec: API, standards and 'host'BSD

[Adam H. <ha...@gm...>]

On Apr,Wednesday 2 2008, at 11:04 PM, Albert Mietus wrote:

> Two remarks
>
>
> ONE
>
>>> I've looked at the different versions and found some main
>>> differences:
>>> OpenBSD: splits syslogd for privilege separation
>>> FreeBSD: 2nd socket for ...
>>> DragonFly: adds a ring buffer
>>> NetBSD: seems 'just' to be refactored and with more checks
>
>>> A merge of current FreeBSD and NetBSD code could be a first step.
>>> I am just afraid it might become a political issue early on ;-)
>
>> yeah I'm almost sure that this will happen :).
>
> I think we should (on SF) try to keep out the politics ...
>
> That would be possible by NOT merging code & politics from the *BSD
> code-bases.
>
> When I started, long ago, I tried to keep the (then only FreeBSD)
> source file almost unchanged  and just added the "sec" part.
>
> The files .../FreeBSD-syslogd/usr.sbin.syslog/syslog* are coming from
> BSD, the file .../sl_* are "mine" and are as independent of the
> original as possible (some call to sl_* functions are added:-)
>
> Is it possible to exent this idea, and separate file like (as an
> example/proposal):
> 	.../sl-sec/*			the "extra" functionality for -sec (spit in sec/sign/
> sec/*/)
>   	.../host/FreeBSD/		The (minimally) addapted FreeBSD srcs
> 	.../host/netBSD/		same for netBSD
> 	.../host/OpenBSD/	same ...	idem
> 	.../host/...			you get the idea.
> And also:
> 	.../stand/				A "stand alone", "best of bread" , as we see it
> version of syslog(d)

yeah I think that this seems good.

>
>
> Then, each *BSD can easily port the (our) SF code there BSD, by
> taking the host/* version and the shared -sec code.
> Eventually (and likely), they will decide to go for the best of bread
> version. Then THEY make the decision; we are happy to get our code
> incorporated and everybody wins by better, integrated, and secure
> syslog.
>
> Note: even a .../linux/, ../WinDos/... or ../whatEver/ host can be
> added. But we start with the one WE like.
>
> Please comment!

I will think more about this later today after some sleep :).

>
>
>
> TWO
>
>>> API which is intended to replace syslog(3).
>
> Don't bed on that. I have seen several would be replacements for
> syslog. They generaly fail to replace syslog, or the fail completely.
>
> So stick to syslog and it standards. Sure learn from all. But focus
> on syslog-sec!


yes syslog API is used to long and therefore it is really hard to  
substitute it with other API.

Regards

Adam.