[Python-Dev] Remove tempfile.mktemp()

[Guido van Rossum]

On Tue, Mar 19, 2019 at 10:14 AM Giampaolo Rodola' <g.rodola at gmail.com>
wrote:

>
> On Tue, 19 Mar 2019 at 17:47, Sebastian Rittau <srittau at rittau.biz> wrote:
>
>> Am 19.03.19 um 17:23 schrieb Giampaolo Rodola':
>> > @Sebastian
>> >> If there are valid use cases for mktemp(), I recommend renaming
>> >> it to mkname_unsafe() or something equally obvious.
>> > I'm -1 about adding an alias (there should be one and preferably only
>> > one way to do it). Also mkstemp() and mkdtemp() are somewhat poorly
>> > named IMO, but I wouldn't add an alias for them either.
>> >
>> Just to clarify: I was not suggesting creating an alias, I was suggesting
>> renaming the function, but keeping the old name for a normal
>> deprecation cycle.
>>
>> But I had another thought: If I understand correctly, the exploitability
>> of mktemp() relies on the fact that between determining whether the
>> file exists and creation an attacker can create the file themselves.
>> Couldn't this problem be solved by generating a filename of sufficient
>> length using the secrets module? This way the filename should be
>> "unguessable" and safe.
>
>
> Technically you cannot make it 100% safe, only less likely to occur.
>

That seems unnecessarily pedantic. A cryptographic random generator, like
the one in the secrets module, *is* safe enough for all practical purposes
(with a large margin).


> And on a second thought (I retract :)) since this could be used in real
> apps other than tests (I was too focused on that) I think this should be a
> doc warning after all, not info. Doc may suggest to use mode=x when
> creating the file, in order to remove the security implications.
>

Hm, the random sequence (implemented in tempfile._RandomNameSequence) is
currently derived from the random module, which is not cryptographically
secure. Maybe all we need to do is replace its source of randomness with
one derived from the secrets module. That seems a one-line change.

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20190319/b26fc74e/attachment.html>