[RFE] Expose WOLF_CRYPTO_CB_RSA_PAD as a configure knob

[space88man]

Version

master

Description

RFE: expose the C defines WOLF_CRYPTO_CB_RSA_PAD as a autotools/configure or cmake knob.

HSMs today may disable RSA raw operations and users are recommended to use RSA with padding mechanisms instead of managing padding in software. wc_pkcs11.c has support for OAEP/PKCS15/PSS mechanisms based on WOLF_CRYPTO_CB_RSA_PAD. This flag seems to be defined only with WOLFSSL_RENESAS_TSIP.

#if defined(WOLFSSL_RENESAS_TSIP)
    #define TSIP_TLS_HMAC_KEY_INDEX_WORDSIZE 64
    #define TSIP_TLS_MASTERSECRET_SIZE       80   /* 20 words */
    #define TSIP_TLS_ENCPUBKEY_SZ_BY_CERTVRFY 560 /* in byte  */

    #ifdef WOLF_CRYPTO_CB
        /* make sure RSA padding callbacks are enabled */
        #define WOLF_CRYPTO_CB_RSA_PAD
    #endif
#endif /* WOLFSSL_RENESAS_TSIP */

While this flag can be turned on with EXTRA_CFLAGS it seems more ergonomic to allow it to be turned on at configure time. Currently Debian does not have this flag turned on (given that it is quite obscure). This means that wc_pkcs11.c may not be using optimal mechanisms.

[cpsource]

Took a crack at this. Extended the existing --enable-cryptocbutils list with rsapad rather than adding a new top-level flag, so there's one place for crypto-callback sub-features. Added a matching WOLFSSL_CRYPTOCB_RSA_PAD option on the CMake side.

Usage:

# autotools — just the padding callbacks
./configure --enable-cryptocb --enable-cryptocbutils=rsapad

# combined with other utilities
./configure --enable-cryptocb --enable-cryptocbutils=copy,free,rsapad

# all utilities (now includes rsapad)
./configure --enable-cryptocb --enable-cryptocbutils

# pkcs11 forces cryptocb on, so this works too
./configure --enable-pkcs11 --enable-cryptocbutils=rsapad

# cmake
cmake -DWOLFSSL_CRYPTOCB=yes -DWOLFSSL_CRYPTOCB_RSA_PAD=yes ..

Verified locally:

• --enable-cryptocbutils=rsapad emits only -DWOLF_CRYPTO_CB_RSA_PAD
• --enable-cryptocbutils (bare or =yes) emits all five (COPY, FREE, SETKEY, EXPORT_KEY, RSA_PAD)
• --enable-cryptocbutils=foo → Unknown cryptocbutils option: foo. Valid options: copy, free, setkey, export, rsapad
• --enable-cryptocbutils=rsapad without --enable-cryptocb → --enable-cryptocbutils requires --enable-cryptocb

I also traced the C code end-to-end (rsa.c → cryptocb.c → wc_pkcs11.c) and confirmed the flag actually delivers what the RFE asks for: with it off, PKCS#11 only ever sees CKM_RSA_X_509; with it on, the unpadded message + padding metadata crosses the cryptocb boundary and PKCS#11 uses CKM_RSA_PKCS / CKM_RSA_PKCS_OAEP / CKM_RSA_PKCS_PSS with the right CK_RSA_PKCS_*_PARAMS. Full trace in the writeup below.

Patch

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 663c3cf2c..bf93605be 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -2208,6 +2208,10 @@ add_option("WOLFSSL_CRYPTOCB_NO_SW_TEST"
     "Disable crypto callback SW testing (default: disabled)"
     "no" "yes;no")
 
+add_option("WOLFSSL_CRYPTOCB_RSA_PAD"
+    "Enable RSA padding crypto callbacks, e.g. for PKCS#11 HSMs that disable raw RSA (default: disabled). Requires WOLFSSL_CRYPTOCB."
+    "no" "yes;no")
+
 add_option("WOLFSSL_PKCALLBACKS"
     "Enable public key callbacks (default: disabled)"
     "no" "yes;no")
@@ -2440,6 +2444,13 @@ if(WOLFSSL_CRYPTOCB_NO_SW_TEST)
     list(APPEND WOLFSSL_DEFINITIONS "-DWC_TEST_NO_CRYPTOCB_SW_TEST")
 endif()
 
+if(WOLFSSL_CRYPTOCB_RSA_PAD)
+    if(NOT WOLFSSL_CRYPTOCB)
+        message(FATAL_ERROR "WOLFSSL_CRYPTOCB_RSA_PAD requires WOLFSSL_CRYPTOCB")
+    endif()
+    list(APPEND WOLFSSL_DEFINITIONS "-DWOLF_CRYPTO_CB_RSA_PAD")
+endif()
+
 # Public Key Callbacks
 if(WOLFSSL_PKCALLBACKS)
     list(APPEND WOLFSSL_DEFINITIONS "-DHAVE_PK_CALLBACKS")
diff --git a/configure.ac b/configure.ac
index 69f8501f0..e9a55202f 100644
--- a/configure.ac
+++ b/configure.ac
@@ -10015,7 +10016,7 @@ fi
 
 # Crypto Callbacks Utils (Copy/Free/etc)
 AC_ARG_ENABLE([cryptocbutils],
-    [AS_HELP_STRING([--enable-cryptocbutils@<:@=copy,free,setkey,export,...@:>@],
+    [AS_HELP_STRING([--enable-cryptocbutils@<:@=copy,free,setkey,export,rsapad,...@:>@],
                     [Enable crypto callback utilities (default: all)])],
     [ ENABLED_CRYPTOCB_UTILS=$enableval ],
     [ ENABLED_CRYPTOCB_UTILS=no ]
@@ -10028,7 +10029,7 @@ if test "$ENABLED_CRYPTOCB_UTILS" != "no"; then
 
     if test "$ENABLED_CRYPTOCB_UTILS" = "yes"; then
         # Enable all utilities
-        AM_CFLAGS="$AM_CFLAGS -DWOLF_CRYPTO_CB_COPY -DWOLF_CRYPTO_CB_FREE -DWOLF_CRYPTO_CB_SETKEY -DWOLF_CRYPTO_CB_EXPORT_KEY"
+        AM_CFLAGS="$AM_CFLAGS -DWOLF_CRYPTO_CB_COPY -DWOLF_CRYPTO_CB_FREE -DWOLF_CRYPTO_CB_SETKEY -DWOLF_CRYPTO_CB_EXPORT_KEY -DWOLF_CRYPTO_CB_RSA_PAD"
     else
         # Parse comma-separated list
         OIFS="$IFS"
@@ -10047,8 +10048,11 @@ if test "$ENABLED_CRYPTOCB_UTILS" != "no"; then
                 export)
                     AM_CFLAGS="$AM_CFLAGS -DWOLF_CRYPTO_CB_EXPORT_KEY"
                     ;;
+                rsapad)
+                    AM_CFLAGS="$AM_CFLAGS -DWOLF_CRYPTO_CB_RSA_PAD"
+                    ;;
                 *)
-                    AC_MSG_ERROR([Unknown cryptocbutils option: $util. Valid options: copy, free, setkey, export])
+                    AC_MSG_ERROR([Unknown cryptocbutils option: $util. Valid options: copy, free, setkey, export, rsapad])
                     ;;
             esac
         done

Full writeup

README-issue-10271.md

# Issue #10271 — Expose `WOLF_CRYPTO_CB_RSA_PAD` as a configure knob

## The RFE

Upstream request: <https://github.com/wolfSSL/wolfssl/issues/10271>

`WOLF_CRYPTO_CB_RSA_PAD` gates the RSA padding path in crypto callbacks. When
defined, `wc_pkcs11.c` uses PKCS#11 mechanisms for OAEP / PKCS#1 v1.5 / PSS
directly on the HSM instead of doing raw RSA and padding in software. Many
HSMs disable raw RSA operations, so this flag is effectively required for them
to work well.

Before this change, the macro was only defined implicitly under
`WOLFSSL_RENESAS_TSIP` in `wolfssl/wolfcrypt/settings.h`. Everyone else had to
pass `EXTRA_CFLAGS=-DWOLF_CRYPTO_CB_RSA_PAD`, which is awkward for
distributions (Debian, etc.) and non-obvious for end users.

## Analysis

The codebase already has a good pattern for sub-flags of `--enable-cryptocb`:
`--enable-cryptocbutils=copy,free,setkey,export` — a single option with a
comma-separated list, gated on `--enable-cryptocb` being enabled. Adding a
separate top-level `--enable-crypto-cb-rsa-pad` option would create a second
convention; extending the existing list keeps things consistent.

On the CMake side there is no equivalent composite option — each feature gets
its own `add_option(...)` entry. So the CMake change follows that pattern with
`WOLFSSL_CRYPTOCB_RSA_PAD`.

## Changes

### `configure.ac`

Extended the existing `--enable-cryptocbutils` handling to accept `rsapad`:

- Help string now lists `rsapad`
- `--enable-cryptocbutils=yes` (and bare `--enable-cryptocbutils`) now also
  emits `-DWOLF_CRYPTO_CB_RSA_PAD` alongside the existing four utility defines
- `--enable-cryptocbutils=rsapad` (alone or combined, e.g. `=copy,rsapad`)
  emits just the padding define
- Unknown values are rejected with an updated error message
- The existing precondition `--enable-cryptocbutils requires --enable-cryptocb`
  applies unchanged

### `CMakeLists.txt`

New boolean option `WOLFSSL_CRYPTOCB_RSA_PAD` (default: `no`). When enabled it
emits `-DWOLF_CRYPTO_CB_RSA_PAD`. If set without `WOLFSSL_CRYPTOCB` it fails
at configure time with a clear error message.

## Usage

### Autotools

```sh
# Just the RSA padding callbacks
./configure --enable-cryptocb --enable-cryptocbutils=rsapad

# Combined with other utilities
./configure --enable-cryptocb --enable-cryptocbutils=copy,free,rsapad

# All utilities (now includes rsapad)
./configure --enable-cryptocb --enable-cryptocbutils
```

Typical HSM / PKCS#11 build:

```sh
./configure --enable-pkcs11 --enable-cryptocbutils=rsapad
```

(`--enable-pkcs11` forces `--enable-cryptocb` on, so the precondition is
satisfied automatically.)

### CMake

```sh
cmake -DWOLFSSL_CRYPTOCB=yes -DWOLFSSL_CRYPTOCB_RSA_PAD=yes ..
```

## Examples

Three end-to-end scenarios showing what the flag unlocks in practice.

### 1. Debian packaging

The RFE's motivating case. Debian currently ships without
`WOLF_CRYPTO_CB_RSA_PAD`, so `wc_pkcs11.c` falls back to raw RSA on HSMs that
have it disabled. With this change, the package rules can add a single
configure argument:

```sh
# debian/rules fragment
override_dh_auto_configure:
	dh_auto_configure -- \
	    --enable-pkcs11 \
	    --enable-cryptocbutils=rsapad
```

No more `EXTRA_CFLAGS=-DWOLF_CRYPTO_CB_RSA_PAD` hack in the package rules.

### 2. Application talking to a PKCS#11 HSM

When wolfSSL is routed through a PKCS#11 HSM (SoftHSM for dev, YubiHSM /
Nitrokey / AWS CloudHSM / SafeNet Luna for production), the HSM typically
refuses raw RSA. Enabling `rsapad` makes `wc_pkcs11.c` invoke
`CKM_RSA_PKCS_OAEP`, `CKM_RSA_PKCS`, and `CKM_RSA_PKCS_PSS` mechanisms
directly on the device.

```sh
./configure \
    --enable-pkcs11 \
    --enable-rsapss \
    --enable-cryptocbutils=rsapad
make
```

Application code is unchanged — `wolfSSL_CTX_use_PrivateKey_*` and
`wc_RsaSSL_Sign` / `wc_RsaPSS_Sign` transparently dispatch to the HSM.

### 3. Cross-build via CMake for an embedded target

A typical embedded / yocto-style build using the CMake knob:

```sh
cmake -S . -B build \
    -DCMAKE_TOOLCHAIN_FILE=/opt/toolchains/aarch64.cmake \
    -DWOLFSSL_CRYPTOCB=yes \
    -DWOLFSSL_CRYPTOCB_RSA_PAD=yes \
    -DWOLFSSL_PKCS11=yes
cmake --build build
```

Misconfigurations are caught at configure time. For example, forgetting the
prerequisite:

```sh
$ cmake -S . -B build -DWOLFSSL_CRYPTOCB_RSA_PAD=yes
...
CMake Error: WOLFSSL_CRYPTOCB_RSA_PAD requires WOLFSSL_CRYPTOCB
```

## Verification

Confirmed on a local build:

- `--enable-cryptocbutils=rsapad` emits only `-DWOLF_CRYPTO_CB_RSA_PAD`
- `--enable-cryptocbutils` emits all five (`COPY`, `FREE`, `SETKEY`,
  `EXPORT_KEY`, `RSA_PAD`)
- `--enable-cryptocbutils=foo` fails with
  `Unknown cryptocbutils option: foo. Valid options: copy, free, setkey, export, rsapad`
- `--enable-cryptocbutils=rsapad` without `--enable-cryptocb` fails with
  `--enable-cryptocbutils requires --enable-cryptocb`

## Files touched

- `configure.ac` — `--enable-cryptocbutils` block (help string, all-utils
  define list, case branch, error message)
- `CMakeLists.txt` — new `add_option("WOLFSSL_CRYPTOCB_RSA_PAD" ...)` and
  matching definition emission with a precondition check

## Appendix — C code verification

Traced the runtime effect of the flag end-to-end through the tree to confirm
the configure knob actually delivers what the RFE asks for.

### 1. Caller side — `wolfcrypt/src/rsa.c`

The padded RSA entry points (`wc_RsaPublicEncryptEx` at ~3430,
private-decrypt path at ~3618) gate on `WOLF_CRYPTO_CB_RSA_PAD`:

```c
/* rsa.c:3523 */
if (key->devId != INVALID_DEVID) {
    XMEMSET(&padding, 0, sizeof(RsaPadding));
    padding.pad_value = pad_value;
    padding.pad_type  = pad_type;   /* WC_RSA_PKCSV15_PAD / WC_RSA_PSS_PAD / WC_RSA_OAEP_PAD */
    padding.hash      = hash;
    padding.mgf       = mgf;
    padding.label     = label;
    padding.saltLen   = saltLen;
    ret = wc_CryptoCb_RsaPad(in, inLen, out, &outLen,
                             rsa_type, key, rng, &padding);
```

The `in` buffer here is the **unpadded** message — dispatch happens before the
software padding step, so the plaintext (plus padding metadata) crosses the
cryptocb boundary and the HSM constructs the padded block internally.

The decrypt gate at `rsa.c:3731` routes everything except `RSA_PUBLIC_DECRYPT`
(verify) through the callback. That's correct: HSMs disable raw *private-key*
ops, but public-key verify is cheap and stays in software.

When the macro is off, the old `wc_CryptoCb_Rsa` (no padding argument) is
called instead, and only already-padded bytes reach the callback.

### 2. Dispatcher — `wolfcrypt/src/cryptocb.c:543`

```c
switch (padding->pad_type) {
case WC_RSA_PKCSV15_PAD: pk_type = WC_PK_TYPE_RSA_PKCS; break;
case WC_RSA_PSS_PAD:     pk_type = WC_PK_TYPE_RSA_PSS;  break;
case WC_RSA_OAEP_PAD:    pk_type = WC_PK_TYPE_RSA_OAEP; break;
default:                 pk_type = WC_PK_TYPE_RSA;
}
...
cryptoInfo.pk.rsa.padding = padding;   /* extra struct field,
                                          gated at cryptocb.h:172 */
ret = dev->cb(dev->devId, &cryptoInfo, dev->ctx);
```

Note: `wc_CryptoCb_RsaPad` dispatches to **any** registered crypto callback,
not just PKCS#11. Any backend can choose to handle the new `WC_PK_TYPE_RSA_*`
types; PKCS#11 is just the first consumer.

### 3. PKCS#11 handler — `wolfcrypt/src/wc_pkcs11.c`

Top-level switch at `wc_pkcs11.c:6334` accepts the three new pk types under
the gate and routes to `Pkcs11Rsa` → `Pkcs11RsaEncrypt` / `Pkcs11RsaDecrypt`
/ `Pkcs11RsaSign`. Each maps the pk type to a PKCS#11 mechanism:

| wolfSSL pk_type | PKCS#11 mechanism | Params struct |
|---|---|---|
| `WC_PK_TYPE_RSA_PKCS` | `CKM_RSA_PKCS` | none |
| `WC_PK_TYPE_RSA_OAEP` | `CKM_RSA_PKCS_OAEP` | `CK_RSA_PKCS_OAEP_PARAMS` (hash + mgf from `padding->hash`/`padding->mgf`) |
| `WC_PK_TYPE_RSA_PSS`  | `CKM_RSA_PKCS_PSS`  | `CK_RSA_PKCS_PSS_PARAMS` (hash + mgf + saltLen) |
| `WC_PK_TYPE_RSA` (fallback when macro off) | `CKM_RSA_X_509` | none — **raw RSA** |

Verified at `wc_pkcs11.c:2733-2738` (encrypt), `2815-2820` (decrypt),
`2901-2906` (sign). OAEP / PSS parameter population at `2752-2759`,
`2834-2841`, `2919-2957`.

### Conclusion

- With `WOLF_CRYPTO_CB_RSA_PAD` **off**, a PKCS#11 HSM only ever sees
  `CKM_RSA_X_509` (raw RSA). HSMs that refuse raw RSA will fail.
- With it **on**, the unpadded message + padding metadata crosses the cryptocb
  boundary and the HSM performs OAEP / PKCS#1 v1.5 / PSS internally via the
  matching `CKM_*` mechanism.
- Verify (`RSA_PUBLIC_DECRYPT`) intentionally stays in software even with the
  flag on — public-key ops are cheap and verify doesn't need the HSM.
- Application code is unchanged — dispatch happens inside the padded RSA
  entry points, not at the application layer.

No dead gates, no mismatch between the RFE's stated intent and the actual
implementation. The configure knob is a pure ergonomics improvement: it
exposes correct, already-wired behavior that previously required
`EXTRA_CFLAGS`.

Happy to turn this into a PR if useful.

[kareem-wolfssl]

Hi @cpsource,

Thanks for the patch. We do require an approved contributor agreement on file in order to accept third-party contributions. If you're interested in setting this up please contact us at support@wolfssl.com.

[cpsource]

It’s probably impossible for me to officially contribute. Just read through this CLA and you will see why. Alright—here’s a *corporate-grade Contributor License Agreement (CLA)* tailored for your situation: - Protects *you as the contributor* - Explicitly handles *AI-generated code (e.g., Claude Code)* - Avoids traps common in big-company CLAs (like one-sided indemnity) - Still acceptable to most professional/open-source projects

…

------------------------------ *CORPORATE-GRADE CONTRIBUTOR LICENSE AGREEMENT (CLA)* *Version 1.0 — AI-Aware, Contributor-Protective* ------------------------------ *1. Parties* This Contributor License Agreement (“Agreement”) is entered into by: - *Contributor:* __________________________ - *Project / Organization:* __________________________ - *Effective Date:* __________________________

------------------------------ *2. Purpose* This Agreement defines the terms under which the Contributor submits Contributions to the Project and allocates rights, risks, and responsibilities between the parties. ------------------------------ *3. Definitions* - *“Contribution”*: Any code, documentation, or material submitted - *“Project”*: The software project identified above - *“Submission”*: Any delivery of Contributions (PRs, commits, patches, etc.) - *“AI Tools”*: Automated systems used to generate or assist Contributions

------------------------------ *4. Ownership* 4.1 *Retention of Rights* Contributor retains all right, title, and interest in their Contributions. 4.2 *No Assignment* No ownership is transferred to the Project. ------------------------------ *5. License Grant* 5.1 *License to Project* Contributor grants a *non-exclusive, worldwide, royalty-free, perpetual, irrevocable license* to: - Use, reproduce, modify, distribute, sublicense - Incorporate Contributions into the Project 5.2 *Scope* This license applies only to use within the Project and its licensing terms. ------------------------------ *6. Contributor Representations (Knowledge-Based)* Contributor represents, *to the best of their knowledge and belief*, that: - They have the right to submit the Contributions - Contributions are original, transformed, or properly licensed - Contributions do not knowingly infringe third-party rights 👉 *No strict liability—this is deliberate* ------------------------------ *7. AI-Generated Contributions* 7.1 *Use of AI Tools* Contributor may use AI Tools, including systems such as Claude Code, to generate or assist Contributions. 7.2 *Contributor Obligations* Contributor represents that: - They have rights to use outputs under applicable AI tool terms - They have reviewed and validated the Contributions - They have no knowledge of intentional license violations 7.3 *Project Acknowledgment* The Project acknowledges that: - Contributions may include AI-generated content - Such content may not be copyrightable - Similarity to third-party works may occur

------------------------------ *8. No Warranty* Contributions are provided *“AS IS”*, without warranties of any kind. ------------------------------ *9. Limitation of Liability* Contributor shall not be liable for: - Indirect, incidental, or consequential damages - Any damages arising from use of Contributions

------------------------------ *10. Indemnification (Balanced)* 10.1 *No Contributor Indemnity* Contributor shall *not* be required to indemnify the Project. 10.2 *Project Responsibility* The Project assumes all risks associated with: - Integration - Distribution - Downstream use

------------------------------ *11. Patent License* Contributor grants a *non-exclusive, worldwide, royalty-free patent license* for patents necessarily infringed by their Contributions. ------------------------------ *12. Patent Retaliation* If the Project or its users initiate patent litigation against Contributor, all patent licenses granted herein terminate. ------------------------------ *13. Attribution* The Project agrees to: - Preserve attribution where reasonable - Not remove authorship notices

------------------------------ *14. No Exclusivity* Contributor may: - Reuse Contributions - License similar code elsewhere

------------------------------ *15. Withdrawal* Contributor may request removal of Contributions, but: - Prior distributions remain valid - The Project is not required to rewrite history

------------------------------ *16. Compliance with Open Source License* The Project is responsible for ensuring: - Compliance with its chosen license - Proper handling of Contributions

------------------------------ *17. Risk Allocation (Critical Clause)* The Project acknowledges that Contributions may: - Lack enforceable intellectual property protection - Contain similarities to third-party materials - Be subject to evolving AI-related legal standards 👉 *All such risks are assumed by the Project* ------------------------------ *18. Governing Law* This Agreement shall be governed by the laws of: *State of California, USA* *(recommended for tech enforceability)* ------------------------------ *19. Entire Agreement* This Agreement constitutes the entire understanding between the parties. ------------------------------ *20. Signature* *Contributor:* Name: __________________________ Signature: ______________________ Date: __________________________ *Project / Organization:* Name: __________________________ Signature: ______________________ Date: __________________________ ------------------------------ *🔐 Why this is “corporate-grade” (not fluff)* This version fixes what most CLAs get wrong: *✅ You are protected from:* - Strict liability infringement claims - AI ambiguity risk - Indemnification traps - Loss of ownership *✅ It is still acceptable because:* - You grant broad usage rights - You include patent license - You include representations (but softened)

------------------------------ *⚠️ Reality check (important)* Big orgs like Google or Apache Software Foundation will *not accept this as-is*—they use contributor-hostile CLAs. 👉 But for: - Your own project - Smaller OSS communities - Partner agreements This is *strong and defensible*

On Wed, Apr 22, 2026 at 15:40 kareem-wolfssl ***@***.***> wrote: *kareem-wolfssl* left a comment (wolfSSL/wolfssl#10271) <#10271 (comment)> Hi @cpsource <https://github.com/cpsource>, Thanks for the patch. We do require an approved contributor agreement on file in order to accept third-party contributions. If you're interested in setting this up please contact us at ***@***.*** — Reply to this email directly, view it on GitHub <#10271?email_source=notifications&email_token=AAU5XNBE2VV2MOJKIWG7JI34XFC45A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMZQGAZTSMJRGY3KM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4300391166>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAU5XNH2WY2JS43ME2HZHAL4XFC45AVCNFSM6AAAAACYAQEDFOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DGMBQGM4TCMJWGY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[kareem-wolfssl]

Ok, in that case we will treat your patch as a bug report.

[cpsource]

Do you want me to create a separate issue or post a reply to the issue? Cal

…

On Thu, Apr 23, 2026 at 10:08 AM kareem-wolfssl ***@***.***> wrote: *kareem-wolfssl* left a comment (wolfSSL/wolfssl#10271) <#10271 (comment)> Ok, in that case we will treat your patch as a bug report. — Reply to this email directly, view it on GitHub <#10271?email_source=notifications&email_token=AAU5XNBPL6LZ3CXGJIPCAE34XJEXBA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMZQGYZTCNJQG4YKM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4306315070>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAU5XNDWGRMSEPE2HVYIIB34XJEXBAVCNFSM6AAAAACYAQEDFOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DGMBWGMYTKMBXGA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[kareem-wolfssl]

Cal, while I appreciate your interest in helping, we are unable to accept any code contributions without a contributor agreement on file. Please refrain from submitting code patches to our Github repo if you are unwilling to submit a contributor agreement. Thank you.

[cpsource]

I have read-only access to your repositories, so you don't have to worry about me submitting anything. My replies to issues are only suggestions to you. And, I recommend you install Claude code, and use the 'skill' I've mentioned in a post to your support line. The main reason I can't sign, is that I take on liability, which I am unwilling to do. Cal

…

On Thu, Apr 23, 2026 at 10:35 AM kareem-wolfssl ***@***.***> wrote: *kareem-wolfssl* left a comment (wolfSSL/wolfssl#10271) <#10271 (comment)> Cal, while I appreciate your interest in helping, we are unable to accept any code contributions without a contributor agreement on file. Please refrain from submitting code patches to our Github repo if you are unwilling to submit a contributor agreement. Thank you. — Reply to this email directly, view it on GitHub <#10271?email_source=notifications&email_token=AAU5XNAUXDLCX2U6AEG4E7T4XJH73A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMZQGY2DQNRVGM3KM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4306486536>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAU5XNHK3OBT33FRY756HU34XJH73AVCNFSM6AAAAACYAQEDFOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DGMBWGQ4DMNJTGY> . You are receiving this because you were mentioned.Message ID: ***@***.***>