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]
Extracting Bazel installation...
Starting local Bazel server (8.3.0) and connecting to it...
INFO: Invocation ID: 794879c8-9898-4b5b-8115-dfbfdedf7e57
Computing main repo mapping: 
Computing main repo mapping: 
Computing main repo mapping: 
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:394:31: in <toplevel>
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:394: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:394:31: in <toplevel>
WARNING: For repository 'score_crates', the root module requires module version score_crates@0.0.7, but got score_crates@0.0.9 in the resolved dependency graph. Please update the version in your MODULE.bazel or set --check_direct_dependencies=off
Computing main repo mapping: 
Loading: 
Loading: 1 packages loaded
Loading: 1 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
Analyzing: 0 targets (2 packages loaded)
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: 10.394s
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-14T13:02:49Z

+        ":use_rust_pkcs11": [
+            "//score/cryptoki:cryptoki_cdylib",
+            "//score/cryptoki:cryptoki_headers",
+            "//third_party/openssl",


I believe this would any way be a transitive dependency when depending on cryptoki_cdylib right?

Thanks @ChansAlive, yes you are right, Done!

ChansAlive · 2026-07-14T13:05:05Z


-#include <cryptoki.h>
-#include <pkcs11.h>
+#ifdef USE_RUST_PKCS11
+    #include <pkcs11.h>
+#else
+    #include <cryptoki.h>
+#endif


I think it was unnecessary to include the cryptoki.h header in the first place.
You may ignore this comment, I will raise a separate fix later.

Changes planned in #92

ChansAlive · 2026-07-14T13:15:42Z

+#ifdef USE_RUST_PKCS11
+        {
+            CK_ULONG slot_count{0U};
+            CK_FUNCTION_LIST* const fl = m_module->GetFunctionList();
+            CK_RV rv = fl->C_GetSlotList(CK_TRUE, nullptr, &slot_count);
+            if ((rv == CKR_OK) && (slot_count > 0U))
+            {
+                std::vector<CK_SLOT_ID> slots(slot_count);
+                rv = fl->C_GetSlotList(CK_TRUE, slots.data(), &slot_count);
+                if ((rv == CKR_OK) && !slots.empty())
+                {
+                    m_config.slotId = slots.front();
+                    score::mw::log::LogWarn() << "[PKCS#11] Warning: token label autodetect failed for '"
+                                              << m_config.tokenLabel
+                                              << "'. Falling back to first present slot id=" << m_config.slotId;
+                    return true;
+                }
+            }
+        }
+#endif


What would be the rationale behind this callback?

The intention would be to use the correct token represented by the label (plus Model).

The overall idea of identifying the correct provider would be based on the provider name which is then mapped to the token label in the config to match with the pkcs11 token. If this is not honored, how can we ensure that we are communicating with the correct token when multiple tokens are present in the pkcs11 module?

yes @ChansAlive, I agree with you. I removed this.

ChansAlive · 2026-07-14T13:50:18Z

+#ifdef USE_RUST_PKCS11
+    {
+        // Hack to modify slot entries since GetSlotEntries returns const
+        auto& slot_entries = const_cast<std::vector<score::crypto::daemon::config::KeyConfig::KeySlotEntry>&>(
+            config.GetKeyConfig().GetSlotEntries()
+        );
+        for (auto& slot : slot_entries)
+        {
+            for (auto& provider_name : slot.provider_names)
+            {
+                if (provider_name == "SOFTHSM")
+                {
+                    provider_name = "SCORE_CRYPTO_PROVIDER";
+                }
+            }
+        }
+    }
+#endif


I think this is not the right way to use the keyslots for the rust pkcs11 provider. Infact there are three better alternatives

Use a common provider name for both softhsm and cryptoki. You can then change the pkcs11_token_config.cpp

Second option is to switch the integration_test_config.json (https://github.com/eclipse-score/inc_security_crypto/blob/main/tests/test_vectors/config/integration_test_config.json) in the BUILD file to use the modified keyslot entries.

Add new keyslot entries in the existing json. Adapt the test to use the new keyslot resource identifier when rust pkcs11 is selected.

Thanks @ChansAlive for your feedback, yes I agree with you. refactoring is ready now for generic provider name

ChansAlive · 2026-07-14T13:55:05Z

+    }
+    auto& km = km_result.value();
+
+    auto slot_result = ctx->ResolveResource("HMAC_SHA256_IntegrationTestKey_SoftHSM", ResourceType::kKeySlot);


Since we want to choose either softHSM or cryptoki, it may be better to rename the keyslot resourceId to have a generic name. Else it is bit confusing. The change requires updating the config json.

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?

Refactor the openssl_sys_build_rs.patch build script to dynamically parse the compiled OpenSSL version number from S-CORE's opensslv.h header inside the sandboxed build environment.

Update openssl_sys_build_rs.patch to emit the ossl350 configuration flags and version number 30500000. This provides the correct backward-compatible fallback configuration for S-CORE's compiled OpenSSL 3.6.1.

OliverHeilwagen · 2026-07-22T12:05:35Z

+    println!("cargo:rustc-cfg=openssl");
+
+    // 1. Declare S-CORE's compiled OpenSSL version and the highest supported crate version
+    const S_CORE_OPENSSL_VERSION: &str = "3.6.1";


@ShoroukRamzy Please create a follow up work item, to explore how we can keep this in sync with the actual used openssl version.

Later it should be possible that reference_integration is able to overwrite the openssl version, doing the manual sync will then only be valid in the security_crypto module scope.

OliverHeilwagen · 2026-07-22T13:24:04Z

+# *******************************************************************************
+git_override(
+    module_name = "rules_rust",
+    commit = "2b171a7376e69cb1207eced1f66904ce4ae0c819",


What is the difference to "0.68.2-score" ?
Is this a upcomming score version?

OliverHeilwagen · 2026-07-22T13:25:20Z

+# *******************************************************************************
+# Valeo - Cryptoki
+# *******************************************************************************
+git_override(


Please move the rust toolchain specific parts to section within this file.

# ******************************************************************************* # Rust toolchains # *******************************************************************************

OliverHeilwagen · 2026-07-22T13:28:45Z


+# s-core baselibs
+bazel_dep(name = "score_baselibs", version = "0.2.7")
+bazel_dep(name = "score_baselibs_rust", version = "0.1.2")


score_baselibs_rust is deprecated and got merged into score_baselibs with version 0.2.9 please create a follow up issue to bump the version and drop the score_baselibs_rust dependency.

OliverHeilwagen · 2026-07-22T13:30:53Z

 # SPDX-License-Identifier: Apache-2.0
 # *******************************************************************************

+load("@rules_shell//shell:sh_binary.bzl", "sh_binary")


please check if this is really needed.

Suggested change

load("@rules_shell//shell:sh_binary.bzl", "sh_binary")

OliverHeilwagen · 2026-07-22T13:34:12Z

    source_dir = ".",
 )

+package(default_visibility = ["//visibility:public"])


Please apply target specific and keep the default private, also for other BUILD files accordingly.

OliverHeilwagen · 2026-07-22T13:37:23Z

+# -------------------------------------------------------------------------------
+# Different toolchain configuration for x86_64-qnx
+# -------------------------------------------------------------------------------
+build:target_config_1 --config=x86_64-qnx
+build:target_config_1 --extra_toolchains=@score_qcc_x86_64_toolchain//:x86_64-qnx-sdp_8.0.0
+build:target_config_1 --extra_toolchains=@score_toolchains_rust//toolchains/ferrocene:ferrocene_x86_64_unknown_linux_gnu
+build:target_config_1 --extra_toolchains=@score_toolchains_rust//toolchains/ferrocene:ferrocene_x86_64_pc_nto_qnx800



With the updated bazelrc from main these changes should not longer be necessary.
The build should work with --config=x86_64-qnx.

Suggested change

# -------------------------------------------------------------------------------

# Different toolchain configuration for x86_64-qnx

# -------------------------------------------------------------------------------

build:target_config_1 --config=x86_64-qnx

build:target_config_1 --extra_toolchains=@score_qcc_x86_64_toolchain//:x86_64-qnx-sdp_8.0.0

build:target_config_1 --extra_toolchains=@score_toolchains_rust//toolchains/ferrocene:ferrocene_x86_64_unknown_linux_gnu

build:target_config_1 --extra_toolchains=@score_toolchains_rust//toolchains/ferrocene:ferrocene_x86_64_pc_nto_qnx800

OliverHeilwagen · 2026-07-22T13:38:00Z

 test:aarch64-qnx --test_lang_filters=cc,rust
 test:aarch64-qnx --test_timeout=180,900,2700,10800 # Increase default test timeout by factor 3
+
+# -------------------------------------------------------------------------------


Same point as above the aarch64-qnx config should already be valid.

OliverHeilwagen · 2026-07-22T13:40:25Z

+# ignore Bazel's own output symlinks
+bazel-inc_security_crypto
+bazel-bin
+bazel-out
+bazel-testlogs


Shouldn't this be default bazel behaviour?

OliverHeilwagen · 2026-07-30T08:00:55Z

+crate = use_extension("@rules_rust//crate_universe:extensions.bzl", "crate", isolate = True)
+crate.from_cargo(


Direct create_universe usage in modules seems invalid looking at:
https://github.com/eclipse-score/score-crates

Which raises the question how we handle the openssl dependency in future.
It seems to make more and more sense to move it into a separate repository.

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 suggested 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 requested a deployment to workflow-approval July 16, 2026 14:45 — with GitHub Actions Waiting

ShoroukRamzy requested a deployment to workflow-approval July 16, 2026 16:02 — with GitHub Actions Waiting

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

ShoroukRamzy requested a deployment to workflow-approval July 19, 2026 15:16 — with GitHub Actions Waiting

ShoroukRamzy requested a deployment to workflow-approval July 19, 2026 15:27 — with GitHub Actions Waiting

ShoroukRamzy force-pushed the cryptoki_etas_integration branch from ce954fc to ad1619a Compare July 19, 2026 15:54

ShoroukRamzy requested a deployment to workflow-approval July 19, 2026 15:54 — with GitHub Actions Waiting

ShoroukRamzy force-pushed the cryptoki_etas_integration branch from ad1619a to d029311 Compare July 19, 2026 16:05

ShoroukRamzy requested a deployment to workflow-approval July 19, 2026 16:05 — with GitHub Actions Waiting

ShoroukRamzy force-pushed the cryptoki_etas_integration branch from d029311 to 7918321 Compare July 19, 2026 16:10

ShoroukRamzy requested a deployment to workflow-approval July 19, 2026 16:10 — with GitHub Actions Waiting

ShoroukRamzy force-pushed the cryptoki_etas_integration branch from 7918321 to 23a7102 Compare July 19, 2026 16:21

ShoroukRamzy requested a deployment to workflow-approval July 19, 2026 16:21 — with GitHub Actions Waiting

CI: Trigger rebuild after network timeout

1711631

ShoroukRamzy force-pushed the cryptoki_etas_integration branch from 23a7102 to 1711631 Compare July 19, 2026 16:45

ShoroukRamzy requested a deployment to workflow-approval July 19, 2026 16:45 — with GitHub Actions Waiting

ShoroukRamzy requested a deployment to workflow-approval July 20, 2026 12:12 — with GitHub Actions Waiting

Build: Make OpenSSL version parsing fully dynamic in patch

8e1dc3d

Refactor the openssl_sys_build_rs.patch build script to dynamically parse the compiled OpenSSL version number from S-CORE's opensslv.h header inside the sandboxed build environment.

ShoroukRamzy force-pushed the cryptoki_etas_integration branch from 95cc948 to 8e1dc3d Compare July 20, 2026 12:21

ShoroukRamzy requested a deployment to workflow-approval July 20, 2026 12:21 — with GitHub Actions Waiting

ShoroukRamzy added 4 commits July 20, 2026 15:59

Build: Align OpenSSL patch with S-CORE version

478aea9

Update openssl_sys_build_rs.patch to emit the ossl350 configuration flags and version number 30500000. This provides the correct backward-compatible fallback configuration for S-CORE's compiled OpenSSL 3.6.1.

Build: Clean up unused legacy patch files in patches directory

a8c1413

Build: clean up legacy score_logging patch

2e8eab5

Build: maintain consistency between openssl and openssl-sys versions

88d3a65

OliverHeilwagen suggested changes Jul 22, 2026

View reviewed changes

OliverHeilwagen reviewed Jul 30, 2026

View reviewed changes

		crate = use_extension("@rules_rust//crate_universe:extensions.bzl", "crate", isolate = True)
		crate.from_cargo(

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!

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!

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!

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!

Choose a reason for hiding this comment

Uh oh!

Reviewers

github-actions Bot commented Jun 10, 2026 •

edited

Loading