Yolanda added the comment:
@rbtcollins, even if we go with a FIPS aware module, we'd still need to detect
if md5 was used for security purposes.
If we build a system that detects FIPS enablement, call md5 say ... for
generating a password, and then the python fips_md5 call is masking it, we'd
Yolanda added the comment:
@rbtcollins, so you mean the apps using it, shall be "fips aware" ? That will
be the point of your separate module?
So...
if fips_enabled then
use fips.md5
else
use normal.md5
--
___
Python tr
Yolanda added the comment:
I agree with Doug. From my understanding, the intention of the patch is to
allow the usage of md5 for non-security purposes, without being blocked by FIPS.
Right now, md5() calls running on a FIPS enabled kernel, are blocked without
discrimination of the usage
Yolanda added the comment:
How about...
@@ -2339,9 +2339,12 @@ def mock_open(mock=None, read_data=''):
if handle.readline.return_value is not None:
while True:
yield handle.readline.return_value
-for line in _state[0]:
-yield line
Yolanda added the comment:
I tried patching the readline_side_effect call. But i cannot trap StopIteration
there, and i don't see any clear way to detect that the generator has reached
its end at that level.
--
___
Python tracker <
Yolanda added the comment:
So... the failures are because i'm capturing the StopIteration exception in
that case. then it's normal that it's not raised. How should you solve that
problem instead?
--
___
Python tracker <rep...@bugs.python.org>
Yolanda added the comment:
diff --git a/Lib/unittest/test/testmock/testwith.py
b/Lib/unittest/test/testmock/testwith.py
index a7bee73..efe6391 100644
--- a/Lib/unittest/test/testmock/testwith.py
+++ b/Lib/unittest/test/testmock/testwith.py
@@ -297,5 +297,16 @@ class TestMockOpen
Yolanda added the comment:
diff --git a/Lib/unittest/mock.py b/Lib/unittest/mock.py
index 7400fb7..9e47cd2 100644
--- a/Lib/unittest/mock.py
+++ b/Lib/unittest/mock.py
@@ -991,7 +991,10 @@ class CallableMixin(Base):
raise effect
if not _callable(effect