PyPi FIPS 422 Unprocessable Entity
Summary
Publishing to the PyPi package registry of a project fails with a 422 Unprocessable Entity when using the FIPS-enabled container images for the webservice.
Steps to reproduce
- Run the webservice using the FIPS-enabled container image variants.
- Try to upload a basic, dummy Python package using Twine or Poetry (v1.3.1). This will return a 422 Unprocessable Entity response.
Running the webservice using the regular non-FIPS container images allows the package to be uploaded to the registry and returns with a "201 Created".
What is the current bug behavior?
When uploading to a project's package registry using Twine or Poetry with a FIPS-enabled webservice container image we incorrectly receive a 422 Unprocessable Entity response from the webservice.
What is the expected correct behavior?
I would expect this to be able to correctly process the uploaded package/artifact, presuming it sends a hash using a FIPS-validated algorithm. The documentation for FIPS-enabled GitLab don't mention any issues with the PyPi registry, only that the Conan and Debian registries won't work so I would expect the PyPi registry to work.
Relevant logs and/or screenshots
There aren't really any relevant logs. The only logs I see from all GitLab components are the lines that indicate it's returning a 422 back to the client.
Results of GitLab environment info
GitLab 15.6.2, installed into a Kubernetes cluster via the Helm chart. All relevant container images using the FIPS-variant (i.e. the -fips
suffix).
Related Issues
This seems like it might be related: #380559 (closed)