STINNER Victor added the comment:
I close the issue. Python 3.7 and newer are fixed. Python 2.7 is still
affected, but I consider that it's ok to leave the bug unfixed in this version.
--
> The random number generator now reseeds after a fork.
I confirm that it's done since Python 3.7, and
Raymond Hettinger added the comment:
The random number generator now reseeds after a fork.
Can this now be closed as "out-of-date" or is there still something that needs
to be done?
--
status: pending -> open
___
Python tracker
Christian Heimes added the comment:
Past me was a bit too eager...
Only UUID4 are suppose to be random and unpredictable. uuid.UUID4 uses
os.urandom() to as RNG. UUID1, UUID3 and UUID5 are more concerned with reducing
collisions.
--
status: open -> pending
type: security -> behavior
STINNER Victor added the comment:
> Given the introduction of the secrets module in 3.6, perhaps uuid could be
> updated to fall back to that rather than to the random module and leave older
> versions unmodified?
issue15206.patch catchs exceptions on random.SystemRandom error, but the
Nick Coghlan added the comment:
Given the introduction of the secrets module in 3.6, perhaps uuid could be
updated to fall back to that rather than to the random module and leave older
versions unmodified?
--
nosy: +ncoghlan
versions: +Python 3.6 -Python 3.2, Python 3.3
Christian Heimes li...@cheimes.de added the comment:
The rest of the module uses bar excepts. I could change the signature if you
insist.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15206
Antoine Pitrou pit...@free.fr added the comment:
The rest of the module uses bar excepts.
It was probably written in prehistoric times :)
The other excepts can be converted later, if the module gets other changes. I
don't think it is a deliberate style choice (it would be particularly
Christian Heimes li...@cheimes.de added the comment:
Am 28.06.2012 07:54, schrieb Martin v. Löwis:
Martin v. Löwis mar...@v.loewis.de added the comment:
a) my patch handles the fork() issue correctly
If the system has urandom, yes.
That's the easy and trivial case. It also handles
Antoine Pitrou pit...@free.fr added the comment:
+except Exception:
I don't think that's a good idea. You should list the specific exceptions here
(NotImplementedError, OSError perhaps?).
--
___
Python tracker rep...@bugs.python.org
New submission from Christian Heimes li...@cheimes.de:
The uuid module uses Mersenne Twister from the random module as last fallback.
However a MT isn't suitable for cryptographic purposes. The module should first
try to use os.urandom() and then perhaps use its own instance of random.Random,
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com:
--
nosy: +Arfrever
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15206
___
Christian Heimes li...@cheimes.de added the comment:
Further analysis:
* uuid1() uses random.randrange() if the system doesn't provide
uuid_generate_time
* uuid1() also falls back to random.randrange() in getnode()'s
_random_getnode() if no hardware address can be acquired.
* uuid4() is
Martin v. Löwis mar...@v.loewis.de added the comment:
Can you elaborate why it is unsuitable? None of the uuid functions claim any
cryptographic properties, so even if MT was unsuitable for cryptographic
purposes, this wouldn't rule it out for generating uuids.
--
nosy: +loewis
Christian Heimes li...@cheimes.de added the comment:
IMHO it's all about managing expectations. As libuuid is using a crypto RNG
before it falls back to a less suitable RNG. We should follow this example. I
couldn't find any information about the implementation details of Window's
Raymond Hettinger raymond.hettin...@gmail.com added the comment:
Are uuid's promised to be cryptographically secure?
--
assignee: - rhettinger
nosy: +rhettinger
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15206
Christian Heimes li...@cheimes.de added the comment:
Not, not by definition. However an uuid generator shall geenerate uuid in a way
that make collisions highly improbable. IMHO this verdict implies that an uuid
generator should use the cryptographic RNG if available.
The behavior after
STINNER Victor victor.stin...@gmail.com added the comment:
However a MT isn't suitable for cryptographic purposes.
The module should first try to use os.urandom() and
then perhaps use its own instance of random.Random,
similar to uuid_generate_* [1]
os.urandom() is not suitable for
Antoine Pitrou pit...@free.fr added the comment:
From the /dev/urandom Linux man page:
If you are unsure about whether you should use /dev/random or
/dev/urandom, then probably you want to use the latter. As a general
rule, /dev/urandom should be used for
Christian Heimes li...@cheimes.de added the comment:
Antoine beat me to it and he is totally right.
Please don't derail this bug report. I agree with your analysis that the RNG
core of random.Random subclass can't be replaced easily and that more
implementations for different purposes would
Martin v. Löwis mar...@v.loewis.de added the comment:
a) my patch handles the fork() issue correctly
If the system has urandom, yes.
b) if it's a good idea to try SystemRandom first
Certainly.
c) a backport to 2.6, 2.7, 3.1 and 3.2 is required
and perhaps
Cannot backport to 2.6 and 3.1;
Changes by Martin v. Löwis mar...@v.loewis.de:
--
versions: -Python 2.6, Python 3.1
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15206
___
___
21 matches
Mail list logo
