Skip to content
New issue

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

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

Already on GitHub? # 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.

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

Successfully merging a pull request may close this issue.

4 participants