Re: [fossil-users] Why we should NEVER use inetd/xinetd

[K. Fossil user]

Hi,
(Some blatant talks from luca tend me to say this) :
Did I say that  I do use a FreeBSD computer ? No I did not. It does NOT mean 
that I do not use a NIX OS freeBSD included :-). [1]


> « It does not matter which model or the context. »

Ask your computer scientist, because You dare to say that I am wrong.Give to 
use his point of view. CC him so you could say that you are coherent.
> « you trust such friend, how can we trust him too? Why don't cc he so he can 
> provide information you are clearly not aware if? »

a) I've responded to that. b) Don't you trust your computer scientist ? Ask 
him... (read just above)
My job is done, do yours...c) CC : I've answered that, too...

> « I do use gmail, I do not send html, just as an example... »

I do use Gmail, Outlook, etc.A webmail send HTML. A MUA could be configured not 
to send HTML. I am not going to change the behavior of my WebMail just for you, 
when most people in real life do prefer HTML.

> « I must be a really strange guy: I do use fossil in production at work and 
> git for personal projects. »

aha : Now I do understand. I was a bit astonished when I do read some stupid 
stuffs but now I am happy:Your are not the nice guy some people expect.Very few 
people do use Fossil especially in production use.So if a guy send so nasty 
vibes inside a mailing list especially a guy who work in his job part time with 
a software (Say Fossil), I know that people would never want to use it (say 
Fossil).

But now because your are so clever (not in my point of view) why don't you 
convince FreeBSD and OpenBSD to use Fossil ?For example, tell OpenBSD that they 
should not use Git, which is a Linux DVCS.And of course because you do know 
better than most of us about it, do CC us so we can follow your steps.(May be 
we will learn something about an new approach to convince people to use Fossil)
> « But, as I already stated, if you are not using fossil, not planning to use 
> fossil, not happy with fossil, what the hell are you posting on the fossil 
> mailing list? »

a) Who said that I don't plan to use Fossil ?b) This is evidence that you don't 
read whatever I've said, especially the other day when I've written something 
about inetd.c) My subject is Fossil related, yours is not.d) What I've done/I 
do/I will do is none of your business !

Go play somewhere else.
Oh I forgot : a guy who seems to convince me that he is aware about NIX is not 
bothered by any html stuffs.(Regular expressions could be used if necessary)
Why do you use Github ? Are you afraid of not to be seen ? I do use Github and 
something else... (Git only)
Don't you know that there are some website that host Fossil ? I do ...

I am quite sure that people who do want to use Fossil, newbies, would like so 
much the way how a Fossil user, I mean YOU, think ! (Luca has Fossil in 
production ! Wow !)
Well played. (I could not imagine the impact of what you've done)

 
Best Regards

K.

 [1] For the record :

4. What Is A "Bikeshed"?
NOT bikeshed.org.

  De : Luca Ferrari <fluca1...@infinito.it>
 À : Fossil SCM user's discussion <fossil-users@lists.fossil-scm.org> 
 Envoyé le : Vendredi 28 octobre 2016 6h29
 Objet : Re: [fossil-users] Why we should NEVER use inetd/xinetd
   
On Fri, Oct 28, 2016 at 3:42 AM, K. Fossil user
<ticketpersonnal-fos...@yahoo.fr> wrote:
> Hi,
>
>> « <http://bikeshed.org/> »
>
> I don't click in any links that are not known...

Right approach!
After all, all computer people have never heard about Bike
Shed...especially those tied to FreeBSD...
You have to learn a lot of stuff.



> a) I've never said that I will provide info about me or people I do know.

Let's call it "scientific approach".

> b) People who are aware about security knows what I am talking about.

Let's call it "religion".

> e) The aim of this thread -mine- is to give info, nothing else.

Let's call it "information without  evidence".

> When an expert says that you should not use inetd/xinetd whatever it is,
> there are no questions about which release it is or which OS.

Don't use chainsaw, they can hurt you.
It does not matter which model or the context.

> Generally speaking if somebody say don't use this software, and I do trust
> him, I won't try to use it, which release, OS and so on it is about.

Trust is the point you are missing so far: you trust such friend, how
can we trust him too? Why don't cc he so he can provide information
you are clearly not aware if?

> I am sorry but my computer send html : I only use WebMail ...
> Most people do use Gmail ...

I do use gmail, I do not send html, just as an example...


> If someone should choose between Git and Fossil, give me evidence that they
> would use Fossil in a long term run if you can ...
> The learning curve is high enough so people will choose ONE of them not
> both.
> e.g. Git and 

Re: [fossil-users] Why we should NEVER use inetd/xinetd

[Luca Ferrari]

On Fri, Oct 28, 2016 at 3:42 AM, K. Fossil user
 wrote:
> Hi,
>
>> «  »
>
> I don't click in any links that are not known...

Right approach!
After all, all computer people have never heard about Bike
Shed...especially those tied to FreeBSD...
You have to learn a lot of stuff.



> a) I've never said that I will provide info about me or people I do know.

Let's call it "scientific approach".

> b) People who are aware about security knows what I am talking about.

Let's call it "religion".

> e) The aim of this thread -mine- is to give info, nothing else.

Let's call it "information without  evidence".

> When an expert says that you should not use inetd/xinetd whatever it is,
> there are no questions about which release it is or which OS.

Don't use chainsaw, they can hurt you.
It does not matter which model or the context.

> Generally speaking if somebody say don't use this software, and I do trust
> him, I won't try to use it, which release, OS and so on it is about.

Trust is the point you are missing so far: you trust such friend, how
can we trust him too? Why don't cc he so he can provide information
you are clearly not aware of?

> I am sorry but my computer send html : I only use WebMail ...
> Most people do use Gmail ...

I do use gmail, I do not send html, just as an example...


> If someone should choose between Git and Fossil, give me evidence that they
> would use Fossil in a long term run if you can ...
> The learning curve is high enough so people will choose ONE of them not
> both.
> e.g. Git and mercurial are the same for some people, but I don't even have
> the time to try Mercurial, so why would people try Fossil ?
> c) Fossil is not the same as Git in many areas. Git is not used as a
> webserver, it is not a single file, etc.

I must be a really strange guy: I do use fossil in production at work
and git for personal projects. While I cannot document my work here,
except thru the mailing list archive, you can search for me on github.
But, as I already stated, if you are not using fossil, not planning to
use fossil, not happy with fossil, what the hell are you posting on
the fossil mailing list?



> Seriously ?
> What did I say in the previous talk : you don't know what you are talking
> about.

No, I do.
You should go trolling somewhere else.
___
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] Why we should NEVER use inetd/xinetd

[Luca Ferrari]

Allow me to elaborate a little more, hope this will make you stop
posting like in the previous days.

On Thu, Oct 27, 2016 at 1:30 AM, K. Fossil user
 wrote:
> a) I have nothing to ask at this time, so I don't even need to learn how to
> [ask]



> b) Someone who have something to say could demonstrate whatever he wants
> (e.g. Why does Fossil need (x)inetd when it is clearly forbidden by security
> expert ?).

Since in this mailing list I believe there are "experts", excluding
me, I would like you to understand that writing something like
"_someone_ who knows much more than you told me, _somewhere_,
_sometime_, that I should not use  because
it is not secure to use".

Now, note the use of "somexxx": you provided no documentation, no
links, no facts, no other discussions. Which version of x|inetd are
you referring to? Which version of fossil? Which OS? What kernel?
Which options?

So what can you do in order to help fossil? I believe you can test and
crash a few installations on your own and report back results with
some numbers, in order to support all your statements and the
statements made by _someone_ expert.

In the meantime I suggest you to carefully read this mailing list
before posting, as well as you do review basic mailing list rules and
recommendations (e.g., no html please). The simple fact that you point
git as an "enemy" for fossil means you do know very little about the
project and the culture behind it.

Luca
___
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] Why we should NEVER use inetd/xinetd

[Ross Berteig]

Mr. User (if that is indeed your name):

On 10/26/2016 4:30 PM, K. Fossil user wrote:
In this mailing list we need to know everything about fossil and 
fossil related stuffs.
- inetd/xinetd etc. that may be used in conjonction with Fossil (may 
be I am the only one who hear about a daemon (inetd) that was used 
with Fossil?)

- security related (Fossil is a server sort of)


Let me try to explain this a different way.

The single fossil executable is several distinct things, and compatible 
with several distinct technologies. It also has additional features that 
can be enabled when building, which are not enabled by default.


Fossil is:

1. A CLI program that as a DVCS uses a local repository to track changes.
2. A client for push/pull/sync with a remote repository
3. A CGI program usable from a big web server
4. A server, for both web and fossil sync, listening on port 80, 8080, 
or a configured port.


Case 1 has no external security issues. You are at a command prompt. You 
can presumably do anything at all to your own files. Fossil won't 
actively help you destroy data any more than GCC does or your favorite 
IDE. Naturally it can be misused and could have bugs because we are only 
human. This case is exercised by the test suite that is run occasionally 
by various developers.


Case 2 can be compiled to use SSL, otherwise it uses sockets in the 
clear. Login security and access controls are configured at the server 
end. Configuration can be subtle, but for simple open source projects it 
can be simple and largely just works.


Cases 3 and 4 (and other subtly distinct variations that most often come 
up in some SSL configurations) are all on the server end.


Case 3 is normal CGI. Overall security of the server is the 
responsibility of the world-facing web server. This might not be the 
"best" way to setup an externally accessible repository, but it is the 
easiest. Login security that controls access to the repository itself is 
handled by fossil, with a session cookie across transactions. If your 
web server already handles SSL, you can get SSL coverage of your 
repository essentially for free this way.


Case 4 covers at least three distinct usage styles. It is how the 
"fossil ui" command is implemented, essentially by starting a server on 
localhost:8080 and launching a web browser to touch it. A long-running 
server can be easily set up for a single repository or a directory full 
or repositories with the "fossil server" command. You can also use 
(x)inetd or another launch and monitor daemon to defer launching fossil 
until the port is accessed.


Under most conditions, if fossil happens to find itself running as root, 
it enters a chroot jail and drops as much privilege as it can. This 
mitigates most attacks that depend on getting something running as root 
to misbehave. Fossil doesn't examine the user's request until that is done.


If inetd, xinetd, systemd, or something similar is used to launch fossil 
on demand, then that daemon is what is seen first by an attacker. The 
biggest concern is that a bug or incident might cause a denial of 
service by crashing that super-daemon. That is what happened with 
http://fossil-scm.org when you started flogging the inetd is evil horse 
recently. The daemon died. The machine didn't notice. Services not 
managed by that specific daemon remained alive. This is one of the 
problems that systemd is trying to solve: by being more aware of what is 
supposed to be running, systemd can notice losses and repair them. Many 
people think that is a good idea. Many people are not convinced. Inetd 
and its close relatives do less monitoring. But for a resource that is 
rarely used, having fossil launch when touched can be a better use of 
server resources than having fossil launched, listening, and paged in 
when touched.


The bottom line is that fossil does not require the use of inetd, 
xinetd, systemd, a web server.


But for systems where the administrator has made her own judgment of the 
balance of security, reliability, and other risk factors, the option is 
there.




a) I have nothing to ask at this time, so I don't even need to learn 
how to [ask]


Reasons you sound like a troll.

1. This statement right here. The questions you have asked have shown 
very little effort on your part.
2. Fake name. Not all trolls use aliases, sure. But I've seen far fewer 
outright trolls using obviously real identities.
3. Belligerence. We support fossil because it is useful to us. You 
approach us with a hostile attitude, then get worse when people engage 
and try to help.

4. The rest of this email which I'm not responding to in detail.

--
Ross Berteig   r...@cheshireeng.com
Cheshire Engineering Corp.   http://www.CheshireEng.com/
+1 626 303 1602

___
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] Why we should NEVER use inetd/xinetd

[K. Fossil user]

In this mailing list we need to know everything about fossil and fossil related 
stuffs.- inetd/xinetd etc. that may be used in conjonction with Fossil (may be 
I am the only one who hear about a daemon (inetd) that was used with Fossil?)
- security related (Fossil is a server sort of)- Windows/Linux/etc. issue when 
it comes to Fossil- tips and tricks (most of the time are used with something 
else)
Every experience around Fossil use should be reported ...
This funny part :
>« you don't learn what to ask on the right mailing list »

You don't know when to stop which is worse... :-x

a) I have nothing to ask at this time, so I don't even need to learn how to 
[ask]
b) Someone who have something to say could demonstrate whatever he wants (e.g. 
Why does Fossil need (x)inetd when it is clearly forbidden by security expert 
?).c) If I were you the next time people would talk about OpenSSL/LibreSSL/etc. 
just demand to the Fossil Team to ban him.
    Of course, if someone would like to talk about GIT, it should be forbidden 
because it is a Fossil user enemy...

And if I understand your logic, you should not say that I am a troll/etc. : 
this is not Fossil ONLY talk ! :-)Wake up man ! :-D


Best Regards
K.

  De : Luca Ferrari <fluca1...@infinito.it>
 À : Fossil SCM user's discussion <fossil-users@lists.fossil-scm.org> 
 Envoyé le : Mercredi 26 octobre 2016 6h25
 Objet : Re: [fossil-users] Why we should NEVER use inetd/xinetd
   
On Wed, Oct 26, 2016 at 1:02 AM, K. Fossil user
<ticketpersonnal-fos...@yahoo.fr> wrote:
> For example, today I've learned that Luca is not aware about security like
> 90% of Windows normal users...

And still you don't learn what to ask on the right mailing list.
Stop trolling.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


   ___
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] Why we should NEVER use inetd/xinetd

[Luca Ferrari]

On Wed, Oct 26, 2016 at 1:02 AM, K. Fossil user
 wrote:
> For example, today I've learned that Luca is not aware about security like
> 90% of Windows normal users...

And still you don't learn what to ask on the right mailing list.
Stop trolling.
___
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] Why we should NEVER use inetd/xinetd

[K. Fossil user]

Hi,

>« Oh, I thought we were on fossil-users here... »

Many people are interested in security talks, but not you.
You are so good in this area, aren't you ?
When it comes to servers, especially TCP/IP things, one should consider 
security seriously.
People will talk again to you the day when a security breach happens to you 
with some software you do mostly use...

>« Ok, so why are you posting here instead of simply accepting what you have 
>been told as a religious dogma? »

You know nothing about security, don't you ?

>« OpenBSD releases twice per year, May and November, so how would you judge 
>such "trend"? »

a) My trend discuss is an example : many things are good sign.
b) OpenBSD have got security issue sometimes, check CVE.
In the past they've said that they have god no issues, and one day some issue 
was discovered.
Strange no ?
c) When I talk about security it is general purpose, not a specific one such as 
OpenBSD.
I don't even talk about Linux, why should I talk about OpenBSD that is a niche ?

>« Really, I don't see the point of all of this. »

... because you never face security issue in your life.

>« My fault. »

No, you don't have the skills to understand : you could not know everything.
That is one of the reason why I am here : I don't know anything about Fossil, I 
always learn something new most of the time.
For example, today I've learned that Luca is not aware about security like 90% 
of Windows normal users...


Best Regards

K.

  De : Luca Ferrari 

*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] Why we should NEVER use inetd/xinetd

[Luca Ferrari]

On Tue, Oct 25, 2016 at 3:35 AM, K. Fossil user
 wrote:
> a) I don't talk about Fossil. My talk is about inetd/xinetd issue when it
> comes to security.

Oh, I thought we were on fossil-users here...

> You really want to know what an expert in computers security said to us ?
> "Never use xinetd or inetd or something like that."
> Isn't never, never ?
> I don't argue against an expert...

Ok, so why are you posting here instead of simply accepting what you
have been told as a religious dogma?

> c) Age is not a poor gauge, it is a good one when you see the trends : few
> release are signs of few reviews and so on...

Uhm...or more releases are signs of a poor quality/testing/release
engineering/...
OpenBSD releases twice per year, May and November, so how would you
judge such "trend"?

Really, I don't see the point of all of this.
My fault.

Luca
___
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] Why we should NEVER use inetd/xinetd

[K. Fossil user]

Hi,

Thanks to Joerg who give some nice perspective about software.
Thank to Warren which tries to talk.

Warren said :
>« I just did a search for inetd at the NVD CVE search, and got nothing 
>relevant to running Fossil under inetd »

a) I don't talk about Fossil. My talk is about inetd/xinetd issue when it comes 
to security.
Clearly speaking, there COULD be security breach with 
inetd/xinetd/what-ever-it-is
b) There are nothing because, the latest release is 4 years later and no one 
would like to use such a software.
c) I've said that it is not recommended so who am I to think that you will find 
something in any CVE ?

>« Perhaps you have misunderstood your advisors, who are really saying that you 
>shouldn’t be using in.telnetd and such any more, which are merely *associated* 
>with inetd, but which are not inetd themselves. »

You really want to know what an expert in computers security said to us ?
"Never use xinetd or inetd or something like that."
Isn't never, never ?
I don't argue against an expert...

>« I am just telling you that the age of the software is a poor gauge to its 
>security »

a) no one said that the age of a software is an important gauge to its security.
b) The age of the LATEST change of a software may explain in part that it is 
widely used or not.
Then you could imagine if bugs could be found or not.
c) Age is not a poor gauge, it is a good one when you see the trends : few 
release are signs of few reviews and so on...

>« The responses just tell the original poster of that thread that *he* 
>probably doesn’t need it »

Nope, the answer explains that FreeBSD use what should be used: You call that 
best practice.
Most of the time it is for security reason when people decided to make changes.
Notice that it is said that inetd should not be used :
It is even said « run separate daemons » ...


At least read Joerg explanations ...They are well explained. :-P


Best Regards

K.

  De : Warren Young 

*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] Why we should NEVER use inetd/xinetd

[Joerg Sonnenberger]

On Mon, Oct 24, 2016 at 02:36:23PM -0600, Warren Young wrote:
> On Oct 24, 2016, at 2:16 PM, Joerg Sonnenberger  wrote:
> > 
> > On Mon, Oct 24, 2016 at 09:56:45AM -0600, Warren Young wrote:
> >> The only common exception is this recent trend of replacing old,
> >> bloated software that grew organically over decades with well-focused
> >> fresh alternatives.  (e.g. BIND vs nsd/unbound, LibreSSL vs OpenSSL,
> >> Postfix vs Sendmail, etc.)
> > 
> > Bad examples. BIND was rewritten from scratch on a regular base
> 
> Really?  The only time BIND was ever completely rewritten to my
> knowledge was for BIND 9, which is now 16 years old.

Either BIND4 or BIND5 was a complete rewrite as well.

> More to the point, nsd + unbound still isn’t as functional as BIND 9,
> meaning there are fewer places for bugs to hide.

Well, the primary difference is that nsd by design is not caching. That
rules out all the cache poisoning attacks, one of the biggest problems
in bad BIND deployments. Of course, if you followed DNS best practises,
you would have been using authoritive-only servers with BIND as well...

> > LibreSSL doesn't fix any of the fundamental issues of OpenSSL
> 
> It fixes at least one, being the OpenSSL had turned into a kind of
> crypto dumping ground, so that the library supports virtually every
> weird crypto idea that’s ever been tried out around the SSL space for
> the past couple of decades.

So? The crypto primitives rarely have any issues at all. There is a
somewhat questionable recent trend to make all kinds of timing "attacks"
a major thing, but that's about it.

> LibreSSL strips a whole lot of that out, so that it only supports
> modern TLS, no legacy SSL or nonstandard extensions, and then only the
> parts that are currently well-regarded, so that a program linked
> against it is not vulnerable to any of the bugs in those rarely-used
> parts of OpenSSL.

I know the marketing language as well. It completely forgets that the
primary reason why a lot of software was still using OpenSSL until
recently was exactly this compatibility. SSLv3 hasn't even decomposed
properly yet. The reality is that if your customer facing web server
rejects a non-trivial number of potentially paying customers, people are
going to hang the admin. It doesn't matter whether there are some
theoretical security issues if a company is losing enough revenue. There
are still a lot of devices installed that only support SSLv3. There is a
reason why the deprecation process took so long.

> There have been cases where a program linked against OpenSSL was vulnerable 
> but not when linked to LibreSSL:
> 
>   https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-3566
>   https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-3567

...and there have been cases where LibreSSL riped things out and broke
things by that.

> If you simply mean that there is a certain amount of horridness to the
> OpenSSL API and that LibreSSH shares this, then yes, that is true. 
> The only fix is a redesign, which means you break compatibility with
> all the programs that currently depend on OpenSSL or LibreSSL.

It is not a certain amount. The API is one of the worst thing ever done.
LibreSSL hasn't improved things at all by claiming to be OpenSSL 2.x or
some other random junk.

> Ideally, LibreSSL is just a bridge to something better, but knowing the
> way software inertia works, I wouldn’t bet on us getting to that
> something-better any year soon.

Better alternatives exist. Many of them were not feasible for a long
time due to the SSLv3 constraint, but that is finally gone. One of the
problems is that dealing with complex highly conditional data structures
is a mess in C. It gets worse when people assume that char arrays are
NUL-terminated etc. At the same time, library developers want to
constraint the input without understanding the way how X509 is used in
practise. Correct TLS use is more than just "use this certificate and
encrypt that data"...

> > Postfix is more secure than (old) sendmail due to a different
> > architecture. :)
> 
> Yes, Postfix is a pile of much smaller cooperating programs rather than
> a monolithic program as with sendmail, each of which may be debugged
> and privilege separated from the rest, which is exactly my point.
> (“…well-focused fresh alternative…”)

sendmail has also been reworked to fix some of the implementation
problems. It is telling that the last CVE is from 2014 and the one
before was from 2009. That's a lot better than some of the replacements
designed for "security". Which brings back the original point of
"mature" != "insecure".

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] Why we should NEVER use inetd/xinetd

[Warren Young]

On Oct 24, 2016, at 2:16 PM, Joerg Sonnenberger  wrote:
> 
> On Mon, Oct 24, 2016 at 09:56:45AM -0600, Warren Young wrote:
>> The only common exception is this recent trend of replacing old,
>> bloated software that grew organically over decades with well-focused
>> fresh alternatives.  (e.g. BIND vs nsd/unbound, LibreSSL vs OpenSSL,
>> Postfix vs Sendmail, etc.)
> 
> Bad examples. BIND was rewritten from scratch on a regular base

Really?  The only time BIND was ever completely rewritten to my knowledge was 
for BIND 9, which is now 16 years old.  nsd is a couple of years younger than 
that, and unbound is about half that age.

More to the point, nsd + unbound still isn’t as functional as BIND 9, meaning 
there are fewer places for bugs to hide.

> LibreSSL doesn't fix any of the fundamental issues of OpenSSL

It fixes at least one, being the OpenSSL had turned into a kind of crypto 
dumping ground, so that the library supports virtually every weird crypto idea 
that’s ever been tried out around the SSL space for the past couple of decades.

LibreSSL strips a whole lot of that out, so that it only supports modern TLS, 
no legacy SSL or nonstandard extensions, and then only the parts that are 
currently well-regarded, so that a program linked against it is not vulnerable 
to any of the bugs in those rarely-used parts of OpenSSL.

There have been cases where a program linked against OpenSSL was vulnerable but 
not when linked to LibreSSL:

  https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-3566
  https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-3567

If you simply mean that there is a certain amount of horridness to the OpenSSL 
API and that LibreSSH shares this, then yes, that is true.  The only fix is a 
redesign, which means you break compatibility with all the programs that 
currently depend on OpenSSL or LibreSSL.

Ideally, LibreSSL is just a bridge to something better, but knowing the way 
software inertia works, I wouldn’t bet on us getting to that something-better 
any year soon.

> Postfix is more secure than (old) sendmail due to a different
> architecture. :)

Yes, Postfix is a pile of much smaller cooperating programs rather than a 
monolithic program as with sendmail, each of which may be debugged and 
privilege separated from the rest, which is exactly my point.  (“…well-focused 
fresh alternative…”)
___
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] Why we should NEVER use inetd/xinetd

[Joerg Sonnenberger]

On Mon, Oct 24, 2016 at 09:56:45AM -0600, Warren Young wrote:
> The only common exception is this recent trend of replacing old,
> bloated software that grew organically over decades with well-focused
> fresh alternatives.  (e.g. BIND vs nsd/unbound, LibreSSL vs OpenSSL,
> Postfix vs Sendmail, etc.)

Bad examples. BIND was rewritten from scratch on a regular base,
LibreSSL doesn't fix any of the fundamental issues of OpenSSL and
Postfix is more secure than (old) sendmail due to a different
architecture. :)

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] Why we should NEVER use inetd/xinetd

[Warren Young]

On Oct 22, 2016, at 3:23 PM, K. Fossil user  
wrote:
> 
> 1/ As I've stated in the past according to people I do know, for security 
> reason, inetd/xinetd is not recommended.

I just did a search for inetd at the NVD CVE search, and got nothing relevant 
to running Fossil under inetd:

  
https://web.nvd.nist.gov/view/vuln/search-results?query=inetd_type=all=on

The only serious problems still extant in that search result are:

1. Stock inetd doesn’t do rate limiting and such, but xinetd does, so in that 
sense, the problem is fixed.

2. Some implementations of inetd do their own naive logging and could thus fill 
the system disk.  Again, the solution is to use xinetd, which defaults to 
syslogd, which is generally protected against that problem.

So, what security issue are you talking about?

Perhaps you have misunderstood your advisors, who are really saying that you 
shouldn’t be using in.telnetd and such any more, which are merely *associated* 
with inetd, but which are not inetd themselves.

> 2/ Xinetd is old (four years ?) so may be not secure.

Older software is often more secure than newer software, not less, being 
well-tested and well-understood.

The number of bugs in a software system is a loose function of the number of 
lines of code in that system, and of the lifetime of each line of code.  
Therefore, an old, stable system with 5 kSLOC will typically have far less than 
half the number of bugs than a new 10 kSLOC system.

The only common exception is this recent trend of replacing old, bloated 
software that grew organically over decades with well-focused fresh 
alternatives.  (e.g. BIND vs nsd/unbound, LibreSSL vs OpenSSL, Postfix vs 
Sendmail, etc.)

xinetd is not a good example of such a system.  The only other common 
alternatives to xinetd (launchd and systemd) are even worse examples.

I am not saying that xinetd is less secure than inetd.  (It may be; I just 
don’t know, one way or the other.)  I am just telling you that the age of the 
software is a poor gauge to its security.

> 3/ And this info should definitely helps :
> rc or inetd? What should I use? | The FreeBSD Forums
> 
> « Modern FreeBSD installations run separate daemons for almost every service 
> nowadays, and inetd is all but deprecated. It's probably only around for 
> historical/compatibility reasons. Starting services from /etc/rc.conf is the 
> modern FreeBSD way. »

I read that whole forum thread, and nothing in there talks about the security 
of running a service like Fossil under [x]inetd.  The responses just tell the 
original poster of that thread that *he* probably doesn’t need it.  Different 
situations get different answers.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users