Python secure?

Terry Reedy tjreedy at
Mon Aug 16 19:49:20 CEST 2004

"Peter Hansen" <peter at> wrote in message
news:NIydnd-skK0q173cRVn-ow at
> Reid Nichol wrote:
> > Terry Reedy wrote:
> >
> >> ... compiled C can be terribly insecure relative to
> >> Python.  C has dangerous functions like strcpy() which, if used with
> >> external input, can make a program subject to buffer overrun exploits
> >> that
> >> can do explosive damage.
> >
> > But this doesn't make C an insecure language.  No language is either
> > secure nor insecure.  It's what the programer does with it that

Yes, and in a later sentence, I said something about smarter programmers
and code check policies.  Indeed, by the mid-1980s, I knew that giving
control of copying to the block copied, by copying until the block
contained a null byte, could be dangerous.  But somewhere around 2000,
Microsoft shipped product that did exactly that with data taken off the

> New definition for the purposes of this discussion:
> "secure language": a programming language which, by virtue of
> its structure, libraries, syntax, runtime, or other features
> supports and tends to encourage the creation of software which
> doesn't have gross security holes".  Viz. "Python"
> "unsecure language": a programming language which, by virtue
> of its structure, primitive libraries, awkward syntax, non-
> existent runtime, or other limitations tends to encourage
> and lead to the creation of software with gross security
> holes".  Viz. "C"

Thanks, Peter, for explaining what I meant better than I could have.  In
particular, as I said, buffer overruns are easily possible in C and
impossible, as far as I know, in pure Python.  Furthermore, I believe that
this is an intentional part of the design of each language, which make
intentionally different tradeoffs between safety and speed.

> A given programmer will be more likely to create safe and
> secure software using Python than with C, thereby making
> C the less secure...

Especially if a programmer is rewarded for faster code -- which one write
by copying dangerously -- and pushing the hidden costs off onto customers.

Terry J. Reedy

More information about the Python-list mailing list