Python as network protocol

[geremy condra]

On Tue, Nov 10, 2009 at 10:56 AM, Steven D'Aprano
<steve at remove-this-cybersource.com.au> wrote:
> On Tue, 10 Nov 2009 16:31:13 +0100, Daniel Fetchinson wrote about using
> exec:
>
>>> This is a *really* bad idea.
>>
>> How do you know for sure? Maybe the OP wants to use this thing with 3
>> known researchers working on a cluster that is not even visible to the
>> outside world. In such a setup the model the OP suggested is a perfectly
>> reasonable one. I say this because I often work in such an environment
>> and security is never an issue for us. And I find it always amusing that
>> whenever I outline our code to a non-scientist programmer they always
>> run away in shock and never talk to us again
>
> You might be a great scientist, but perhaps you should pay attention to
> the experts on programming who tell you that this is opening a potential
> security hole in your system.
>
> No, it's not a "perfectly reasonable" tactic. It's a risky tactic that
> only works because the environment you use it in is so limited and the
> users so trusted. Can you guarantee that will never change? If not, then
> you should rethink your tactic of using exec.
>
> Besides, as a general rule, exec is around an order of magnitude slower
> than running code directly. If performance matters at all, you are better
> off to try to find an alternative to exec.
>
>
>> Nevertheless our code works perfectly for our purposes.
>
> Until the day that some manager decides that it would be great to make
> your code into a service available over the Internet, or until one of the
> other scientists decides that he really needs to access it from home, or
> somebody pastes the wrong text into the application and it blows up in
> your face... it's not just malice you need to be careful of, but also
> accidents.
>
> The history of computing is full of systems that were designed with no
> security because it wasn't needed, until it was needed, but it was too
> late by then.
>
> There's no need, or at least very little need, to put locks on the
> internal doors of your house, because we're not in the habit of taking
> internal doors and turning them into outside doors. But code designed to
> run inside your secure, safe network has a tendency to be re-purposed to
> run in insecure, unsafe networks, usually by people who have forgotten,
> or never knew, that they were opening up their system to code injection
> attacks.
>
>
>
> --
> Steven

Steven, remember a few weeks ago when you tried to explain to me that
the person who was storing windows administrative passwords using a
40 byte xor cipher with the hardcoded password might not be doing
something stupid because I didn't know what their threat model was?
Yeah- what you just said is what I was trying to explain then.

Geremy Condra