<br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 19 Mar 2019 at 17:47, Sebastian Rittau <<a href="mailto:srittau@rittau.biz">srittau@rittau.biz</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Am 19.03.19 um 17:23 schrieb Giampaolo Rodola':<br>
> @Sebastian<br>
>> If there are valid use cases for mktemp(), I recommend renaming<br>
>> it to mkname_unsafe() or something equally obvious.<br>
> I'm -1 about adding an alias (there should be one and preferably only<br>
> one way to do it). Also mkstemp() and mkdtemp() are somewhat poorly<br>
> named IMO, but I wouldn't add an alias for them either.<br>
><br>
Just to clarify: I was not suggesting creating an alias, I was suggesting<br>
renaming the function, but keeping the old name for a normal<br>
deprecation cycle.<br>
<br>
But I had another thought: If I understand correctly, the exploitability<br>
of mktemp() relies on the fact that between determining whether the<br>
file exists and creation an attacker can create the file themselves.<br>
Couldn't this problem be solved by generating a filename of sufficient<br>
length using the secrets module? This way the filename should be<br>
"unguessable" and safe.</blockquote><div dir="auto"><br></div><div dir="auto">Technically you cannot make it 100% safe, only less likely to occur. 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.</div><div dir="auto"><br></div></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Giampaolo - <a href="http://grodola.blogspot.com" target="_blank">http://grodola.blogspot.com</a></div><div><br></div></div></div>