Re: [Python-Dev] Removing PendingDeprecationWarning
On Fri, Mar 22, 2019 at 6:19 PM Inada Naoki wrote: > On Sat, Mar 23, 2019 at 3:02 AM Brett Cannon wrote: > > > >> > >> There might be some small troubles. But it was small enough for > >> Python minor versions, I think. > > > > > > I don't think it's worth the cost to users. We can just choose to stop > using it in the stdlib and not use PendingDeprecationWarning. And if people > want to force others to define their own PendingDeprecationWarning by > deprecating that's fine, but the aliasing where it could cause unintended > exception swallowing for something related to breaking changes seems > unnecessarily risky to me simply because we don't want to ask users to > update their code in a backwards-compatible fashion. > > I still can't believe there are real world usage of > PendingDeprecationWarning > other than warnings.warn() and assertRaises(). > I've made the same mistake of assuming something that made no sense to me wouldn't make sense to anyone else and I have been proven wrong nearly every time. ;) -Brett > > But I'm OK to not removing actual class. > > Stop using it in stdlib reduces maintenance cost like this: > https://github.com/python/cpython/pull/12494/files > > And deprecation in document reduces learning cost. > People can skip reading and understanding document of > PendingDeprecatedWarning. > > Keeping PendingDeprecationWarning class for several years is very > low cost compared to these cost. > > Regards, > -- > Inada Naoki > ___ 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
Re: [Python-Dev] Remove tempfile.mktemp()
On 20Mar2019 12:53, Jeroen Demeyer wrote: On 2019-03-20 12:45, Victor Stinner wrote: You can watch the /tmp directory using inotify and "discover" immediately the "secret" filename, it doesn't depend on the amount of entropy used to generate the filename. That's not the problem. The security issue here is guessing the filename *before* it's created and putting a different file or symlink in place. So I actually do think that mktemp() could be made secure by using a longer name generated by a secure random generator. I know it is days later, but to add a little nuance: the security issue is guessing the filename before it is _used_. Consider: path = tempfile.mktemp() with open(path, "w"): write some secret stuff ... call_other_function(path) If an attacker gets in _after_ the open (which creates the file) by using something like inotify to _observe_ the pathname instead of guessing and supplants the file then, call_other_function is then subverted. Also, the common examples are attackers who are not the user making the tempfile, in which case the _default_ mktemp is sort of secure with the above because it gets made in /tmp which on a modern POSIX system prevents _other_ uses from removing/renaming a file. (And Eryk I think described the Windows situation which is similarly protected). However, mktemp somewhere else is not so protected. And the attacker might be malware running as the orignal user (yes the game may already be overin that case for other reasons). However, I wanted to make the point that the security issue isn't around creation but use - trusting the mktemp pathname to be the same state as it was earlier. Cheers, Cameron Simpson ___ 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
Re: [Python-Dev] Remove tempfile.mktemp()
On 3/23/19, Cameron Simpson wrote:
>
> Also, the common examples are attackers who are not the user making the
> tempfile, in which case the _default_ mktemp is sort of secure with the
> above because it gets made in /tmp which on a modern POSIX system
> prevents _other_ uses from removing/renaming a file. (And Eryk I think
> described the Windows situation which is similarly protected).
Using NamedTemporaryFile(delete=False) or mkstemp() ensures that the
file is created and opened securely. in contrast, the filename from
mktemp() might be used naively in POSIX, such as open(path, "w"). This
file might grant read access to everyone depending on the file-mode
creation mask (umask). Also, since it neglects to use exclusive mode
("x"), it might open an existing file that grants read-write
permission to the world, or maybe it's a symlink.
By default, even naive use of the mktemp() name in Windows remains
secure, since every user has a separate temp directory that's only
accessible by privileged users such as SYSTEM, Administrators, and
Backup Operators (with SeBackupPrivilege and SeRestorePrivilege
enabled). The primary issue with a short name is an accidental name
collision with another program that's not as careful as Python's
tempfile. Using a longer name decreases the chance of this to
practically nothing.
___
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
Re: [Python-Dev] Removing PendingDeprecationWarning
On Sun, Mar 24, 2019 at 8:07 AM Brett Cannon wrote: > > > I've made the same mistake of assuming something that made no sense to me > wouldn't make sense to anyone else and I have been proven wrong nearly every > time. ;) > > -Brett > And beta and RC phase can be used to detect such breakage. When no real world pain is assumed, we can chose simple solution. Then, if real world pain is found, we can move to more complicated, but backward compatible way. Of course, keeping PendingDeprecatedWarning is not complicated way in this time. So I don't push the removal. It was just an idea. -- Inada Naoki ___ 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
