<head><title></title></head>
<body><div class="iw_mail" dir="ltr">
<br><div class="signature"></div>-----Original Message-----<br>From: "Dániel Szoboszlay" <<a href="mailto:dszoboszlay@gmail.com">dszoboszlay@gmail.com</a>><br>Date: 05/01/15 04:01<br><br>Hi,<br><br>Thanks for your comments, much appreciated !<br><br>> - Blocked non-compliant calls in FIPS mode before they would reach<br>> OpenSSL (so you get an Erlang error instead of killing your<br>> VM). This is a must have for any FIPS fork, but it was quite<br>> trivial to implement.<br><br>That would be the CHECK_NO_FIPS_MODE in crypto.c. Is there any at the<br>Erlang level ?<br><br>I'm asking beacause what I am considering at the moment is to only<br>modify the crypto.c code. No modification to Erlang code. For two<br>reasons. One is that I do not know Erlang, although by browsing the<br>code lately I find it quite interesting :) But nowhere near being able<br>to modify an application that is used in the field. Let alone<br>establishing test harnesses in the first place. Second is, the OTP<br>that is used is already modified by tail-f AG as part of the ConfD<br>product. For instance, if I'm not mistaken, the SSL component is<br>different, with crypto being the only part used from OpenSSL. I have<br>the impression that the OTP base used in the product dates from some<br>time. It is possible to compile locally crypto.c, but when it comes<br>to altering the company's Erlang code then all support is lost.<br><br>This approach also means to keep the C <-> Erlang interface intact.<br><br>Do you think it is at all possible to have a working FIPS mode without<br>any modification to Erlang code ?<br><br>Regards.<br><br>
</div></body>