>> 128 bits seems like overkill: There's no birthday attack because
>> no-one keeps 2^(ENTROPY_BITS/2) files around
> You haven't seen my Downloads folder... :-)
I put it to you that those files are not temporary :-)
> Why be so miserly with entropy?
I don't necessarily disagree.
> Using 128 bits is just 22 characters using secrets.token_urlsafe().
A little more when you take into account case-insensitive file systems.
>>> So use NamedTemporaryFile(delete = False) and close it before passing it to the other program.
>> That's effectively the same as calling tempfile.mktemp. While it does waste time opening and closing an unused file, that doesn't help with security
> That is not actually true. The important difference is that with NamedTemporaryFile the file exists with appropriate access right (0600).
You are right, I must have mentally reversed the polarity of the delete argument. And I didn't realise that the access right on a file had the power to prevent itself from being removed from the folder that it's in. I thought the access flags were a property of the file itself and not the directory entry. Not sure how that works.
But if NamedTemporaryFile(delete=False) is secure then why not use that to implement mktemp?
def mktemp(suffix="", prefix=template, dir=None):
with NamedTemporaryFile(delete=False, suffix=suffix, prefix=prefix, dir=dir) as f:
Yes, it does leave an empty file if the name is not used, but the name is usually created with the intent to use it, so that is rarely going to be a problem. Just document that that's how it is. It does mean that where there's an explicit file-exists check before writing the file, that code will break. But it will break a lot less code than removing mktemp entirely.
> So use NamedTemporaryFile(delete = False) and close it before passing it to the other program.
That's effectively the same as calling tempfile.mktemp. While it does waste time opening and closing an unused file, that doesn't help with security. If anything, it might worsen security.
If a secure implementation of mktemp is truly impossible, then the same could be said for NamedTemperatoryFile(delete=False). Should that be deprecated as well?
VxWorks RTOS will release a new version at the end of June. For this new version, we(Wind River) plan to announce the Python support officially here (https://www.python.org/download/other/) for VxWorks as tier 2 platform. Now my 2 questions come:
1. To be qualified as tier 2 platform here https://www.python.org/download/other/, do I need to get all test cases pass on VxWorks RTOS? Now we have the following PRs for VxWorks. With these PRs merged, we can get around 70% test cases PASS.
2. If we reach the announcement level, what is the workflow to update the website statements here https://www.python.org/download/other/. The following picture shows what we want to show.
> And if there is an easy replacement, then how about re-implementing
> mktemp() using that replacement, instead of removing it?
Indeed. The principal security issue with mktemp is the difficulty in creating a user-specific thing under a shared /tmp folder in a multi-user setup.
But if it hurts when you use /tmp, why use /tmp? Use a path with no world-accessible ancestor, or at least no world-writable ancestor.
On Windows, that means creating it somewhere under the CSIDL_LOCAL_APPDATA folder. Which is already the default for %TEMP% and %TMP%.
On Unix, it's a $HOME subfolder with access 700 or 600.
How about switching mktemp over to use that?
For windows arm32 I would like to be able run tests in the buildbot.
Windows arm32 programs built with MSVC are always cross-compiled.
This means I need to build cpython on x86/x64 and then deploy the build artifacts and run the tests on an ARM32 device.
Is there any documentation or examples of how to do this?
If not, are there any recommendations for how to achieve this?
On behalf of the Python development community, I'm proud--if slightly
sad--to announce the availability of Python 3.4.10.
Python 3.4.10 was released in "security fixes only" mode. It only
contains security fixes, not conventional bug fixes, and it is a
Python 3.4.10 is the final release in the Python 3.4 series. As of this
release, the 3.4 branch has been retired, no further changes to 3.4 will
be accepted, and no new releases will be made. This is standard Python
policy; Python releases get five years of support and are then retired.
If you're still using Python 3.4, you should consider upgrading to the
current version--3.7.2 as of this writing. Newer versions of Python
have many new features, performance improvements, and bug fixes, which
should all serve to enhance your Python programming experience.
We in the Python core development community thank you for your interest
in 3.4, and we wish you all the best!
You can find Python 3.4.10 here:
One I completely finish the Python 3.4.10 release process, I will retire
as Python 3.4 Release Manager. I'll still be Python 3.5 Release Manager
for another eighteen months or so.
Python 3.4 is OVER!
On behalf of the Python development community, I'm chuffed to announce
the availability of Python 3.5.7.
Python 3.5 is in "security fixes only" mode. It only accepts security
fixes, not conventional bug fixes, and the release is source-only.
And you can find Python 3.5.7rc1 here: