poetry publish fails on FIPS enabled systems because of hashlib.md5()

[CrazyBonze]

• I am on the latest Poetry version.
• I have searched the issues of this repo and believe that this is not a duplicate.
• If an exception occurs when executing a command, I executed it again in debug mode (-vvv option).

• OS version and name: Red Hat Enterprise Linux Server release 7.9 (Maipo)
• Poetry version: 1.1.12
• Link of a Gist with the contents of your pyproject.toml file:

Issue

If FIPS mode is enabled for a system there is a potential for a ValueError in upload.py when trying to publish a package to a repository when there is an md5 checksum. See the documentation for hashlib for more information. The important part being:

md5() is normally available as well, though it may be missing or blocked if you are using a rare “FIPS compliant” build of Python.

The error returned when running the command poetry publish -r <my-repo>

No suitable keyring backends were found
Using a plaintext file to store and retrieve credentials
Publishing <my-package> (0.1.5) to <my-repo>

  ValueError

  error:060800A3:digital envelope routines:EVP_DigestInit_ex:disabled for fips

  at ~/.poetry/lib/poetry/publishing/uploader.py:131 in post_data
      127│
      128│         if _has_blake2:
      129│             blake2_256_hash = hashlib.blake2b(digest_size=256 // 8)
      130│
    → 131│         md5_hash = hashlib.md5()
      132│         sha256_hash = hashlib.sha256()
      133│         with file.open("rb") as fp:
      134│             for content in iter(lambda: fp.read(io.DEFAULT_BUFFER_SIZE), b""):
      135│                 md5_hash.update(content)

[CrazyBonze]

This looks like a pretty easy fix, i am asking my manager if it would be fine if i implement a fix for it. Unless someone has a better idea i was thinking of just adding a try catch for a ValueError for the md5 part of the code. I dont see any other good way for checking if FIPS is enabled other then just trying.

[CrazyBonze]

Looking into this a little more, hashlib.md5() can take an argument usedforsecurity, a simple change md5_hash = hashlib.md5(usedforsecurity=False) should fix this issue.

[johnthagen]

Note that usedforsecurity was added in Python 3.9.

[cquick01]

Bumping this issue.

I've needed to implement a custom patch to utilize poetry in an environment with FIPS enabled. That can be found here, if it helps: https://gist.github.com/cquick01/17da8f2c7eeccb9a944443e13bc132ef

Note that there is also a file that I needed to patch after installing my patched-poetry package, poetry/core/_vendor/lark/load_grammar.py, which didn't seem to be included with the source files in this repo. Might be a dependency file, I'm not sure. But running sed -i "s/hashlib.md5(text.encode('utf8'))/hashlib.md5(text.encode('utf8'), usedforsecurity=False)/g" /path/to/poetry/core/_vendor/lark/load_grammar.py was needed along with my patch above.

This does, of course, only work for Python 3.9+ though. We'd probably want to wrap these changes into some logic based on the running Python version.

Edit: As it turns out sha256 doesn't need to be patched to work in a FIPS environment. But md5 does, which isn't a big deal since it isn't considered a secure hashing algorithm anyways. That change needs to be done in lark though, not in poetry.

[clintonroy]

Err, aren't we using the hashes for security though?

[burrego]

This also prevents "poetry install" from executing on a FIPS Mode enabled system

[cquick01]

FWIW this has been fixed upstream in lark, but they haven't released a new tag with the changes. lark-parser/lark#1190

I think poetry-core will need to be updated - https://github.com/python-poetry/poetry-core/tree/main/src/poetry/core/_vendor/lark

[davidrfreeman]

A coworker just let me know that a new tag for lark, 1.1.3, was cut to address this issue. Can poetry-core be updated to pull in this new release?

[neersighted]

python-poetry/poetry-core#503 is merged, the next release will include this change.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.