You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
I'm not opposed to having a separate output openssl-fips, but I'm not super comfortable with the idea for all the reasons laid out above [in the discussion of that PR]
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)
The text was updated successfully, but these errors were encountered: