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

[Francisco G. <fra...@fn...>]

Hi folks,

I'm just this guy that wants to contribute to FreeBSD and Albert was  
kind enough to invite me to this (re)start of syslog-sec, no academia  
behind me though.

I do think politics are something that we shouldn't be worried about  
since the BSD projects will ultimately decide on what they want for  
themselves. I thought of syslog-sec as freebsd's syslog with security  
features added-in and as such perhaps one could consider having a good  
look into *BSD's syslogs and perhaps create an abstract layer for the  
security enhancements that could be fitted into each of the diferent  
code trains. im not sure if you guys are thinking of doing a syslog  
from scratch...if so, i'm all for it ;)

Kind Regards,
Francisco Guerreiro

Quoting Albert Mietus <al...@on...>:

> 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)
>
> 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!
>
>
> 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!
>
> --Groetjes
> ALbert Mietus
>      Send prive mail to:          ALbert at ons-huis dot net
>      Don't send spam mail!
> http://albert.mietus.nl               http://albert.mietus.nl/read.IT
>
>
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> Syslog-sec-misc mailing list
> Sys...@li...
> https://lists.sourceforge.net/lists/listinfo/syslog-sec-misc
>