On 10/08/2017 14:17, Jan Tluka wrote:
> 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.