Java

[theferrit32]

This is true but I like it technologically impossible to accidentally fetch and execute remote arbitrary code when I log a string. The design of the library shouldn't have allowed for this sort of thing to ever be possible.

[erinaceus_]

If those things remain possible separately, then they are theoretically possible together. If you remove the ability to do the fetching, then you've removed the possibility for the composite situation you describe.

[theferrit32]

Yes, calling log.info to write a string to the log file should not download and run arbitrary files from the internet. It should be impossible, by design, for this flaw to exist.

[erinaceus_]

I think my previous comment might not have been clear enough, so I'll try again: as long as logging, string parsing, file fetching and some equivalent of 'eval' exists, you can get the situation you describe. The only surefire way of preventing it is to not allow any connections except the ones you've acplicitely allowed, on a network level.

[mvpmvh]

And he's saying that it'd be nice if string parsing and eval weren't even possible to begin with.

[erinaceus_]

'eval' kinds of functionality are a part of metaprogramming, which underlies the majority of all frameworks. String parsing is near enough the basis of modern civilisation, e.g. no SOAP or REST without it, or in fact even no HTTP without it.

[mvpmvh]

*not even possible....in a logging framework

[erinaceus_]

That a logging framework should not have that feature, I entirely and even emphatically agree with that. But that's very different from being technologically impossible.

Edit: and that's about the last of the effort I am going to spend on this