<html>

  <head>

    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

  </head>

  <body>

    <p><br>

    </p>

    <div class="moz-cite-prefix">On 8/15/23 9:54 PM, Cantor, Scott via

      dev wrote:<br>

    </div>

    <blockquote type="cite"

      cite="mid:ED3F04D6-8959-45C1-AEFB-E31DD7EEF91C@osu.edu">

      <pre class="moz-quote-pre" wrap="">

Whether that leads to a simple fix is a different issue, but that's up to Brent. I will say it seems pretty disadvantageous to me for the package names to be different between them. Unless those classes are programmatically loaded, not sure how that's going to fly. I assume they aren't now, or this wouldn't be a compile time dependency problem.</pre>

    </blockquote>

    <p><br>

    </p>

    <p>They aren't currently loaded reflectively, if that's what you

      mean.</p>

    <p>I currently personally know nothing of FIPS compliance, so the

      concrete requirements here are just a mystery to me at this point.

      But in general:<br>

    </p>

    <p>If it ever gets to the point of us trying to support FIPS

      properly, we'd really need to nail down what the actual ask is

      here, what is "good enough for FIPS users", etc.  Right now the

      kludges people are doing are just avoiding runtime errors for

      things they apparently aren't currently using anyway.</p>

    <p>But to do it properly, we might actually have to make all of that

      stuff work with the BC FIPS dependency.  As in, they might

      actually want to use ConcatKDF with ECDH.  Or even EC keys period,

      which is what most of the ECNamedCurve* and EC5Util dependence is

      about (consuming and emitting KeyInfo structures).</p>

    <p>So, we might have to have separate modules in java-opensaml and

      elsewhere, for FIPS vs non-FIPS.  We might have to have then

      different distributions of the IdP. Etc.  Could get complicated.<br>

    </p>

    <p>And then there's the fact (that we apparently just had to deal

      with, again) that the BC folks make completely breaking changes in

      any release, i.e. no concept of minor or patch releases ala

      semantic versioning, etc.  So there's no guarantee at all over

      time that the class named X in the non-FIPS artifact really has

      the same API as class X in the FIPS artifact. Or which classes

      exist in one and not the other. Etc.</p>

  </body>

</html>