ENH: Add support for python in FIPS mode for document identifier

[xnox]

In FIPS mode, md5 might be available and approved. It might also be
available, but only on opt-in basis for unapproved usage. And very
strict systems might not have md5 even on opt-in basis.

Python has API to expose this as "usedforsecurity=False" argument, see
python documentation.

The rolling document checksum is not used for cryptograpic protection,
but rather used out of convenience. Hence allow using MD5 on more FIPS
systems.

This is no effective change for regular non-fips python builds.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 96.97%. Comparing base (38e4a8c) to head (cf65616).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #3438   +/-   ##
=======================================
  Coverage   96.97%   96.97%           
=======================================
  Files          54       54           
  Lines        9337     9337           
  Branches     1711     1711           
=======================================
  Hits         9055     9055           
  Misses        168      168           
  Partials      114      114           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[stefan6419846]

Thanks for the report and the fix. Is there any risk of accidentally breaking FIPS compatibility with further changes where a corresponding test run would help - or is this specific change sufficient for most of the PDF-related use cases?

[xnox]

Thanks for the report and the fix. Is there any risk of accidentally breaking FIPS compatibility with further changes where a corresponding test run would help - or is this specific change sufficient for most of the PDF-related use cases?

this absolutely is enough as is for most usage, without need for any further testing.

If you must you can pull down freely available azure linux fips containers; or like launch amazon linux 2023 EC2 instance, put it into fips mode...... to then check that this just works. But I find this in general un-necessary.

Upstream cpython, has extensive test suite to ensure this hashlib api works correctly with openssl in fips mode already, which they validate on every PR and release as is.

The encrypted pdf works with the aes-256 / latest key derivation based on sha256, and as expected loudly fails when using RC4 based stuff - but all that clearly is done for cryptographic protection and all FIPS users expect such behaviour of allowed aes to work, and rc4 stuff to fail.