I originally commented this in #105 and was asked to create a separate issue for it for visibility. As mentioned in #105, adding FIPS compatibility and offering an openssl-fips package may give users the idea that "if I install openssl-fips then my software/environment is FIPS certified". This is not true as real certification takes a lot of paperwork and time (I'm not an expert, just my understanding).
However, conda-forge users like me may have use cases where they want to run conda-forge-based environments/packages on FIPS-enabled/limited machines. If it is possible and not difficult or annoying to maintain, I'd love to see an openssl-fips available from conda-forge. However, I'm not sure what this means for downstream packages. For example, my main and most immediate concern is Python (CPython 3.10 specifically). Python has a C-level dependency on openssl and libcrypto from what I can tell so compiling it in such a way that any Python code run with it will run on a FIPS-enabled machine may not be a simple task.
Original comment:
I was going to file a new issue about this, but seeing as this PR is only semi-recently closed: I release some software that uses conda-pack to make a tarball of a conda-forge-based environment and recently some users have tried to run the software on FIPS-enabled/limited machines. It doesn't seem like it will be an urgent requirement for me to make it work and I can always rebuild things that are necessary, but I just wanted to put my name in the bowl of people who use conda-forge and have users on FIPS machines.
Put another way, I'm not looking for certification, I just need the system's kernel to not panic/abort if it sees my non-FIPS OpenSSL version. The next level above that would be not failing a utility scanning my bundled package for non-FIPS software.
Originally posted by @djhoese in #105 (comment)
I originally commented this in #105 and was asked to create a separate issue for it for visibility. As mentioned in #105, adding FIPS compatibility and offering an
openssl-fipspackage may give users the idea that "if I install openssl-fips then my software/environment is FIPS certified". This is not true as real certification takes a lot of paperwork and time (I'm not an expert, just my understanding).However, conda-forge users like me may have use cases where they want to run conda-forge-based environments/packages on FIPS-enabled/limited machines. If it is possible and not difficult or annoying to maintain, I'd love to see an openssl-fips available from conda-forge. However, I'm not sure what this means for downstream packages. For example, my main and most immediate concern is Python (CPython 3.10 specifically). Python has a C-level dependency on openssl and libcrypto from what I can tell so compiling it in such a way that any Python code run with it will run on a FIPS-enabled machine may not be a simple task.
Original comment:
I was going to file a new issue about this, but seeing as this PR is only semi-recently closed: I release some software that uses
conda-packto make a tarball of a conda-forge-based environment and recently some users have tried to run the software on FIPS-enabled/limited machines. It doesn't seem like it will be an urgent requirement for me to make it work and I can always rebuild things that are necessary, but I just wanted to put my name in the bowl of people who use conda-forge and have users on FIPS machines.Put another way, I'm not looking for certification, I just need the system's kernel to not panic/abort if it sees my non-FIPS OpenSSL version. The next level above that would be not failing a utility scanning my bundled package for non-FIPS software.
Originally posted by @djhoese in #105 (comment)