The simple solution is to keep doing what we do now: only support OpenSSL and not whatever Apple does with LibreSSL which may or may not be up to date.
Gary On Wed, Jun 29, 2022, 06:59 sebb <seb...@gmail.com> wrote: > It looks like macOS 10.5+ and Windows (latest) use LibreSSL by default > rather than OpenSSL. > > The LibreSSL API does not have the same functions as either 1.0.2 or > 1.1.1, so needs its own JNA class. In particular it looks like > ENGINE_load_rdrand is not present, nor is OpenSSL_version_num; 1.0.2 > has the former only, and 1.1.1 has the latter only. > > This makes it hard to support JNA with the current design. > It would require another OpenSsl<version>NativeJna class, and the > parent class OpenSslNativeJna would need to use yet another condition > in each of its methods. > > This is quite tedious and error-prone. > > Seems to me it would be better to use something like a set of > singleton classes that implement the required methods. The appropriate > one can then be initialised and used by OpenSslNativeJna to field the > actual methods. i.e. replace the conditional logic with a static > reference to the correct API interface instance. This should only > affect non-public classes. > > Any other suggestions? > > Sebb > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
