Allow the user to build oqs-provider as a static library. #201

thb-sb · 2023-06-29T15:45:28Z

This commit removes the SHARED argument of the add_library. By doing so, we let the user choose the build type of library.

By default, CMake will build a static library. Thus, BUILD_SHARED_LIBS must be used to switch to a shared library.

oqs-provider as a static library allows us to use the provider without having to store its shared library somewhere. In addition, it happens that some operating systems prohibit the use of dlopen/dlsym.

To load oqs-provider when it is embedded into a library of a binary, one can use the OSSL_PROVIDER_add_builtin API from OpenSSL 3.

.circleci/config.yml

baentsch

Thanks for the contribution! Yes, having it be one DLL/SO was the intention (by default) -- I'm not sure whether this works seamlessly on all platforms, though. Let's see what CI says... Please also check out the two nits in separate comments.

thb-sb · 2023-06-29T17:56:11Z

I've fixed the CI (I forgot the GitHub Actions part).

baentsch · 2023-06-30T05:20:52Z

The latest discussion above on the use of the static/shared/module moniker had me review also your rationale for the PR:

it happens that some operating systems prohibit the use of dlopen/dlsym

Which OS are you referring-to? Wouldn't such OS feature completely disable the purpose of openssl providers (as a dynamically loadable library)? I can understand this argument

one can use the OSSL_PROVIDER_add_builtin API from OpenSSL 3.

for wanting to build oqsprovider as a static lib: That way its should be possible to completely embed it into an application without (wanting) it being dynamically linked in: That definitely eases distribution of binaries with PQ capabilities inside.

But if this is the reason for this PR (?), the default behaviour of cmake (building static) clashes with the default purpose of a provider (being dynamically loadable).

What about this proposal then: We'd add a specific build option, say "OQS_PROVIDER_BUILD_STATIC" that --when set-- changes "MODULE" to "STATIC" in

oqs-provider/oqsprov/CMakeLists.txt

Line 34 in 6b34839

add_library(oqsprovider SHARED ${PROVIDER_SOURCE_FILES})

(and probably also resets/warns of set "BUILD_SHARED_LIBS" option)?

thb-sb · 2023-06-30T14:44:48Z

Which OS are you referring-to? Wouldn't such OS feature completely disable the purpose of openssl providers (as a dynamically loadable library)? I can understand this argument

I was referring to iOS on PAC-enabled devices (basically all the aarch64 mac and iPhones since the XS).

But if this is the reason for this PR (?), the default behaviour of cmake (building static) clashes with the default purpose of a provider (being dynamically loadable).

What about this proposal then: We'd add a specific build option, say "OQS_PROVIDER_BUILD_STATIC" that --when set-- changes "MODULE" to "STATIC" in

oqs-provider/oqsprov/CMakeLists.txt

Line 34 in 6b34839

add_library(oqsprovider SHARED ${PROVIDER_SOURCE_FILES})

(and probably also resets/warns of set "BUILD_SHARED_LIBS" option)?

I totally agree with you on that point. Changing the default behavior is indeed not a good idea.

So I implemented OQS_PROVIDER_BUILD_STATIC in e74d9da, and I removed the BUILD_SHARED_LIBS=ON flags I had previously set.

About the MODULE type, I can do it in another PR (I tried it here, and it failed to compile, so I guess it needs additional investigation).

.circleci/config.yml

baentsch · 2023-06-30T15:01:05Z

About the MODULE type, I can do it in another PR (I tried it here, and it failed to compile, so I guess it needs additional investigation).

ACK. Makes sense. Pushed your PR to the OQS CI test realm to see that everything's OK (apart from the CI nit above). Thanks again for the addition. Please consider adding yourself to the Contributors section at the end of the README.md.

thb-sb · 2023-06-30T16:12:19Z

About the MODULE type, I can do it in another PR (I tried it here, and it failed to compile, so I guess it needs additional investigation).

ACK. Makes sense. Pushed your PR to the OQS CI test realm to see that everything's OK (apart from the CI nit above). Thanks again for the addition. Please consider adding yourself to the Contributors section at the end of the README.md.

Ok!

I added two additional CI targets to test the OQS_PROVIDER_BUILD_STATIC=ON on Linux and macOS.

(and added myself in the README.md in 9eaa075).

thb-sb · 2023-06-30T16:48:20Z

Added a SKIP_TESTS parameter in the CircleCI configuration.
Since the two targets I added build oqs-provider statically, tests cannot be run.

Done in https://github.com/open-quantum-safe/oqs-provider/compare/9eaa075bdc2d033e9eb32d9fe6f40d1d5efa55e6..c26e1bf90c8a5a7f0d6f6666c2d41b915ebd249f.

baentsch

Added a SKIP_TESTS parameter in the CircleCI configuration.
Since the two targets I added build oqs-provider statically, tests cannot be run.

Agreed, tests as-is cannot be run with a statically built oqsprovider as they currently still rely on the dynamic-module-by-config load mechanism (OSSL_LIB_CTX_load_config) to activate oqsprovider. But I'd argue the above/the latest commits don't seem an ideal solution: That way the tests for the new configuration only check whether it can build but not whether oqsprovider can run in this config.

A more complete solution (not requiring any changes to any CI logic, i.e., performing functional testing) seems to be possible by using the new config variable as a #define in the test cases to call OSSL_PROVIDER_add_builtin and in the tests/CMakeLists.txt to suitably link the (then static) lib in to deliver the required init symbol. The code for the legacy provider seems to utilize the define "STATIC_LEGACY" for exactly this purpose and could serve as an example how to do this...

baentsch · 2023-07-04T05:33:42Z

@thb-sb When re-basing your PR, please be sure to update the new CONFIGURE.md with documentation for "OQS_PROVIDER_BUILD_STATIC".

thb-sb · 2023-07-04T08:08:02Z

@thb-sb When re-basing your PR, please be sure to update the new CONFIGURE.md with documentation for "OQS_PROVIDER_BUILD_STATIC".

Thanks for the reminder! Done :)

But I'd argue the above/the latest commits don't seem an ideal solution: That way the tests for the new configuration only check whether it can build but not whether oqsprovider can run in this config.

You're totally right, that SKIP_TESTS thing wasn't a good idea.

A more complete solution (not requiring any changes to any CI logic, i.e., performing functional testing) seems to be possible by using the new config variable as a #define in the test cases to call OSSL_PROVIDER_add_builtin and in the tests/CMakeLists.txt to suitably link the (then static) lib in to deliver the required init symbol. The code for the legacy provider seems to utilize the define "STATIC_LEGACY" for exactly this purpose and could serve as an example how to do this...

This is a far more better idea! So I did it: in test_common.h, I declared the following method:

void load_oqs_provider(OSSL_LIB_CTX *libctx, const char *modulename, const char *configfile);

Then, in test/CMakeLists.txt I implemented the following function:

function(targets_set_static_provider)                                            
  foreach(target ${ARGN})                                                        
    target_compile_definitions(${target} PRIVATE "OQS_PROVIDER_STATIC")          
    target_link_libraries(${target} PRIVATE oqsprovider)                         
  endforeach()                                                                   
endfunction()

This function is called if OQS_PROVIDER_BUILD_STATIC is set.

Finally, in test/test_common.c, the implementation of load_oqs_provider depends on the definition of OQS_PROVIDER_STATIC: if not set, then oqs-provider is loaded the same way as before, using the shared module. If set, OSSL_PROVIDER_add_builtin is instead used.

Note that OSSL_PROVIDER_add_builtin is called with the OSSL_provider_init symbol name, defined in oqsprov.
This only works if no other provider is statically linked, otherwise we may end up with a clash.
So, I was thinking that after this PR and the one about replacing SHARED with MODULE, I could submit a PR to let the user specify the init function name with a CMake option. What do you think? :)

baentsch · 2023-07-04T13:47:56Z

Thanks for these updates -- exactly as I'd hoped it should work.

I could submit a PR to let the user specify the init function name with a CMake option. What do you think? :)

With tongue-in-cheek, I'd say "Yes, let's hang them by the options" :), but more seriously, I'd rather suggest (best already in this PR) setting (and using) a fixed name "oqs_provider_init" if "OQS_PROVIDER_STATIC" is set exactly to avoid

if no other provider is statically linked, otherwise we may end up with a clash.

thb-sb · 2023-07-18T06:42:48Z

Okay, so I tried to leave runtests.sh untouched, but I ran into the following issue (CircleCI job):

Internal ctest changing into directory: /Users/distiller/project/_build
Test project /Users/distiller/project/_build
    Start 1: oqs_signatures
1/5 Test #1: oqs_signatures ...................Subprocess aborted***Exception:   0.04 sec
error registering dilithium2 with no hash
/Users/distiller/project/test/test_common.c:47: OpenSSL internal error: OSSL_PROVIDER_available(libctx, modulename)

From my understanding, I fell into the following case:

oqs-provider/scripts/runtests.sh

Lines 139 to 143 in 5250576

    
           # Disable testing for version 3.0.1: Buggy as hell: 
        
           if "${OPENSSL_APP}" version | grep -q "OpenSSL 3.0.1"; then 
        
              echo "Skipping testing of buggy OpenSSL 3.0.1" 
        
              exit 0 
        
           fi

Thus I'm wondering if having this check in both CircleCI's config.yml and runtests.sh is actually a good idea…

What do you think @baentsch ?

baentsch · 2023-07-18T09:46:55Z

From my understanding, I fell into the following case:

Well, Yes, I by now have no real trust in proper operation of OpenSSL 3.0.[0-8] (pertaining to providers :).

Thus I'm wondering if having this check in both CircleCI's config.yml and runtests.sh is actually a good idea…

I'm afraid that's then necessary, indeed.

But what irks me also is that the CI task (still) uses OpenSSL1.1.1 to build liboqs. Such error (not finding OpenSSL111 symbols "baked into" liboqs (and thus oqsprovider) may also be a reason behind the failure to load the provider. This was the reason for #212. Looking back at that PR, the fix only applies to the "courtesy build script" and not CI, though :-( So maybe same thing: CI needs to be upgraded, too (for liboqs to always use the same OpenSSL version as is used to run oqsprovider).

thb-sb · 2023-07-18T11:17:23Z

may also be a reason behind the failure to load the provider.

Okay, so I investigated this issue. To do so, I cloned liboqs, oqs-provider and various versions of OpenSSL. Here is what I found:

In this CircleCI job, we see that CMake uses the OpenSSL 1.1.1 include directory to build liboqs:

Found OpenSSL: /usr/local/opt/[email protected]/lib/libcrypto.dylib (found suitable version "1.1.1m", minimum required is "1.1.1")

while OpenSSL 3.0.1 is used for oqs-provider:

-- Found OpenSSL: /usr/local/opt/openssl@3/lib/libcrypto.dylib (found suitable version "3.0.1", minimum required is "3.0")

Thus, inside a sandbox, I compiled liboqs using OpenSSL 1.1.1m, and oqs-provider using OpenSSL 3.0.1. And I got the very same errors:

CTest output on oqs-provider

$ ctest --test-dir build --output-on-failure                                     
Internal ctest changing into directory: /Users/pawn/tests/openssl-3.0.8-oqs-provider/oqs-provider/build
Test project /Users/pawn/tests/openssl-3.0.8-oqs-provider/oqs-provider/build     
    Start 1: oqs_signatures                                                      
1/5 Test #1: oqs_signatures ...................Subprocess aborted***Exception:   0.01 sec
error registering dilithium2 with no hash                                        
/Users/pawn/tests/openssl-3.0.8-oqs-provider/oqs-provider/test/oqs_test_signatures.c:106: OpenSSL internal error: OSSL_PROVIDER_available(libctx, modulename)
                                                                                 
    Start 2: oqs_kems                                                            
2/5 Test #2: oqs_kems .........................Subprocess aborted***Exception:   0.00 sec
error registering dilithium2 with no hash                                        
/Users/pawn/tests/openssl-3.0.8-oqs-provider/oqs-provider/test/oqs_test_kems.c:85: OpenSSL internal error: OSSL_PROVIDER_available(libctx, modulename)
                                                                                 
    Start 3: oqs_groups                                                          
3/5 Test #3: oqs_groups .......................Subprocess aborted***Exception:   0.01 sec
error registering dilithium2 with no hash                                        
/Users/pawn/tests/openssl-3.0.8-oqs-provider/oqs-provider/test/oqs_test_groups.c:144: OpenSSL internal error: OSSL_PROVIDER_available(libctx, modulename)
                                                                                 
    Start 4: oqs_tlssig                                                          
4/5 Test #4: oqs_tlssig .......................Subprocess aborted***Exception:   0.00 sec
error registering dilithium2 with no hash                                        
/Users/pawn/tests/openssl-3.0.8-oqs-provider/oqs-provider/test/oqs_test_tlssig.c:158: OpenSSL internal error: OSSL_PROVIDER_available(libctx, modulename)
                                                                                 
    Start 5: oqs_endecode                                                        
5/5 Test #5: oqs_endecode .....................Subprocess aborted***Exception:   0.00 sec
error registering dilithium2 with no hash                                        
/Users/pawn/tests/openssl-3.0.8-oqs-provider/oqs-provider/test/oqs_test_endecode.c:217: OpenSSL internal error: OSSL_PROVIDER_available(libctx, modulename)
                                                                                 
                                                                                 
0% tests passed, 5 tests failed out of 5                                         
                                                                                 
Total Test time (real) =   0.03 sec                                              
                                                                                 
The following tests FAILED:                                                      
    1 - oqs_signatures (Subprocess aborted)                                      
    2 - oqs_kems (Subprocess aborted)                                            
    3 - oqs_groups (Subprocess aborted)                                          
    4 - oqs_tlssig (Subprocess aborted)                                          
    5 - oqs_endecode (Subprocess aborted)                                        
Errors while running CTest

Then, I tried to compile liboqs with OpenSSL 3.0.1 (instead of 1.1.1), and I also got those errors (error registering dilithium2 with no hash).

Finally, I tested with several versions of OpenSSL 3.0:

OpenSSL 3.0.1: error while registering the oqsprovider
OpenSSL 3.0.2: failed to compile [1]
OpenSSL 3.0.3 to 3.0.8: works

For each version V, I tried with liboqs+OpenSSL 1.1.1 and liboqs+OpenSSL V, and nothing changed.

Consequently, I think that using the OpenSSL 1.1.1 headers to compile liboqs isn't an issue (yet?), however OpenSSL 3.0.1 definitely appears to be broken.

I think we may fix that issue by upgrading the OpenSSL 3 version from homebrew:

env HOMEBREW_NO_AUTO_UPDATE=1 brew install cmake ninja [email protected]

I'll give it a shot.

[1]: OpenSSL 3.0.2 errors while compiling:

Output of make on OpenSSL 3.0.2

ld: Undefined symbols:
  _ossl_der_oid_id_aes128_wrap, referenced from:
      _kek_algs in libdefault.a[89](libdefault-lib-x942kdf.o)
  _ossl_der_oid_id_aes192_wrap, referenced from:
      _kek_algs in libdefault.a[89](libdefault-lib-x942kdf.o)
  _ossl_der_oid_id_aes256_wrap, referenced from:
      _kek_algs in libdefault.a[89](libdefault-lib-x942kdf.o)
  _ossl_der_oid_id_alg_CMS3DESwrap, referenced from:
      _kek_algs in libdefault.a[89](libdefault-lib-x942kdf.o)

thb-sb · 2023-07-18T16:05:46Z

Now that #217 is merged, I rebased this PR onto main, it should work.

CircleCI is having an outage on their GitHub service, so we'll have to wait and re-trigger the CircleCI pipelines…

baentsch

Tests with the external encodings library also cannot run as-is (in CI). See https://app.circleci.com/pipelines/github/open-quantum-safe/oqs-provider/710/workflows/e31c536a-beb9-4f93-ac9d-4cef35d2ec59/jobs/1589. Suggest to skip those in case of static build.

@bhess What's your take as to the need for testing of this library after IETF has rejected the encoding it implements? Should we keep it in CI? If not, the test failing in the trace above could simply be culled completely.

This commit removes the `SHARED` argument of the `add_library`. By doing so, we let the user choose the build type of library. By default, CMake will build a static library. Thus, [`BUILD_SHARED_LIBS`] must be used to switch to a shared library. `oqs-provider` as a static library allows us to use the provider without having to store its shared library somewhere. In addition, it happens that some operating systems prohibit the use of `dlopen`/`dlsym`. To load `oqs-provider` when it is embedded into a library of a binary, one can use the [`OSSL_PROVIDER_add_builtin`] API from OpenSSL 3. [`BUILD_SHARED_LIBS`]: https://cmake.org/cmake/help/latest/variable/BUILD_SHARED_LIBS.html [`OSSL_PROVIDER_add_builtin`]: https://www.openssl.org/docs/man3.1/man3/OSSL_PROVIDER_add_builtin.html

thb-sb · 2023-07-19T06:13:28Z

Suggest to skip those in case of static build.

It's done. Actually I did it for macOS but I forgot about linux...

baentsch · 2023-07-19T07:33:15Z

Thanks again for this contribution, @thb-sb!

…ies. open-quantum-safe#201 has been merged, but the `RELEASE.md` file has not been updated to reflect the new changes.

…ies. (#220) #201 has been merged, but the `RELEASE.md` file has not been updated to reflect the new changes.

PR [open-quantum-safe#207] introduced a check for setting the right suffix to the library, depending on the target OS: https://github.com/open-quantum-safe/oqs-provider/blob/823f3178dd50eeb5febf29eb82680400c4d9e887/oqsprov/CMakeLists.txt#L61-L7://github.com/open-quantum-safe/oqs-provider/blob/823f3178dd50eeb5febf29eb82680400c4d9e887/oqsprov/CMakeLists.txt#L61-L79 However, mixed with PR [open-quantum-safe#201] and the `OQS_PROVIDER_BUILD_STATIC` option, the library may be suffixed with the wrong extension: we may end up with a static library named `oqsprovider.dylib`, even if it's an archive: ```shell $ cmake -GNinja \ -DOQS_PROVIDER_BUILD_STATIC=ON \ -B build $ cmake --build build $ file build/lib/oqsprovider.dylib build/lib/oqsprovider.dylib: current ar archive random library $ # ^ should be named `oqsprovider.a`! ``` The check mentioned above is only relevant when oqsprovider is built as a module. This commit fixes this bug and introduces a check in the CircleCI jobs to verify that `oqsprovider.a` is actually produced. [open-quantum-safe#201](open-quantum-safe#201) [open-quantum-safe#207](open-quantum-safe#207)

PR [#207] introduced a check for setting the right suffix to the library, depending on the target OS: https://github.com/open-quantum-safe/oqs-provider/blob/823f3178dd50eeb5febf29eb82680400c4d9e887/oqsprov/CMakeLists.txt#L61-L7://github.com/open-quantum-safe/oqs-provider/blob/823f3178dd50eeb5febf29eb82680400c4d9e887/oqsprov/CMakeLists.txt#L61-L79 However, mixed with PR [#201] and the `OQS_PROVIDER_BUILD_STATIC` option, the library may be suffixed with the wrong extension: we may end up with a static library named `oqsprovider.dylib`, even if it's an archive: ```shell $ cmake -GNinja \ -DOQS_PROVIDER_BUILD_STATIC=ON \ -B build $ cmake --build build $ file build/lib/oqsprovider.dylib build/lib/oqsprovider.dylib: current ar archive random library $ # ^ should be named `oqsprovider.a`! ``` The check mentioned above is only relevant when oqsprovider is built as a module. This commit fixes this bug and introduces a check in the CircleCI jobs to verify that `oqsprovider.a` is actually produced. [#201](#201) [#207](#207)

This commit removes the trailing whitespaces from the `.fragment` files used for generating some pieces of code that end up in `oqsprov/oqsprov.c`. See open-quantum-safe#201 (review). Signed-off-by: Felipe Ventura <[email protected]>

…um-safe#201) This commit removes the `SHARED` argument of the `add_library`. By doing so, we let the user choose the build type of library. By default, CMake will build a static library. Thus, [`BUILD_SHARED_LIBS`] must be used to switch to a shared library. `oqs-provider` as a static library allows us to use the provider without having to store its shared library somewhere. In addition, it happens that some operating systems prohibit the use of `dlopen`/`dlsym`. To load `oqs-provider` when it is embedded into a library of a binary, one can use the [`OSSL_PROVIDER_add_builtin`] API from OpenSSL 3. The `cmake` define `OQS_PROVIDER_BUILD_STATIC` is introduced to drive building this variant. [`BUILD_SHARED_LIBS`]: https://cmake.org/cmake/help/latest/variable/BUILD_SHARED_LIBS.html [`OSSL_PROVIDER_add_builtin`]: https://www.openssl.org/docs/man3.1/man3/OSSL_PROVIDER_add_builtin.html Signed-off-by: Felipe Ventura <[email protected]>

…ies. (open-quantum-safe#220) open-quantum-safe#201 has been merged, but the `RELEASE.md` file has not been updated to reflect the new changes. Signed-off-by: Felipe Ventura <[email protected]>

PR [open-quantum-safe#207] introduced a check for setting the right suffix to the library, depending on the target OS: https://github.com/open-quantum-safe/oqs-provider/blob/823f3178dd50eeb5febf29eb82680400c4d9e887/oqsprov/CMakeLists.txt#L61-L7://github.com/open-quantum-safe/oqs-provider/blob/823f3178dd50eeb5febf29eb82680400c4d9e887/oqsprov/CMakeLists.txt#L61-L79 However, mixed with PR [open-quantum-safe#201] and the `OQS_PROVIDER_BUILD_STATIC` option, the library may be suffixed with the wrong extension: we may end up with a static library named `oqsprovider.dylib`, even if it's an archive: ```shell $ cmake -GNinja \ -DOQS_PROVIDER_BUILD_STATIC=ON \ -B build $ cmake --build build $ file build/lib/oqsprovider.dylib build/lib/oqsprovider.dylib: current ar archive random library $ # ^ should be named `oqsprovider.a`! ``` The check mentioned above is only relevant when oqsprovider is built as a module. This commit fixes this bug and introduces a check in the CircleCI jobs to verify that `oqsprovider.a` is actually produced. [open-quantum-safe#201](open-quantum-safe#201) [open-quantum-safe#207](open-quantum-safe#207) Signed-off-by: Felipe Ventura <[email protected]>

thb-sb force-pushed the static branch from e239fea to fad43d7 Compare June 29, 2023 15:56

thb-sb marked this pull request as ready for review June 29, 2023 16:04

thb-sb requested a review from baentsch as a code owner June 29, 2023 16:04

baentsch reviewed Jun 29, 2023

View reviewed changes

.circleci/config.yml Outdated Show resolved Hide resolved

baentsch reviewed Jun 29, 2023

View reviewed changes

.circleci/config.yml Outdated Show resolved Hide resolved

baentsch requested changes Jun 29, 2023

View reviewed changes

thb-sb force-pushed the static branch 3 times, most recently from d813109 to 60af75f Compare June 29, 2023 17:54

thb-sb requested a review from baentsch June 29, 2023 17:56

thb-sb force-pushed the static branch from 60af75f to e74d9da Compare June 30, 2023 14:41

baentsch reviewed Jun 30, 2023

View reviewed changes

.circleci/config.yml Show resolved Hide resolved

thb-sb force-pushed the static branch 2 times, most recently from 7dda5ee to 9eaa075 Compare June 30, 2023 16:11

baentsch approved these changes Jun 30, 2023

View reviewed changes

thb-sb force-pushed the static branch from 9eaa075 to c26e1bf Compare June 30, 2023 16:47

baentsch mentioned this pull request Jul 1, 2023

Change build (back) to "MODULE" #202

Closed

baentsch reviewed Jul 1, 2023

View reviewed changes

baentsch mentioned this pull request Jul 2, 2023

Static library support #82

Closed

thb-sb force-pushed the static branch from c26e1bf to 953aea0 Compare July 4, 2023 07:55

thb-sb force-pushed the static branch from 953aea0 to 000c56b Compare July 4, 2023 08:10

thb-sb force-pushed the static branch from 1566bdc to 04fdb5d Compare July 18, 2023 15:49

thb-sb force-pushed the static branch 2 times, most recently from 4bdccb5 to 26cc7e7 Compare July 18, 2023 16:55

baentsch requested changes Jul 19, 2023

View reviewed changes

thb-sb force-pushed the static branch from 26cc7e7 to aadb0bc Compare July 19, 2023 06:12

baentsch approved these changes Jul 19, 2023

View reviewed changes

baentsch merged commit 694b17e into open-quantum-safe:main Jul 19, 2023
19 checks passed

thb-sb deleted the static branch July 19, 2023 07:32

thb-sb added a commit to thb-sb/oqs-provider that referenced this pull request Jul 19, 2023

Add a line to RELEASE.md to highlight the support for static librar…

279a4a3

…ies. open-quantum-safe#201 has been merged, but the `RELEASE.md` file has not been updated to reflect the new changes.

thb-sb mentioned this pull request Jul 19, 2023

Add a line to RELEASE.md to highlight the support for static libraries #220

Merged

thb-sb added a commit to thb-sb/oqs-provider that referenced this pull request Jul 19, 2023

Add a line to RELEASE.md to highlight the support for static librar…

932b867

…ies. open-quantum-safe#201 has been merged, but the `RELEASE.md` file has not been updated to reflect the new changes.

baentsch pushed a commit that referenced this pull request Jul 19, 2023

Add a line to RELEASE.md to highlight the support for static librar…

823f317

…ies. (#220) #201 has been merged, but the `RELEASE.md` file has not been updated to reflect the new changes.

thb-sb mentioned this pull request Jul 19, 2023

Fix a bug in the CMake script. #221

Merged

baentsch mentioned this pull request Jul 20, 2023

QSC encoder library build loses cross-compilation settings #154

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Allow the user to build oqs-provider as a static library. #201

Allow the user to build oqs-provider as a static library. #201

thb-sb commented Jun 29, 2023

baentsch left a comment

thb-sb commented Jun 29, 2023

baentsch commented Jun 30, 2023

thb-sb commented Jun 30, 2023

baentsch commented Jun 30, 2023

thb-sb commented Jun 30, 2023

thb-sb commented Jun 30, 2023

baentsch left a comment

baentsch commented Jul 4, 2023

thb-sb commented Jul 4, 2023 •

edited

Loading

baentsch commented Jul 4, 2023

thb-sb commented Jul 18, 2023

baentsch commented Jul 18, 2023

thb-sb commented Jul 18, 2023

thb-sb commented Jul 18, 2023

baentsch left a comment

thb-sb commented Jul 19, 2023

baentsch commented Jul 19, 2023

Allow the user to build oqs-provider as a static library. #201

Allow the user to build oqs-provider as a static library. #201

Conversation

thb-sb commented Jun 29, 2023

baentsch left a comment

Choose a reason for hiding this comment

thb-sb commented Jun 29, 2023

baentsch commented Jun 30, 2023

thb-sb commented Jun 30, 2023

baentsch commented Jun 30, 2023

thb-sb commented Jun 30, 2023

thb-sb commented Jun 30, 2023

baentsch left a comment

Choose a reason for hiding this comment

baentsch commented Jul 4, 2023

thb-sb commented Jul 4, 2023 • edited Loading

baentsch commented Jul 4, 2023

thb-sb commented Jul 18, 2023

baentsch commented Jul 18, 2023

thb-sb commented Jul 18, 2023

thb-sb commented Jul 18, 2023

baentsch left a comment

Choose a reason for hiding this comment

thb-sb commented Jul 19, 2023

baentsch commented Jul 19, 2023

thb-sb commented Jul 4, 2023 •

edited

Loading