Thu, Aug 10, 2017 at 08:47:43AM CEST, olichtne(a)redhat.com wrote:
> On Wed, Aug 09, 2017 at 06:13:51PM +0300, Roi Dayan wrote:
>> Hi,
>>
>> This actually broke lnst on my machine.
>> I don't have the usedforsecurity option in python2.7 or python3
>> but do in python2.6.
>> I encountered this because I run lnst with python2.7.
>>
>> root@mtr-stm-023 ~ # python2.6 -c "import hashlib ;
>> hashlib.md5(usedforsecurity=False)"
>>
>> root@mtr-stm-023 ~ # python2.7 -c "import hashlib ;
>> hashlib.md5(usedforsecurity=False)"
>> Traceback (most recent call last):
>> File "<string>", line 1, in <module>
>> TypeError: openssl_md5() takes no keyword arguments
>>
>> root@mtr-stm-023 ~ # 1 python3 -c "import hashlib ;
>> hashlib.md5(usedforsecurity=False)"
>> Traceback (most recent call last):
>> File "<string>", line 1, in <module>
>> TypeError: openssl_md5() takes no keyword arguments
>> root@mtr-stm-023 ~ # 1
>>
>>
>> any idea? is it the python build?
>> maybe there should be a check if the flag exists and only
>> then use it?
>>
>> Thanks,
>> Roi
>
> Hi,
>
> interesting, it seems that the "usedforsecurity" patch is something
> applied downstream by the Fedora packagers and it wasn't accepted into
> upstream python yet [1]. The issue is already 7 years old so let's not
> get our hopes up for a quick resolution...
>
> So for LNST I see two possibilities:
> * move to a newer hash that fips doesn't disable - I already do this on
> the 'next' branch and we only use md5 for file/directory hashing
> making the required changes pretty contained.
> * Impact on running LNST instances will be that all test resources will
> be resynchronized again but that's not a big problem.
> * This technically isn't a futureproof solution... fips will inevitably
> change and sha256 will be deprecated when we'll encounter the same
> issues... But it might be enough to postpone the issue until python
> upstream solves this properly.
> * implement the other proposed solution (which I think I only discussed
> with jtluka in person) and just catch the proper exceptions - either
> the "fips forbidden" exception or the "takes no keyword
arguments"
> exception
> * in the end i don't think it solves the issue at all - we still need
> a hash for the file, how do we calculate it if we can't use the
> hashlib function? (running without "usedforsecurity=false" might
> still encounter the "fips forbidden" exception on fips enabled
> systems)
>
> So only one of these really "solves" the issue, by postponing it... does
> anyone see a better option than just moving to sha256?
>
> -Ondrej
>
> [1]
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.p...
IMO, the first action is that we should revert the patch if the solution is
not in standard Python. That would make LNST working for everyone until
we fix this properly.
Thoughts?
-Jan
I'm in favor to remove as it's not standard.
when there will be a standard fix then it wouldn't be a problem to
update a problematic setup.