External Email - Use Caution        

Dear FreeSurfer developers,

I have also encountered the error that Katja Zoner reported in

https://secure-web.cisco.com/1HqVP4_2gCSsHuuEFWzIN0yTWdDhhIeKNpc8cqD9BfBOmmKgsS9FIE4BKco1FPCE5Anq994ZwqQIsH-u2071nrJlW0a_AaHRcLWJn3XuQgUjRiMEp2BpE0gI8eF8s8ikJXS3BqmyQAUgeKlcpib4mDD1S8E5UXh2JD2sXO-AbxxBDu9bQNKF7rf0lHDkDNfYjGSc8DunjxMCM05q_bkGDOiO-2GdCV_NpBoID8eaQZnvykADMJvFpXiqJDCGjMz27Qf6gJexxyJqD-dYrRp6waA/https%3A%2F%2Fwww.mail-archive.com%2Ffreesurfer%40nmr.mgh.harvard.edu%2Fmsg69509.html

We work on different servers within the same institution and have been in 
contact with our administrators, we are sure at this point that the error is 
caused by FIPS 140 compliance on some of our systems. It is unrelated to 
Singularity. The crypt() function, as called in freesurfer/utils/chklc.cpp, 
returns NULL with errno == EPERM on machines booted in FIPS mode. I believe 
these users have encountered the same problem

https://secure-web.cisco.com/1-z_qWpPYjwD6UccsUQP4XQEVo4YMH5WkF2I0eRZ2Z2G-7Y-JnshMWuVhJZRyY0wfjmrZSyrmDTgQdj8O3GxncnrQ9AmpeIZGVXTqsBAcmX4Akup4RNxjeeoGse6bLy7yCNdP6FVB4ITMiUxFHnihZ2QuHIacEPmNLw7ffxyzQj5q7xb5umpROXZPIM3JXy_CRpxqY4C0jW5lndQ7MTP8JG5k8TxqDQDDzAWwmM80_qobm3N-fykZlBXA8zPcd64E2ednYIz2DS7cZpFNtQrhkA/https%3A%2F%2Fwww.mail-archive.com%2Ffreesurfer%40nmr.mgh.harvard.edu%2Fmsg54981.html

https://secure-web.cisco.com/1D8Zt97JISxcqWsV-6sX9O6GUs5X59E2NOYaxNQqkDBr8tOgbGrQnC9a2mf-tNs_Fych5ae4pGNCU1oJZP4QbtDo2Kqh3uYCrInZ5_i0oPnfgk1byC79h8O7xrTu44C0O_zATfdd5JdOnS3S8k3i7P8_4rcS2PeZLL6IfNh61kZIFJHY4y5RvwC4cpRazga8DWUU-EaznxbicQkee-raOBRj3DULH-QkNgzsXVTBcUtT0FkgE1YLXmOjoSuFN5AOD4Vun7Krv0Reds-4RXTuzqA/https%3A%2F%2Fwww.mail-archive.com%2Ffreesurfer%40nmr.mgh.harvard.edu%2Fmsg57637.html

As one of the above users noted, certain institutions (such as the Veterans 
Administration) require FIPS mode, as do studies using sensitive data. Our 
administrators have agreed to provide some "insecure" machines to run 
FreeSurfer binaries and containers for the time being, but we're concerned 
about the sustainability of this longer term.

I think the issue could be resolved by using a FIPS-compliant algorithm in the 
call to crypt(). For example, I've tested crypt() with the SHA-512 algorithm in 
FIPS mode, and this works

  crypt_gkey = crypt(gkey, "$6$FS");

but this would require the license file to contain an SHA-512 encrypted gkey in 
addition to the DES one that currently exists.

Alternatively, we can check if errno == EPERM after the call to crypt(), and 
bypass the encryption check in that case.

I understand that these solutions are non-trivial and could raise backwards 
compatibility or license compliance issues. Unfortunately, I've not been able 
to find any other workaround.

Thanks

_______________________________________________
Freesurfer mailing list
[email protected]
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

Reply via email to