[Python-Dev] Re: PoC: Subinterpreters 4x faster than sequential execution or threads on CPU-bound workaround

[Sebastian Krause]

Guido van Rossum  wrote:
> Is there some kind of optimized communication possible yet between
> subinterpreters? (Otherwise I still worry that it's no better than
> subprocesses -- and it could be worse because when one
> subinterpreter experiences a hard crash or runs out of memory, all
> others have to die with it.)

The use case that I have in mind with subinterpreters is
Windows. With its lack of fork() and the way it spawns a fresh
interpreter process it always feels a bit weird to use
multiprocessing on Windows. Would it be faster and/or cleaner to
start a new in-process subinterpreter instead?
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/MVYVEDXIW24I5LX2RW26P3FVBBYIO6TT/
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-Dev] Remove tempfile.mktemp()

[Sebastian Krause]

Guido van Rossum  wrote:
> If all you need is a random name, why not just use a random number
> generator?
> E.g. I see code like this:
>
> binascii.hexlify(os.urandom(8)).decode('ascii')

I tend to use os.path.join(dir, str(uuid.uuid4())) if I need to
create a random filename to pass to another program. However, it
would be nice to have a standard helper function that also allows me
to specify a prefix and suffix. Shouldn't it be possible to just
modify tempfile.mktemp() to generate much longer random filenames so
that it is virtually impossible that another program has already
created a file with the same name? Then the security problem is
gone, there is no need to continue deprecating this function and all
programs using it should continue to work.
___
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] Guido's Python 1.0.0 Announcement from 27 Jan 1994

[Sebastian Krause]

Guido van Rossum  wrote:
> For me personally, the fondest memories are of 1.5.2, which Paul Everitt
> declared, while we were well into 2.x territory, was still the best Python
> ever. (I didn't agree, but 1.5.2 did serve us very well for a long time.)

That makes me feel better about the fact that 1.5.2 was my
employer's main Python version until late 2010. :)

(We're at 3.5 now.)
___
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] BDFL ruling request: should we block forever waiting for high-quality random bits?

[Sebastian Krause]

Steven D'Aprano  wrote:
>> it seems to me that you'd want such a solution to have code that
>> causes the initialization of the entropy pool to be sped up so that it
>> happens as quickly as possible (if that is even possible).  Is it
>> possible? (E.g. by causing the machine to start doing things other
>> than just CPython?)
>
> I don't think that's something which the Python interpreter ought to do 
> for you, but you can write to /dev/urandom or /dev/random (both keep 
> their own, separate, entropy pools):

There are projects like http://www.issihosts.com/haveged/ that use
some tiny timing fluctuations in CPUs to feed the entropy pool and
which are available in most Linux distributions. But as you said,
that is something completely outside of Python's scope.
___
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] BDFL ruling request: should we block forever waiting for high-quality random bits?

[Sebastian Krause]

Tim Peters  wrote:
> secrets.token_bytes() is already the way to spell "get a string of
> messed-up bytes", and that's the dead obvious (according to me) place
> to add the potentially blocking implementation.

I honestly didn't think that this was the dead obvious function to
use. To me the naming kind of suggested that it would do some
special magic that tokens needed, instead of just returning random
bytes (even though the best token is probably just perfectly random
data). If you want to provide a general function for secure random
bytes I would suggest at least a better naming.

Sebastian
___
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] BDFL ruling request: should we block forever waiting for high-quality random bits?

[Sebastian Krause]

David Mertz  wrote:
> It feels to me like the correct spelling in 3.6 should probably be
> secrets.getrandom() or something related to that.

Since there already is a secrets.randbits(k), I would keep the
naming similar and suggest something like:

secrets.randbytes(k, *, nonblock=False)

With the argument "nonblock" you can control what happens when not
enough entropy is available: It either blocks or (if nonblock=True)
raises an exception. The third option, getting unsecure random data,
is simply not available in this function.

Then you can keep os.urandom() as it was in Python 3.4 and earlier,
but update the documentation to better warn about its behavior and
point developers to the secrets module.

Sebastian
___
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] BDFL ruling request: should we block forever waiting for high-quality random bits?

[Sebastian Krause]

Guido van Rossum  wrote:
> I just don't like the potentially blocking behavior, and experts' opinions
> seem to widely vary on how insecure the fallback bits really are, how
> likely you are to find yourself in that situation, and how probable an
> exploit would be.

This is not just a theoretical problem being discussed by security
experts that *could* be exploited, there have already been multiple
real-life cases of devices (mostly embedded Linux machines)
generating predicatable SSH keys because they read from an
uninitialized /dev/urandom at first boot. Most recently in the
Raspbian distribution for the Raspberry Pi:
https://www.raspberrypi.org/forums/viewtopic.php?f=66=126892

At least in 3.6 there should be obvious way to get random data that
*always* guarantees to be secure and either fails or blocks if it
can't guarantee that.

Sebastian
___
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] BDFL ruling request: should we block forever waiting for high-quality random bits?

[Sebastian Krause]

Nathaniel Smith  wrote:
> (This is based on the assumption that the only time that explicitly
> calling os.urandom is the best option is when one cares about the
> cryptographic strength of the result -- I'm explicitly distinguishing
> here between the hash seeding issue that triggered the original bug
> report and explicit calls to os.urandom.)

I disagree with that assumption. I've often found myself to use
os.urandom for non-secure random data and seen it as the best option
simply because it directly returns the type I wanted: bytes.

The last time I looked the random module didn't have a function to
directly give me bytes, so I would have to wrap it in something like:

bytearray(random.getrandbits(8) for _ in range(size))

Or maybe the function exists, but then it doesn't seem very
discoverable. Ideally I would only want to use the random module for
non-secure and (in 3.6) the secrets module (which could block) for
secure random data and never bother with os.urandom (and knowing how
it behaves). But then those modules should probably get new
functions to directly return bytes.

Sebastian
___
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] C99

[Sebastian Krause]

Martin Panter  wrote:
>> So, what say you to updating PEP 7 to allow C99 features for Python 3.6
>> (in so much as GCC and MSVC support them)?
>
> Sounds good for features that are well-supported by compilers that
> people use. (Are there other compilers used than just GCC and MSVC?)

clang on OS X, but it supports pretty much everything that GCC
supports as well.
___
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] runtime dlls on Windows

[Sebastian Krause]

Chris Angelico  wrote:
>> BUT -- Steve Dower seems to have identified that the wonders of dll hell
>> never cease, and this isn't possible anyway. Oh well.
>
> I'm not entirely grasping what's happening here. There are multiple
> versions of msvcp140.dll floating around out there; what happens if
> one app requires one of them and another requires another? Can you
> simply say "take the newer one"? Is there a way to instantly recognize
> that there's a newer one available, and ignore the older one?
> Versioning is a *pain*.

Windows executables can and should ask for specific versions of the
DLLs in the manifest (an XML file embedded in the EXE). Details
here: https://en.wikipedia.org/wiki/Side-by-side_assembly

Sebastian
___
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