On Tue, Mar 19, 2019 at 10:22 AM Guido van Rossum <gu...@python.org> wrote:
> On Tue, Mar 19, 2019 at 10:14 AM Giampaolo Rodola' <g.rod...@gmail.com> > wrote: > >> >> On Tue, 19 Mar 2019 at 17:47, Sebastian Rittau <srit...@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. > If the only security vulnerability is due to the ability to guess a path that would make sense (but I honestly don't know since I'm not a security expert). If Guido's suggestion isn't enough then I think that long with a rename of the function to make it obvious that there's potential issues and deprecating the old name makes the most sense.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
