Re: [fossil-users] OT: Why we should NEVER use inetd/xinetd
Nathaniel Reindl decía, en el mensaje "Re: [fossil-users] OT: Why we should NEVER use inetd/xinetd" del 28/10/2016 08:23:28: > From my perspective, this thread has far outlasted its usefulness and has > become an exercise in self-satisfaction for those who prefer to write words > instead of writing code. Can we perhaps refrain from offering > attention-addicted individuals the attention they so desperately crave? Apparently I did something like that previously; the OP is in my blocklist. I would encourage others to do the same. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] OT: Why we should NEVER use inetd/xinetd
> On Oct 28, 2016, at 02:29, Luca Ferrari wrote: > No, I do. > You should go trolling somewhere else. Just checking in. It seems that my decision to mute this thread within my mailer immediately after my single response was a good idea. From my perspective, this thread has far outlasted its usefulness and has become an exercise in self-satisfaction for those who prefer to write words instead of writing code. Can we perhaps refrain from offering attention-addicted individuals the attention they so desperately crave? I promise you'll look back fondly on this decision just as I have. —n ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] OT: Why we should NEVER use inetd/xinetd
Hi, >« The security concerns come in as a result of not paying attention to the >details of the implementation » Oh I forgot this. In the past, it was my tought. But as the expert explain to us, it is not only implementation. Theses days, we all hear about DDOS that could not be stopped, not to mention serious security issue not far in the past with routers... >« but that is by no means a guarantee » No one ask for guarantee. But everyone would like to reduce issues... DDos : 'Preliminary' evidence: Cyberattack not carried out by a government - Oct. 25, 2016 http://money.cnn.com/2016/10/25/technology/cyberattack-obama-dyn-ddos/index.html Eh it was this year ? This month ? It should never happen, no ? Today's Brutal DDoS Attack Is the Beginning of a Bleak Future http://gizmodo.com/todays-brutal-ddos-attack-is-the-beginning-of-a-bleak-f-1788071976 « No matter who did it, we should expect incidents like this to get worse in the future » As Luca said, Fossil users don't need security talks ... :-D Hmm ... Now I've got a question just for me : why do we want security in Github ? Best Regards K. De : Nathaniel Reindl *snip* ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] OT: Why we should NEVER use inetd/xinetd
On Sun, Oct 23, 2016 at 07:00:25PM -0400, Ron W wrote: > I think what K meant was that it has been more than 4 years since the last > new release of xinetd. I also noticed it was about 7 years to the previous > release. > > I do agree that assuming too much from a project being long time since the > latest release is folly. I find it to be quite a stupid assumption to be frank. Let me put it into perspective. The last change in NetBSD's src/libexec/inetd was last year to add some more format print annotation. The last functional change was 2009. There is a lot of software in the real world with a well defined goal and unchanging feature set. Reaching a point of maturity where there is simply no need for changes is not that difficult. Joerg ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] OT: Why we should NEVER use inetd/xinetd
On Sat, Oct 22, 2016 at 8:32 PM, wrote: > > -- Forwarded message -- > From: Nathaniel Reindl > To: "Fossil SCM user's discussion" > Cc: > Date: Sat, 22 Oct 2016 19:56:51 -0400 > Subject: Re: [fossil-users] OT: Why we should NEVER use inetd/xinetd > > On Oct 22, 2016, at 17:23, K. Fossil user fr> wrote: > > 2/ Xinetd is old (four years ?) so may be not secure. > > xinetd is actually older than that. It may have not, for whatever reason, > seen a recent release. > I think what K meant was that it has been more than 4 years since the last new release of xinetd. I also noticed it was about 7 years to the previous release. I do agree that assuming too much from a project being long time since the latest release is folly. Even a very new release could be insecure. Xinetd is actually small and simple compared to a lot of servers with a lot of recent activity. It might be that none of the few currently open issues is an actual security problem. I have not audited the code, however, I don't see any recent CERT advisories about xinetd. I don't use xinetd. I have no need for it. I don't run any services other than Fossil on my computers. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] OT: Why we should NEVER use inetd/xinetd
> On Oct 22, 2016, at 17:23, K. Fossil user > wrote: > P.S. : I will never understand why people don't know about security issue > when it comes to inetd. Aha, so this was a security concern. I figured just as much. Please read on. (: > I was explained to never use ONE daemon for many servers. When needed ONE > daemon for ONE server and not more. OK, so, from a systems design standpoint, inetd and xinetd don't inherently have insecure designs as super servers. Instead, that design lends them a tendency to exhibit pathological unreliability; if inetd or xinetd crash (say, because the configuration parser has a bug because it unwittingly derefs NULL), the services that are run under the auspices of either one will similarly meet a less than pleasant fate. The security concerns come in as a result of not paying attention to the details of the implementation. Make sure you use things like initgroups(3), setgid(2), and setuid(2) to drop privileges. Make sure you understand how inter-process communication can be made secure. Make sure you have good hygiene when you dynamically allocate memory and work with, e.g., NUL-terminated strings. Now, it just so happens that it's simpler to keep track of the security details in things like tcpserver and tcpsvd because the single-instance-per-single-server architecture lends itself well to fewer lines of code to serve as a liability, but that is by no means a guarantee. Caveat emptor. > 2/ Xinetd is old (four years ?) so may be not secure. xinetd is actually older than that. It may have not, for whatever reason, seen a recent release. That said, xinetd has comparatively few lines of code (granted, it's still more than tcpserver and tcpsvd for just the configuration file bits alone) when placed next to other pieces of software that often run in part with escalated privileges like, well, modern full-featured HTTP servers. Also, it's folly to discount everything above a certain age as insecure. tcpserver, part of Dan Bernstein's ucspi-tcp package, has a solid design that lends itself very well to running TCP servers that are invulnerable to the exploits you're afraid of. I don't think it has seen an update in 15 years. Anyway, that's all I have to say about that. —n ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
