Home Original page

Python/Wx dot net

Carl Waldbieser waldbie at attglobal.net
Tue Oct 7 03:50:22 EDT 2003 
----- Original Message -----
From: "HankC" <hankc at nospam.com <mailto:hankc at nospam.com>>
Newsgroups: comp.lang.python
Sent: Monday, October 06, 2003 4:13 PM
Subject: Re: Python/Wx dot net
> I thought managed code would prevent, among other things, things like
> buffer over runs. In any case, they can't do to much worse.
>
Well, that's the theory. Since managed code does not let you use pointers,
you are not supposed to be able to accidently write past the end of your
data structures. However, you can make the same arguments for Python, or
Java, or a lot of other languages that don't let you "get down to the
metal". Of course, Python is written in C, so if there was a bug in the
interpreter code, it could overwite a buffer on your behalf (of course this
is purely hypothetical ;-) ). It is really somewhat misleading to say
"buffer overruns are now impossible." It would probably be more accurate to
say, "if you trust Microsoft, or if you trust Sun, or if you trust the
Python Dev team and the Open Source community, you are trusting that they
are going to make sure that there are not going to be buffer overruns in
*their* code."

To some extent, I would suppose it is less likely for code that is generated
by a widely used compiler or interpreter to make the same kind of mistakes
that would otherwise be made by hand. But even machine generated code could
have some hidden, exploitable bug. I have never in the course of programming
with Python come across what I would have recognized as a bug in the
interpreter. However, the fact that there are bug-fix releases suggests that
there has in fact been code that was incorrectly interpreted by a particular
implementation. The same is also probably very true of .NET managed code. It
all comes down to who you are going to trust.

I'm not sure if Microsoft relases bug-fix information for .NETor not, so I
really am not sure the extent I can trust that their code is going to be any
more secure than say using some third party C++ libraries and tools like
lint.  I probably can assume that if a problem exploitable by malfefactor
emerges, Microsoft will try to correct it as quickly as possible-- but there
are also rumour floating around that suggest that maybe they would just try
to conceal it instead.  I don't have the answers here, and Microsoft has
picked up a bad reputation in this regard.  It doesn't necessarily mean it's
true, but it doesn't particulary increase my confidence.

Since Python's source code is freely available, it's a lot easier for me to
trust it.  If I have particular concerns, I can look at the source myself,
or I can ask people with more expertise to look at it for me.  And if there
is a bug discovered, I don't have to take a passive role and sit around
waiting for someone to correct the problem for me-- I can take an active
role.  I could patch it myself (if it's within my technical capabilites), or
I could hire a team of experts to patch it (if it's in my budget).  I can
still just submit a bug report, too, but the fact that the bug is going to
be in the open at least lets others be aware of what's going on.  For these
reasons, I feel I can have a good deal of trust using Python.

Saying that code written in (unmanaged) C or C++ is inherently not secure is
also misleading.  C and C++ catch a lot of flak because it is possible to
accidently have buffer overrun errors and enter the dreaded realm of
"undefined behavior".  These mistakes tend to be especially common when you
are just starting out in either of these languages.  However, both these
languages have been around for quite some time, and a good deal of effort
has gone into producing sophisticated tools for detecting these kind of
errors.  Again it boils down to trust.  Am I going to trust code that I
wrote?  Code that someone wrote for the Standard Library?  Code that my
compiler generated?  Can I trust my tools to catch errors that I won't?  In
some cases maybe I can trust the code-- in others, maybe I shouldn't.

Carl Waldbieser
More information about the Python-list mailing list