josepy/pyopenssl vulnerability

[lbeaufort]

Snyk links https://app.snyk.io/org/fecfile/project/e7c50dce-96a9-4313-818b-069a631aa5bc#issue-SNYK-PYTHON-PYOPENSSL-6157250 https://app.snyk.io/org/fecfile/project/e7c50dce-96a9-4313-818b-069a631aa5bc#issue-SNYK-PYTHON-PYOPENSSL-6149520 https://app.snyk.io/org/fecfile/project/e7c50dce-96a9-4313-818b-069a631aa5bc#issue-SNYK-PYTHON-PYOPENSSL-6592766

Introduced through [email protected] › [email protected]

We'll probably need to wait until a new version of josepy is released and certbot/josepy#181 is resolved. This may have breaking changes. certbot/josepy#182

QA Notes

null

DEV Notes

null

Design

null

See full ticket and images here: FECFILE-1634

[exalate-issue-sync]

David Heitzer commented: After doing some research, the solution may be to move to jwcrypto for all jwk/jws operations. This is what the [trussworks library|https://github.com/trussworks/logindotgov-oidc-py/blob/main/logindotgov/oidc.py] does and according to [pyopenssl|https://pypi.org/project/pyOpenSSL/], the cryptography library should be used instead where possible (this is what jwcrypto uses).

[exalate-issue-sync]

Shelly Wise commented: No QA review needed on this ticket.

Moved to Stage Ready.

[exalate-issue-sync]

akhorsand commented: Sprint conditionally accepted by Paul on 10/22/24 on the condition that we complete the hotfix FECFILE-1623. Tickets have been moved to DONE out of STAGE READY to facilitate QA processes, but full acceptance will come with the deployment of 1623.