Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] implementation of hashlib in _utils.py fails in FIPS environment #2697

Closed
caplinje-NOAA opened this issue Nov 20, 2023 · 5 comments · Fixed by #2817
Closed

[BUG] implementation of hashlib in _utils.py fails in FIPS environment #2697

caplinje-NOAA opened this issue Nov 20, 2023 · 5 comments · Fixed by #2817
Assignees

Comments

@caplinje-NOAA
Copy link
Contributor

caplinje-NOAA commented Nov 20, 2023

Describe your context
CentOS FIPS environment
Python 3.11.5

dash
dash-bootstrap-components
dash-leaflet
numpy
pandas
plotly
pyproj
scipy
xarray
tables

Describe the bug
When deployed using rstudio-connect, the app fails to initialize with the following error:
...dash/_utils.py", line 144, in _concat hashed_inputs = hashlib.md5( ValueError: [digital envelope routines: EVP_DigestInit_ex] disabled for FIPS

The error can be replicated simply with python3 in a similar environment, as was done in this redhat bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=1744670

There is a fair amount of discussion about this issue in other projects (where reporters on average do a better job of describing the issue):

dask/dask#8608
Linuxfabrik/lib#30
PrefectHQ/prefect#7615

Where the suggested fix is to use a different hasher (e.g. blake3) or using the hashilb.md5 optional flag used_for_security=False (python>=3.9) if you're not hashing sensitive data. I for some reason did not see this error while in python 3.8. I believe this is a necessary fix to make dash compatible with FIPS environments.

@alexcjohnson
Copy link
Collaborator

Thanks @caplinje-NOAA - FIPS is new to me, but I don't see any reason we can't switch to sha256 or some such. That's probably easier than trying to use used_for_security=False since we still support back to Py3.6, though I don't believe there are any security implications of our use of hashes here, we just need repeatability and uniqueness.

Feel like making a PR? For completeness here are all the places I see us using hashlib. The dash.py usage is fine, and if we're OK with sha1 so is the long_callbacks/managers/__init__.py usage but I see no harm converting that to sha256 as well.

> ag --py hashlib
development/_jl_components_generation.py
9:import hashlib
419:        hex=u.hex[:-12] + hashlib.md5(package_name.encode("utf-8")).hexdigest()[-12:]

_callback.py
2:import hashlib
530:        function_name = hashlib.md5(clientside_function.encode("utf-8")).hexdigest()

long_callback/managers/__init__.py
3:import hashlib
76:        return hashlib.sha1(str(hash_dict).encode("utf-8")).hexdigest()
105:        return hashlib.sha1(

dash.py
15:import hashlib
1466:        method = getattr(hashlib, hash_algorithm)

_utils.py
5:import hashlib
145:                hashed_inputs = hashlib.md5(
218:        return hashlib.md5(fp.read().encode("utf-8")).hexdigest()

@caplinje-NOAA
Copy link
Contributor Author

I would be happy to, I'll submit as soon as I work out a testing scheme that makes sense. Thanks.

@shieronymus-slingshot
Copy link

Any update here? I'm very interested in a fix as I've been bitten by this too.

@caplinje-NOAA
Copy link
Contributor Author

caplinje-NOAA commented Mar 21, 2024

@alexcjohnson, @shieronymus-slingshot FIPS envrionments which properly implement python guardrails were difficult for me to implement in a testing environment and I did not want to submit a pull request without testing that my edits would have resolved this issue. I still believe switching to a different hashing algorithm will solve this problem (and searching git for hashlib/FIPS will tell the whole story). For now I am simply using python 3.8 which somehow avoids this issue, though that is clearly not a long term solution.

@caplinje-NOAA
Copy link
Contributor Author

caplinje-NOAA commented Mar 23, 2024

@shieronymus-slingshot I successfully reproduced my error with a simple example dashboard, and was able to resolve the error with a messy monkey patch / method overload. This is not ideal but is a reasonable test that switching to different/better hashing algorithm solves this issue. In my case, the offending method was create_callback_id and was invoked by callback in the case allow_duplicate=True. If this is your situation, you could apply a similar patch as a short term solution. My example code is here:

https://github.com/caplinje-NOAA/dash_md5_patch_testing

Again this is a messy and not intended as a real solution, but shows this can be resolved with a small pull request. It would be great to know that this is the same situation you are in, so if you wanted to do a similar test in your environment, that maybe is helpful here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants