[EXTERNAL] - 32-bit OpenSSL binary found in Suprema BioStar 2 door access system

[Michael Wojcik]

> From: Turritopsis Dohrnii Teo En Ming <teo.en.ming at protonmail.com>
> Sent: Monday, 15 April, 2024 07:36
> > > From: openssl-users openssl-users-bounces at openssl.org On Behalf Of
> > > Turritopsis Dohrnii Teo En Ming via openssl-users
> > > Sent: Saturday, 9 March, 2024 06:59
> > > To: openssl-users at openssl.org
> > >
> > > On 7 March 2024 Thursday, when I was installing new self-signed SSL
> > > certificate for the door access system for a law firm in Singapore, I notice that
> > > Suprema BioStar 2 also has 32-bit OpenSSL binary.
> > >
> > > The path is:
> > >
> > > C:\Program Files\BioStar 2(x64)\ta\OpenSSL-Win32\bin
> > >
> > > I am wondering if I can install 64-bit OpenSSL binary from another packager.
> > > Will there be any conflict?

> I am thinking of installing Third Party OpenSSL Related Binary Distributions like
> FireDaemon.

I can't comment on that; I don't know what it contains, or how its installation process works.

> I think there shouldn't be a conflict.

This is more a question about Windows and how it loads DLLs, than it is an OpenSSL question.

Assuming BioStar 2 loads the OpenSSL DLLs using the normal Windows mechanism, from EXEs in the same directory as those DLLs, then it should continue to load its own OpenSSL DLLs. Windows puts the EXE's directory at the start of the DLL search path when doing a normal implicit load, assuming no SxS nonsense interferes. Though that said, it's odd that BioStar 2 puts the OpenSSL DLLs in a "bin" directory (apparently) of their own. I can't say what BioStar 2 is up to here; I have no idea how the developers of that package expect things to work.

The other concern is whether any other programs which use OpenSSL will end up loading it from the BioStar 2 OpenSSL-Win32\bin directory rather than the FireDaemon installation directory, whatever that might be. Applications which simply have an implicit dependency on the OpenSSL DLLs, or which do a conventional LoadLibrary, will typically end up searching the directories in their PATH environment value. So you would want to ensure that the FireDaemon directory containing the OpenSSL DLLs is earlier in the PATH for at least those applications, and probably for everything — assuming BioStar 2 does something sensible like specify its library-loading source.

In short, it's impossible for anyone to say whether there will be a problem without recreating your environment. This is a universal difficulty with loading shared modules. The best approach for professional software is to avoid using modules which might conflict, by being explicit with their linking or using alternative file and symbol names or whatever. But many ISVs do not take that precaution.

-- 
Michael Wojcik