[acqq]

nostrademons's comment is for me the most important comment here in this discussion. Thanks nostrademons!

Just as an illustration, from the linked page:

"Security. Gumbo was initially designed for a product that worked with trusted input files only. We're working to harden this and make sure that it behaves as expected even on malicious input, but for now, Gumbo should only be run on trusted input or within a sandbox."

[bct]

That's an issue with this implementation, not the idea of hooking up stdin/stdout to websockets.

[colanderman]

Nostrademons doesn't know what he's talking about. See bct's comment, and my heavily-downvoted comment. Security has nothing to do with using STDIO and everything to do with how you code your program.

[nostrademons]

http://xkcd.com/386/

If you have corrections, post them, which you did up above. My post is being upvoted because it makes people think about considerations that they didn't think about before, which is a good thing. Further details are also a good thing, but I've found - through numerous engineering projects - that if you think you've found the "right" solution and someone is just "wrong", there's usually a trade-off you missed somewhere and a concern they're considering that you're not.

Anyway, I don't think that your conclusion ("Security has nothing to do with using STDIO and everything to do with how you code your program") and my conclusion ("You can do this, but you better consider the attack surface you're opening your program up to first") are all that incompatible. My point is that most programs with an interface on STDIN are not designed out of the box to be run on untrusted, potentially malicious input, and so you will have to spend time hardening yours that far exceeds the time you spend hooking up the network protocol to STDIN.

[colanderman]

> My point is that most programs with an interface on STDIN are not designed out of the box to be run on untrusted, potentially malicious input, and so you will have to spend time hardening yours that far exceeds the time you spend hooking up the network protocol to STDIN.

Yes, that is a valid point. However that is not what you said, which was:

> Problem is that it requires that the app handle all the security aspects of talking to the Internet

which is not unique to applications using this daemon, or even to WebSocket applications in general. That's borderline FUD. Combined with the inaccurate statements you made to back it up, your original post is simply incorrect and misleading.

> if you think you've found the "right" solution and someone is just "wrong", there's usually a trade-off you missed somewhere and a concern they're considering that you're not.

No, not if the "right" solution is backed by facts and research, and the "wrong" solution is based on demonstrably incorrect half-remembered mistruths from ten years ago. There's not really a tradeoff there.

[fit2rule]

There is no reason not to think that anyone who has written an app to use STDIO may be more likely, in fact, to have a safe string-parsing/protocol handler setup. I mean, there is no guarantee that just because an app uses STDIO, they have exposed their strlen() and its ilk to the world ..

This table is not complete:

http://bstring.sourceforge.net/features.html

.. and the thing is, its not the 90's any more. There are a lot of great tools that can be exposed on this interface, if you think about it, quite safely ..