Cryptoki etas integration by oeweda · Pull Request #49 · eclipse-score/inc_security_crypto

oeweda · 2026-06-10T13:08:33Z

Key Changes:

Integrated the cryptoki module natively into the score_crypto.
Moved the cryptoki provider to score/crypto/daemon/provider/pkcs11/cryptoki.
Updated all Bazel build configurations, Cargo dependencies, and lockfiles to correctly map to the new path.
Verified that the daemon, integration tests, and multi-provider demos build and pass successfully with the new provider location.
Use a single source for openssl (ETAS provided version) found under third_party/openssl
Integrate SCORE Logger into Cryptoki code
closes Integrate PKCS11 (Cryptoki) to SCORE #29 (children tasks PKCS11 (Cryptoki) Integration with SCORE #31 and Integration of PKCS11 (Cryptoki) With ETAS Architecture #32)
closes Have only one version of OpenSSL on target #30 (child task Selecting One OpenSSL Version for the Security Code #33)

Your Reviews will be appreciated @ChansAlive @PandaeDo @masc2023 @schreibwsag @OliverHeilwagen

github-actions · 2026-06-10T13:09:13Z

License Check Results

🚀 The license check job ran with the Bazel command:

bazel run --lockfile_mode=error //:license-check

Status: ⚠️ Needs Review

Click to expand output

[License Check Output]
2026/08/24 07:08:16 Downloading https://releases.bazel.build/8.6.0/release/bazel-8.6.0-linux-x86_64...
Extracting Bazel installation...
Starting local Bazel server (8.6.0) and connecting to it...
INFO: Invocation ID: 3a5b854d-131b-49dc-b2f6-f47a85d46fb6
Computing main repo mapping: 
Computing main repo mapping: 
DEBUG: Rule 'score_baselibs_rust+' indicated that a canonical reproducible form can be obtained by modifying arguments integrity = "sha256-4kzcXcvGi9xBEEnrPOiSEvteITZMPKmK3MNgJXQIGtY="
DEBUG: Repository score_baselibs_rust+ instantiated at:
  <builtin>: in <toplevel>
Repository rule http_archive defined at:
  /home/runner/.bazel/external/bazel_tools/tools/build_defs/repo/http.bzl:431:31: in <toplevel>
DEBUG: Rule 'score_logging+' indicated that a canonical reproducible form can be obtained by modifying arguments integrity = "sha256-/Q5+YfLkbMpz5PfvOkNS7qA3ehzth4emFhTcsk4q3zQ="
DEBUG: Repository score_logging+ instantiated at:
  <builtin>: in <toplevel>
Repository rule http_archive defined at:
  /home/runner/.bazel/external/bazel_tools/tools/build_defs/repo/http.bzl:431:31: in <toplevel>
DEBUG: Rule 'abseil-cpp+' indicated that a canonical reproducible form can be obtained by modifying arguments integrity = "sha256-m3oGQwXp/ZTRJP+mzDWFkutCtdpYj7TgfQklSqQAhts="
DEBUG: Repository abseil-cpp+ instantiated at:
  <builtin>: in <toplevel>
Repository rule http_archive defined at:
  /home/runner/.bazel/external/bazel_tools/tools/build_defs/repo/http.bzl:431:31: in <toplevel>
Computing main repo mapping: 
DEBUG: Rule 'grpc+' indicated that a canonical reproducible form can be obtained by modifying arguments integrity = "sha256-CvN7gAlTEwtHwHW1ZoPuYL3D7aPDf8YAQZP1tWl1ggQ="
DEBUG: Repository grpc+ instantiated at:
  <builtin>: in <toplevel>
Repository rule http_archive defined at:
  /home/runner/.bazel/external/bazel_tools/tools/build_defs/repo/http.bzl:431:31: in <toplevel>
Computing main repo mapping: 
DEBUG: Rule 'protobuf+' indicated that a canonical reproducible form can be obtained by modifying arguments integrity = "sha256-w6Cp7OiTLjHDtzbi2xixxC5wcM2biBOIsm0BqnHiTKI="
DEBUG: Repository protobuf+ instantiated at:
  <builtin>: in <toplevel>
Repository rule http_archive defined at:
  /home/runner/.bazel/external/bazel_tools/tools/build_defs/repo/http.bzl:431:31: in <toplevel>
Computing main repo mapping: 
Loading: 
Loading: 2 packages loaded
Loading: 2 packages loaded
    currently loading: 
WARNING: Target pattern parsing failed.
ERROR: Skipping '//:license-check': no such target '//:license-check': target 'license-check' not declared in package '' defined by /home/runner/work/inc_security_crypto/inc_security_crypto/BUILD
ERROR: no such target '//:license-check': target 'license-check' not declared in package '' defined by /home/runner/work/inc_security_crypto/inc_security_crypto/BUILD
INFO: Elapsed time: 11.976s
INFO: 0 processes.
ERROR: Build did NOT complete successfully
ERROR: Build failed. Not running target

PandaeDo · 2026-06-15T07:41:10Z

80k lines. Sorry, but I'm not able to review that. Is it possible to create smaller, readable PR's?

ChansAlive · 2026-06-15T07:45:51Z

Kindly check the PR again and resolve the merge conflicts.
It may then reflect the actual changes that is being brought in.
It currently shows the source code that is already present in the main as incoming changes.
Thanks

schreibwsag · 2026-06-18T05:28:09Z

test_pkcs11_provider fails when compiled with USE_RUST_PKCS11 ("C_InitToken failed: 160").
test_pkcs11_provider tries to initialize the token which is apparently necessary for the SoftHSM2
case, but not for libcryptoki. Proposal: to get test_pkcs11_provider running, do the initialization
parts only if USE_RUST_PKCS11 is not defined. Then test_pkcs11_provider will run:

./bazel-bin/tests/provider_test/test_pkcs11_provider
[==========] Running 4 tests from 1 test suite.
[----------] Global test environment set-up.
[----------] 4 tests from Pkcs11ProviderHashTest
[ RUN ] Pkcs11ProviderHashTest.SHA256SingleShotHash
mw::log initialization error: Error No logging configuration files could be found. occurred with context information: Failed to load configuration files. Fallback to console logging.
mw::log initialization error: Error No logging configuration files could be found. occurred with context information: Failed to load configuration files. Fallback to console logging.
2026/06/18 05:17:33.9853564 2801418324 000 ECU1 NONE DFLT log warn verbose 4 [PKCS#11] Warning: token label autodetect failed for ' SoftHSM '. Falling back to first present slot id= 0
[ OK ] Pkcs11ProviderHashTest.SHA256SingleShotHash (126 ms)
[ RUN ] Pkcs11ProviderHashTest.SHA256StreamingHash
2026/06/18 05:17:33.9853692 2801419597 000 ECU1 NONE DFLT log warn verbose 4 [PKCS#11] Warning: token label autodetect failed for ' SoftHSM '. Falling back to first present slot id= 0
[ OK ] Pkcs11ProviderHashTest.SHA256StreamingHash (122 ms)
[ RUN ] Pkcs11ProviderHashTest.StreamStateViolation
2026/06/18 05:17:33.9853802 2801420698 000 ECU1 NONE DFLT log warn verbose 4 [PKCS#11] Warning: token label autodetect failed for ' SoftHSM '. Falling back to first present slot id= 0
[ OK ] Pkcs11ProviderHashTest.StreamStateViolation (110 ms)
[ RUN ] Pkcs11ProviderHashTest.TrueConcurrentStreamingOnSeparateSessions
2026/06/18 05:17:33.9853925 2801421927 000 ECU1 NONE DFLT log warn verbose 4 [PKCS#11] Warning: token label autodetect failed for ' SoftHSM '. Falling back to first present slot id= 0
[ OK ] Pkcs11ProviderHashTest.TrueConcurrentStreamingOnSeparateSessions (123 ms)
[----------] 4 tests from Pkcs11ProviderHashTest (482 ms total)

[----------] Global test environment tear-down
[==========] 4 tests from 1 test suite ran. (482 ms total)
[ PASSED ] 4 tests.

github-actions · 2026-06-22T09:47:01Z

The created documentation from the pull request is available at: docu-html

ChansAlive

Review done on the daemon changes as part of integrating the rust pkcs11 provider

ChansAlive · 2026-07-15T07:58:32Z

Are these patch files really required to be merged?

Hi @ChansAlive, Yes, these patches are required to compile successfully:

openssl_sys patch: Bypasses host filesystem scanning (which is blocked by Bazel's secure sandbox) to link directly to our built-in //third_party/openssl library.

Other patches: Fix outdated Rust syntax and Cargo workspace README paths so S-CORE compiles cleanly on modern stable toolchains

Hi @ShoroukRamzy ,
Thanks for the response.

Currently, if I understand correctly, the patch hardcodes the version to 3.4 and we already are using 3.6.1, shouldn't we check which version of openssl we are using and adapt the patch to maintain consistency?

Regarding the score_logging.patch, if this is some change that should ideally be present in the respective module, we should not be patching it here right? Probably if we are using a third_party exclusively used sources, it may be fine. But from the middleware perspective, considering the modules could be shared by multiple modules, how do we expect this patching to work?

Ideally we should try to reduce patches as this might cause issues in the reference integration.
cc: @OliverHeilwagen

Hi @ChansAlive,

Thank you for your feedback. Regarding the first point, Let me clarify some points:

OpenSSL (C++) vs openssl-sys (Rust): S-CORE compiles OpenSSL 3.6.1 (the actual C++ binary), but our Rust bindings crate openssl-sys has no 3.6.x or ossl360 flags in its source code; its highest defined 3.x flag is ossl350.

Why we patch (Bazel Sandbox): The unpatched crate’s script scans host paths (like /usr/include), which is blocked inside Bazel's secure sandbox. Our patch simply bypasses this scan to prevent a compile-time crash.

Backward Compatibility: If the unpatched script could scan our 3.6.1 dynamically, it would automatically fall back to ossl350. OpenSSL strictly guarantees ABI backward compatibility, making this 3.5.0 compiled subset 100% compatible and safe to run against S-CORE's compiled 3.6.1 binary at runtime.

To maintain perfect consistency, we have updated the patch to output ossl350 and version number 30500000 (3.5.0 fallback).

@ShoroukRamzy,
I agree with the reason for patching the openssl-sys crate. Please check if all other patches are necessary.

The open point I have is on how to maintain consistency with openssl-sys crate patch and the openssl what we are building automatically. Else we might change (upgrade or downgrade) the openssl version without upgrading the patch.

It would be great if we have a possibility to patch with the maximum supported version of openssl (either of what is supported by crate or what we build) and throw necessary error in case of incompatibility.
Thanks.

@ChansAlive,
I removed all other patches, I tested without them and they are not needed

@ChansAlive, Regarding the openssl point, I fully agree with it and I updated the patch to maintain this consistency. Thanks!

@ChansAlive, Regarding the openssl point, I fully agree with it and I updated the patch to maintain this consistency. Thanks!

@ChansAlive, Done

@oeweda any update on the PR?

ChansAlive

Non rust code review

masc2023 · 2026-08-20T05:13:46Z

@ChansAlive , is this to be merged now?

ShoroukRamzy · 2026-08-20T08:27:07Z

Hi @ChansAlive and @OliverHeilwagen, I addressed all the review comments. next step, I will create the sub-issues that will need to be handled in other dedicated PRs. Thanks for all the review comments and your efforts!
cc: @sunildevda @masc2023

ChansAlive · 2026-08-20T10:22:22Z

@ChansAlive , is this to be merged now?

Yes. We can target to merge this next.
cc: @sunildevda @OliverHeilwagen

OliverHeilwagen

Approved with suggestions.

OliverHeilwagen · 2026-08-21T09:40:03Z

    with:
      # the bazel-target depends on your repo specific docs_targets configuration (e.g. "suffix")
-      bazel-target: "--lockfile_mode=error //:docs -- --github_user=${{ github.repository_owner }} --github_repo=${{ github.event.repository.name }}"
+      bazel-target: "--lockfile_mode=update //:docs -- --github_user=${{ github.repository_owner }} --github_repo=${{ github.event.repository.name }}"


Please revert to error.
Update should hide a wrong MODULE.bazel.lock which should not be done.

This also applies to license_check.yml

We can make the lockfile update part of the pre-commit so it is less annoying when doing dependency updates.

fixed please resolve comment.

OliverHeilwagen · 2026-08-21T09:41:16Z

 build:x86_64-linux --config=shared
 build:x86_64-linux --platforms=@score_bazel_platforms//:x86_64-linux-gcc_12.2.0-posix
 build:x86_64-linux --extra_toolchains=@score_gcc_x86_64_toolchain//:x86_64-linux-gcc_12.2.0
-build:x86_64-linux --extra_toolchains=@score_toolchains_rust//toolchains/ferrocene:ferrocene_x86_64_unknown_linux_gnu


Why is this not longer required?

@OliverHeilwagen, yes not needed because this Rust toolchain registration is automatically handled by the Bzlmod module system through our dependency on@score_toolchains_rust in MODULE.bazel, making manual registeration in bazel.rc redundant

OliverHeilwagen · 2026-08-21T09:44:31Z

+build --output_groups=+rules_lint_human
+build:lint --@aspect_rules_lint//lint:fail_on_violation=true
+build:lint --config=per-x86_64-linux
+test --test_output=errors


Nitpick, please separate it from the Clippy linting settings as it is a generic setting affecting all bazel test invocations.

fixed please resolve comment.

OliverHeilwagen

No blockers from testing and bazel point of view.
Remove of patches and crate_universe are planned as follow-up topics.

OliverHeilwagen · 2026-08-24T06:45:06Z

It should not be necessary to upload this file to the repository.

OliverHeilwagen · 2026-08-24T06:46:30Z

This file got removed in earlier PRs no need to bring it back

OliverHeilwagen

No blockers from testing and bazel point of view.
Remove of patches and crate_universe are planned as follow-up topics.

ShoroukRamzy · 2026-08-24T10:54:43Z

Hi @ChansAlive and @OliverHeilwagen, Thank you for all your feedbacks. I addressed all the review comments and I created the sub-issues that to be handled in dedicated follow-up PRs. Any other feedbacks?
cc: @sunildevda, @masc2023

ShoroukRamzy · 2026-08-24T14:22:52Z

No blockers from testing and bazel point of view. Remove of patches and crate_universe are planned as follow-up topics.

Hi @OliverHeilwagen , I created these issues #185 #184 #183 to be implemented in dedicated PRs in next step

masc2023 requested changes Jun 14, 2026

View reviewed changes

Comment thread docs/crypto/architecture/index.rst

Comment thread docs/crypto/architecture/index.rst Outdated

Comment thread docs/crypto/architecture/dynamic_architecture.rst Outdated

Comment thread docs/crypto/architecture/dynamic_architecture.rst Outdated

oeweda force-pushed the cryptoki_etas_integration branch 4 times, most recently from 4d92606 to cc51b96 Compare June 17, 2026 04:36

oeweda force-pushed the cryptoki_etas_integration branch 4 times, most recently from 4e95a25 to 0f08964 Compare June 22, 2026 09:41

ShoroukRamzy force-pushed the cryptoki_etas_integration branch 7 times, most recently from ab068a8 to 09800f7 Compare July 7, 2026 14:31

sunildevda requested a review from ChansAlive July 8, 2026 08:30

ChansAlive requested changes Jul 14, 2026

View reviewed changes

ChansAlive reviewed Jul 15, 2026

View reviewed changes

ShoroukRamzy force-pushed the cryptoki_etas_integration branch from 09800f7 to 2811e99 Compare July 16, 2026 09:12

ShoroukRamzy had a problem deploying to workflow-approval July 16, 2026 14:45 — with GitHub Actions Failure

ShoroukRamzy had a problem deploying to workflow-approval July 16, 2026 16:02 — with GitHub Actions Failure

ShoroukRamzy had a problem deploying to workflow-approval July 16, 2026 16:15 — with GitHub Actions Error

ShoroukRamzy added 2 commits August 19, 2026 10:51

Build: Transition rules_rust to central corporate release 0.68.2-score

ae191e3

Build: Fix PKCS#11 v3.0 C++ compilation in pkcs11_module.cpp

8a5702a

ChansAlive requested changes Aug 19, 2026

View reviewed changes

ShoroukRamzy added 3 commits August 20, 2026 10:08

Build: Remove redundant local_defines from init_pkcs11_token

7e63d2d

Build: Delete obsolete cryptoki_demo_client prototype

f49b1cd

Docs: Update README.md with Bzlmod label flags

a94bab2

This was referenced Aug 20, 2026

C++ Unit Test Environment Decoupling & Refactoring #177

Open

Integration Test Suite Cleanup & Abstraction #178

Open

ChansAlive reviewed Aug 20, 2026

View reviewed changes

Comment thread score/crypto/src/daemon/provider/pkcs11/src/pkcs11_module.cpp Outdated

Build: Unify PKCS#11 C_Initialize call with zero compile-time casts

051d204

ChansAlive reviewed Aug 20, 2026

View reviewed changes

Comment thread README.md Outdated

ShoroukRamzy added 2 commits August 20, 2026 16:08

Build: Delete redundant target_config configurations from bazelrc

845b817

Docs: Relocate Valeo Cryptoki integration guide to subfolder

d39c474

ChansAlive reviewed Aug 21, 2026

View reviewed changes

Comment thread score/crypto/src/backend/BUILD

OliverHeilwagen approved these changes Aug 21, 2026

View reviewed changes

Build: Revert lockfile mode to error across CI and bazelrc

05e805a

ShoroukRamzy mentioned this pull request Aug 23, 2026

Centralize PKCS#11 Backend Selection via String Flag Union and Transition to Rust Cryptoki Default #182

Open

OliverHeilwagen approved these changes Aug 24, 2026

View reviewed changes

Remove obsolete control client and binary config from repo

1931863

OliverHeilwagen approved these changes Aug 24, 2026

View reviewed changes

ChansAlive approved these changes Aug 24, 2026

View reviewed changes

This was referenced Aug 24, 2026

Migrate openssl-sys to score-crates and align version synchronization #183

Open

Drop deprecated score_baselibs_rust dependency and bump score_baselibs to v0.2.9 #184

Open

Resolve score_logging compile crashes upstream and remove local temporary patch #185

Open

ShoroukRamzy mentioned this pull request Aug 24, 2026

Update Rust Cryptoki README #186

Open

1 task

Uh oh!

Conversation

oeweda commented Jun 10, 2026

Uh oh!

github-actions Bot commented Jun 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

License Check Results

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

PandaeDo commented Jun 15, 2026

Uh oh!

ChansAlive commented Jun 15, 2026

Uh oh!

schreibwsag commented Jun 18, 2026

Uh oh!

github-actions Bot commented Jun 22, 2026

Uh oh!

ChansAlive left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ChansAlive left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

masc2023 commented Aug 20, 2026

Uh oh!

ShoroukRamzy commented Aug 20, 2026

Uh oh!

Uh oh!

ChansAlive commented Aug 20, 2026

Uh oh!

Uh oh!

Uh oh!

OliverHeilwagen left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

github-actions Bot commented Jun 10, 2026 •

edited

Loading

OliverHeilwagen left a comment •

edited

Loading

ShoroukRamzy commented Aug 24, 2026 •

edited

Loading