.deb inside of oqsprovider-linux-x64.zip 0.5.3 does not work & prevents OpenSSL from loading

[catharsis71]

Describe the bug

Installing this .deb deleted my existing /usr/lib/x86_64-linux-gnu/ossl-modules/oqsprovider.so (from an older .deb) from all my servers and did not replace it, instead it dumped a bunch of files into a /__w/ directory which appears to be in error:

# find /__w/
/__w/
/__w/oqs-provider
/__w/oqs-provider/oqs-provider
/__w/oqs-provider/oqs-provider/.local
/__w/oqs-provider/oqs-provider/.local/lib
/__w/oqs-provider/oqs-provider/.local/lib/ossl-modules
/__w/oqs-provider/oqs-provider/.local/lib/ossl-modules/oqsprovider.so

This caused all my OpenSSL-linked services (Apache etc) to be unable to start and caused me to be unable to run curl and other programs

also causes OpenSSL commands to fail:

# openssl list -signature-algorithms -provider oqsprovider
list: unable to load provider oqsprovider
Hint: use -provider-path option or OPENSSL_MODULES environment variable.
40D717FE7F7F0000:error:12800067:DSO support routines:dlfcn_load:could not load the shared library:../crypto/dso/dso_dlfcn.c:118:filename(/usr/lib/x86_64-linux-gnu/ossl-modules/oqsprovider.so): /usr/lib/x86_64-linux-gnu/ossl-modules/oqsprovider.so: cannot open shared object file: No such file or directory
40D717FE7F7F0000:error:12800067:DSO support routines:DSO_load:could not load the shared library:../crypto/dso/dso_lib.c:152:
40D717FE7F7F0000:error:078C0105:common libcrypto routines:provider_init:init fail:../crypto/provider_core.c:910:name=oqsprovider

[catharsis71]

Downloaded 0.5.3.zip source... rebuilt .deb with make package and it works fine

seems like it's just the uploaded .debs which are corrupt

[baentsch]

Thanks for the report and your tests: This is definitely a bug. The binaries have been taken from the CI run(s) on the released branch, so we'll need to investigate what went wrong in that process...

[catharsis71]

Thank you, also, just out of curiosity, are you planning on providing .debs for liboqs as well? Having pre-built debs for provider is of limited benefit when you still have to compile liboqs manually

[baentsch]

Thank you, also, just out of curiosity, are you planning on providing .debs for liboqs as well? Having pre-built debs for provider is of limited benefit when you still have to compile liboqs manually

The liboqs project doesn't (or at least didn't) want to make binaries available (maybe worthwhile reconsidering, @dstebila ?). Thus, the oqsprovider .deb indeed was meant for folks that have liboqs deployed by other means (e.g., downstream packaging).

But your question correctly points to other setups. Would you think a .deb oqsprovider statically containing liboqs would be a good addition, @catharsis71 ?

[catharsis71]

A statically-linked .deb would be great. I run this on my home PC and 6 servers. I normally only have compiler/library/build-tool stuff installed on my home PC. I've been compiling / building .debs there and then copying to 5 of the 6 servers. But one server is ARM64 and I couldn't figure out if cross-compiling was possible so I had to install all the build stuff & libraries on that server too.

[dstebila]

Thank you, also, just out of curiosity, are you planning on providing .debs for liboqs as well? Having pre-built debs for provider is of limited benefit when you still have to compile liboqs manually

The liboqs project doesn't (or at least didn't) want to make binaries available (maybe worthwhile reconsidering, @dstebila ?). Thus, the oqsprovider .deb indeed was meant for folks that have liboqs deployed by other means (e.g., downstream packaging).

For the short-term, would it be more straightforward to have two binaries for oqs-provider: one without liboqs (like now), one with liboqs? If the two binaries are bundled together with oqs-provider, less risk of mismatches.

[baentsch]

The idea would not be to bundle two binaries but to statically link liboqs into oqsprovider, thus resulting in another single, large shared lib that OpenSSL Van load. Need to try this.

[dstebila]

The idea would not be to bundle two binaries but to statically link liboqs into oqsprovider, thus resulting in another single, large shared lib that OpenSSL Van load. Need to try this.

That makes sense too.