[Python-Dev] Warnings
Jean-Paul Calderone
exarkun at divmod.com
Thu Feb 5 17:47:21 CET 2009
On Thu, 5 Feb 2009 08:35:30 -0800, Raymond Hettinger <python at rcn.com> wrote:
>>>import os
>>>>os.tmpnam()
>RuntimeWarning: tmpnam is a potential security risk to your program
>
This warning is a reflection of the fact that (at least) the glibc authors
think you shouldn't be using tmpnam(2). If you compile a C program that
uses it, you'll see a warning about it. Since you can write a Python
program that uses tmpnam(2) without ever compiling such a C program,
you get a RuntimeWarning instead. It's not quite analogous, since
you don't get the warning from the C program every time you run it,
but it's about as close as you can do in Python without resorting to
crazy tricks.
>
>Are these runtime warnings necessary? Suppressing these warnings is a pita
>for one-off uses of os.tmpnam() or os.tempnam().
Why are you using them? Why not just use one of the many, many, many
other APIs for generating temporary files that Python exposes? One of
the ones that doesn't emit any warnings?
>I would hate for this sort of thing to propagate throughout the standard
>library. Some folks think eval() should never be used and the same for
>input(). Some folks think md5 should be removed. Some folks think pickles
>are the ultimate security threat. IMO, it is enough to note potential
>vulnerabilities in the docs. Even then, I'm not too keen on the docs being
>filled with lots of red-outlined pink-boxed warning signs, effectively
>communicating that Python itself is dangerous and unreliable.
>
I agree. The best thing to do would be to deprecate the Python wrappers
around insecure C functions and then remove them after a couple releases.
It's not as though these functions fill a critical niche - the tempfile
module and even os.tmpfile are more than enough. Why does Python offer
this attractive nuisance?
Jean-Paul
More information about the Python-Dev
mailing list