[LUAU] high performance SCP/SSH

[Jim Thompson]

On Feb 19, 2008, at 1:38 PM, Kristian Erik Hermansen wrote:

> On Feb 19, 2008 11:58 AM, Jim Thompson <jim at netgate.com> wrote:
>> No, I don't.  Especially since it doesn't.
>
> And which networking stack, would you say, does?  OpenBSD prevent  
> manyth
> common and uncommon TCP, ICMP, and other protocol attacks.


> They do heavy port randomization assignment for new connections and  
> try to
> mitigate against things like ICMP path mtu discovery issues.  Are you
> familiar with these attacks? (without using google right now -- I mean
> real experience protecting against them).

Yes.   You may wish to google for the origination of the "Netgate"  
trademark (as a hint, smallworks.com was the company.)

>  I am wondering if you dare to claim FreeBSD as to having superior  
> secure networking stack :-)

Sure, I'll bring an otherwise stock FreeBSD 7.0 system, with the  
following commands run, and stack it against your OpenBSD of any  
vintage system.

sysctl -w net.link.ether.inet.max_age=1200
sysctl -w net.inet.icmp.bmcastecho=0
sysctl -w net.inet.icmp.masqrepl=0
sysctl -w net.inet.ip.sourceroute=0
sysctl -w net.inet.ip.accept_sourceroute=0
sysctl -w kern.ipc.somaxconn=1024
sysctl -w net.inet.tcp.sendspace=32768
sysctl -w net.inet.tcp.recvspace=32768
sysctl -w net.inet.ip.redirect=0
sysctl -w net.inet.ip6.redirect=0

these last two may be useful on your OpenBSD machine as well.


>> I'm sure.   (You may wish to re-parse your words here.)
>
> Right.  I meant, if there is a sniffle of an issue, OpenBSD hops on
> board to investigate, and if it is considered an issue, they try to
> fix or at least mitigate.

Do you mean to imply that, linux and FreeBSD teams do not behave  
similarly?

> Openwall Linux does much of this as well, but perhaps more of their  
> patches lie on the address
> mapping/allocation/protection side of things.

Because Theo claimed this was impossible on x86.

> You commonly see new techniques being implemented there first...
>
>> Yes, I have looked at the history of the OpenBSD stack and software
>> issues.
>>
>> That was my point.   You seem to have missed it in your fandom for
>> Theo's "groupthink".
>
> Please do explain your stance.  I don't have much fandom for guys who
> are assholes.  In fact, I met Peter Hessler in San Francisco who told
> me some funny stories about being invited to the OpenBSD sprint at
> Theo's house.  Good guy.  Good stories.  Maybe you don't know them :-)
> I am *not* an OpenBSD fanboy.  I run Linux mostly and BSD when I deem
> necessary.

> OpenBSD + amd64 + Gnome is not a good choice, I can assure you!

I'm not sure that either OpenBSD or Gnome is a good choice.   I  
covered some of this back in August on this list:

http://lists.hosef.org/pipermail/luau/2007-August/017825.html
http://lists.hosef.org/pipermail/luau/2007-August/017827.html
and, most critically:
http://lists.hosef.org/pipermail/luau/2007-August/017829.html
http://lists.hosef.org/pipermail/luau/2007-August/017834.html

Please review these and if you still wish me to "explain my  
stance" (that OpenBSD's approach is fundamentally flawed), I'll  
attempt to further euclidiate.

Lets just say it now, OpenBSD is not my <http://www.youtube.com/watch?v=hC2LAIDidis&feature=related 
 > kind of party.  (May be NSFW, depending on your company standards...)

>> While this is a true statement, a properly-constructed system
>> ('infrastructure') shouldn't be open to this type of failure.
>
> Right.  OK, build it.  Let us know when your 1.0 release is :-)

Its already been built.   Several times.  Multics and/or several  
variations of Lisp Machine.

> I'll even buy you a beer.  Building quality software, that you can  
> prove is secure/stable/non-buggy, is NP-hard...

This kind of proof is usually based on the algorithms and data  
structures. For instance, there are various proofs showing that the  
general problem of proving the correctness of programs containing at  
least two levels of pointer indirection to manipulate doubly linked  
lists is NP-hard.
Yes, its difficult, especially with 'C', but I don't see any  
mathematical evidence that the problem is in P or NP.  And I don't  
mean to rag on 'C', the problem is equivalent for any sufficiently  
expressive language, and the class of programs in that language will  
of course be NP-hard to verify in general. The point I am trying to  
make is that there are certain constructs - such as loops and pointers  
(which are supported by almost all programming languages) - that make  
the task much harder in practice, unless additional information is  
provided, such as invariants that are expected to hold.

Problems are designated "NP-complete" if their solutions can be  
quickly checked for correctness, but they are not solvable in  
polynomial time.   The problem of building provably-correct software  
is not testable for success, though Praxis get quite close to this  
goal with SPARK with a proof rate of over 90%.
Dave Crocker has pointed out that with PD he generally finds that more  
than 90% of the loops in the program are generated from specification  
constructs, thereby making them amenable to verification using  
automated reasoning. The remaining loops are written by the developer,  
and in his experience, even people experienced with formal methods  
often fail to state a sufficient loop invariant to make the proof  
possible.
So, until we get better-trained programmers, or a better constraint- 
language in which to program, the issue of building quality software  
that you can "prove is secure/stable/non-buggy" is not NP-hard, its  
completely intractable.