Skip to content

Store in extensions the full octet string #8967

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 13 commits into
base: master
Choose a base branch
from

Conversation

ribes96
Copy link
Contributor

@ribes96 ribes96 commented Jul 4, 2025

Store in WOLFSSL_X509_EXTENSION.value always the full contents of the OCTET STRING of the extension, instead of different type of data depending on the type of extension. Previously this was only done for unknown extensions.

Description

It is clear from Issue #8941 that X509_EXTENSION_get_data has a clear different behavior on OpenSSL than in WolfSSL. RFC8280 defines an extension as:

Extension  ::=  SEQUENCE  {
     extnID      OBJECT IDENTIFIER,
     critical    BOOLEAN DEFAULT FALSE,
     extnValue   OCTET STRING
                 -- contains the DER encoding of an ASN.1 value
                 -- corresponding to the extension type identified
                 -- by extnID
     }

Whereas OpenSSL always returns the full OCTET STRING when calling X509_EXTENSION_get_data, WolfSSL returns a different type of object depending on the type of extension parsed. This can be observed in the following program:

#include <stdio.h>
#include <err.h>

#ifdef USE_WOLFSSL

#define WOLFSSL_USE_OPTIONS_H

#include <wolfssl/ssl.h>
#include <wolfssl/openssl/pem.h>
#include <wolfssl/openssl/ssl.h>
#include <wolfssl/openssl/buffer.h>

#endif /* USE_WOLFSSL */

#ifdef USE_OPENSSL

#include <openssl/x509.h>
#include <openssl/pem.h>
#include <openssl/err.h>

#endif /* USE_OPENSSL */

int main (int argc, char **argv)
{
	const char     *filename;
	FILE           *f;
	X509           *x509;
	int            n_extensions;
	int            i;

	if (argc < 2)
		errx (-1, "Error: Usage: <filename>");

	filename = argv[1];

	if ((f = fopen (filename, "r")) == NULL)
		err (-1, "%s", filename);

	if ((x509 = PEM_read_X509 (f, NULL, NULL, NULL)) == NULL)
		err (-1, NULL);

	fclose (f);

	n_extensions = X509_get_ext_count (x509);
	for (i = 0; i < n_extensions; ++i)
	{
		X509_EXTENSION         *ext;
		ASN1_OBJECT            *object;
		char                   oid[32];
		int                    j;
		#ifdef USE_WOLFSSL
		ASN1_STRING            *data;
		#endif /* USE_WOLFSSL */

		#ifdef USE_OPENSSL
		ASN1_OCTET_STRING      *data;
		#endif /* USE_OPENSSL */

		if ((ext = X509_get_ext (x509, i)) == NULL)
			errx (-1, "Error: No extension at %d\n", i);

		if ((object = X509_EXTENSION_get_object (ext)) == NULL)
			errx (-1, "Error: No object for extension at %d\n", i);

		OBJ_obj2txt (oid, sizeof (oid), object, 1);

		if ((data = X509_EXTENSION_get_data (ext)) == NULL)
			errx (-1, "Error: No data for extension at %d\n", i);

		printf ("i=%d\n", i);
		printf ("oid=%s\n", oid);
		printf ("data->length=%d\n", data->length);
		printf ("data->data={");
		for (j = 0; j < data->length; ++j)
			printf ("%02X:", (unsigned char) data->data[j]);
		printf ("}\n");
		printf ("\n");
	}


	X509_free (x509);
	return 0;
}

For example with this extension

-----BEGIN CERTIFICATE-----
MIIFYjCCBEqgAwIBAgIQd70NbNs2+RrqIQ/E8FjTDTANBgkqhkiG9w0BAQsFADBX
MQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEQMA4GA1UE
CxMHUm9vdCBDQTEbMBkGA1UEAxMSR2xvYmFsU2lnbiBSb290IENBMB4XDTIwMDYx
OTAwMDA0MloXDTI4MDEyODAwMDA0MlowRzELMAkGA1UEBhMCVVMxIjAgBgNVBAoT
GUdvb2dsZSBUcnVzdCBTZXJ2aWNlcyBMTEMxFDASBgNVBAMTC0dUUyBSb290IFIx
MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAthECix7joXebO9y/lD63
ladAPKH9gvl9MgaCcfb2jH/76Nu8ai6Xl6OMS/kr9rH5zoQdsfnFl97vufKj6bwS
iV6nqlKr+CMny6SxnGPb15l+8Ape62im9MZaRw1NEDPjTrETo8gYbEvs/AmQ351k
KSUjB6G00j0uYODP0gmHu81I8E3CwnqIiru6z1kZ1q+PsAewnjHxgsHA3y6mbWwZ
DrXYfiYaRQM9sHmklCitD38m5agI/pboPGiUU+6DOogrFZYJsuB6jC511pzrp1Zk
j5ZPaK49l8KEj8C8QMALXL32h7M1bKwYUH+E4EzNktMg6TO8UpmvMrUpsyUqtEj5
cuHKZPfmghCN6J3Cioj6OGaK/GP5Afl4/Xtcd/p2h/rs37EOeZVXtL0m79YB0esW
CruOC7XFxYpVq9Os6pFLKcwZpDIlTirxZUTQAs6qzkm06p98g7BAe+dDq6dso499
iYH6TKX/1Y7DzkvgtdizjkXPdsDtQCv9Uw+wp9U7DbGKogPeMa3Md+pvez7W35Ei
Eua++tgy/BBjFFFy3l3WFpO9KWgz7zpm7AeKJt8T11dleCfeXkkUAKIAf5qoIbap
sZWwpbkNFhHax2xIPEDgfg1azVY80ZcFuctL7TlLnMQ/0lUTbiSw1nH69MG6zO0b
9f6BQdgAmD06yK56mDcYBZUCAwEAAaOCATgwggE0MA4GA1UdDwEB/wQEAwIBhjAP
BgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBTkrysmcRorSCeFL1JmLO/wiRNxPjAf
BgNVHSMEGDAWgBRge2YaRQ2XyolQL30EzTSo//z9SzBgBggrBgEFBQcBAQRUMFIw
JQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnBraS5nb29nL2dzcjEwKQYIKwYBBQUH
MAKGHWh0dHA6Ly9wa2kuZ29vZy9nc3IxL2dzcjEuY3J0MDIGA1UdHwQrMCkwJ6Al
oCOGIWh0dHA6Ly9jcmwucGtpLmdvb2cvZ3NyMS9nc3IxLmNybDA7BgNVHSAENDAy
MAgGBmeBDAECATAIBgZngQwBAgIwDQYLKwYBBAHWeQIFAwIwDQYLKwYBBAHWeQIF
AwMwDQYJKoZIhvcNAQELBQADggEBADSkHrEoo9C0dhemMXoh6dFSPsjbdBZBiLg9
NR3t5P+T4Vxfq7vqfM/b5A3Ri1fyJm9bvhdGaJQ3b2t6yMAYN/olUazsaL+yyEn9
WprKASOshIArAoyZl+tJaox118fessmXn1hIVw41oeQa1v1vg4Fv74zPl6/AhSrw
9U5pCZEt4Wi4wStz6dTZ/CLANx8LZh1J7QJVj2fhMtfTJr9w4z30Z209fOU0iOMy
+qduBmpvvYuR7hZL6Dupszfnw0Skfths18dG9ZKb59UhvmaSGZRVbNQpsg3BZlvi
d0lIKO2d1xozclOzgjXPYovJJIultzkMu34qQb9Sz/yilrbCgj8=
-----END CERTIFICATE-----

Given that wolfSSL_X509_EXTENSION_get_data is currently aliased to X509_EXTENSION_get_data, I would say the intention is for them to have the same behaviour, so this PR changes how an extension is stored in WolfSSL.

Now, this is a clear change of behavior, and will probably break a lot of tests. To start, the API of the public function would need to be changed to return an ASN1_OCTET_STRING instead of an ASN1_STRING. But I don't really see a utility for a function that returns different type of data depending on the type of extension, other than to print it in a console.

So, this PR is not really intended to be merged yet, but to trigger a discussion about how should WolfSSL behave. If it is acknowledged that they should not have the same behavior, I think the alias to OpenSSL alternatives should be removed.

Please describe the scope of the fix or feature addition.

The storage format of an X.509 extension is changed

Fixes #8941

Testing

How did you test?

No testing other than running the attached program

Checklist

  • added tests
  • updated/added doxygen
  • updated appropriate READMEs
  • Updated manual and documentation

@wolfSSL-Bot
Copy link

Can one of the admins verify this patch?

@dgarske
Copy link
Contributor

dgarske commented Jul 4, 2025

Okay to test. No approved contributor agreement yet but process started.

@ribes96
Copy link
Contributor Author

ribes96 commented Jul 8, 2025

Last pushed commit (979d732 (Add missing ext_sk to ALT_NAMES extension, 2025-07-08)) makes the LDAP tests pass.

libspdm is failing because the 'wolfSSL/osp' project has a patch with the following contents:

--- a/library/spdm_crypt_lib/libspdm_crypt_cert.c
+++ b/library/spdm_crypt_lib/libspdm_crypt_cert.c
@@ -911,11 +911,13 @@ static bool libspdm_verify_leaf_cert_spdm_eku(const uint8_t *cert, size_t cert_s
     req_auth_oid_find_success = false;
     rsp_auth_oid_find_success = false;
 
+#ifndef SPDM_USING_WOLFSSL /* wolfssl returns data without sequence tag */
     status = libspdm_asn1_get_tag(&ptr, eku + eku_size, &obj_len,
                                   LIBSPDM_CRYPTO_ASN1_SEQUENCE | LIBSPDM_CRYPTO_ASN1_CONSTRUCTED);
     if (!status) {
         return false;
     }
+#endif
 
     while(ptr < eku + eku_size) {
         status = libspdm_asn1_get_tag(&ptr, eku + eku_size, &obj_len, LIBSPDM_CRYPTO_ASN1_OID);

So it is working around precisely the behavior that this PR is fixing. With the patch fixed, the libspdm tests pass in my workstation.

@dgarske
Copy link
Contributor

dgarske commented Jul 8, 2025

Okay to test. Contributor agreement approved and on file.

@dgarske dgarske requested review from Copilot and SparkiDev July 8, 2025 22:50
Copilot

This comment was marked as outdated.

@dgarske
Copy link
Contributor

dgarske commented Jul 8, 2025

Last pushed commit (979d732 (Add missing ext_sk to ALT_NAMES extension, 2025-07-08)) makes the LDAP tests pass.

libspdm is failing because the 'wolfSSL/osp' project has a patch with the following contents:

--- a/library/spdm_crypt_lib/libspdm_crypt_cert.c
+++ b/library/spdm_crypt_lib/libspdm_crypt_cert.c
@@ -911,11 +911,13 @@ static bool libspdm_verify_leaf_cert_spdm_eku(const uint8_t *cert, size_t cert_s
     req_auth_oid_find_success = false;
     rsp_auth_oid_find_success = false;
 
+#ifndef SPDM_USING_WOLFSSL /* wolfssl returns data without sequence tag */
     status = libspdm_asn1_get_tag(&ptr, eku + eku_size, &obj_len,
                                   LIBSPDM_CRYPTO_ASN1_SEQUENCE | LIBSPDM_CRYPTO_ASN1_CONSTRUCTED);
     if (!status) {
         return false;
     }
+#endif
 
     while(ptr < eku + eku_size) {
         status = libspdm_asn1_get_tag(&ptr, eku + eku_size, &obj_len, LIBSPDM_CRYPTO_ASN1_OID);

So it is working around precisely the behavior that this PR is fixing. With the patch fixed, the libspdm tests pass in my workstation.

@julek-wolfssl will you please work on updating the libspdm patch and reviewing this PR?

Copy link
Contributor

@SparkiDev SparkiDev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Otherwise good to have this change.

julek-wolfssl added a commit to julek-wolfssl/osp that referenced this pull request Jul 11, 2025
wolfSSL/wolfssl#8967 updates wolfSSL to return DER data in the same way as OpenSSL. When this PR goes in then wolfSSL/wolfssl#8967 needs to be re-run and merged so that other wolfSSL PR's are not blocked on libspdm test failures.
Copy link
Member

@julek-wolfssl julek-wolfssl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't like the growing complexity of wolfSSL_X509V3_EXT_d2i. At this point I would prefer to use DecodeCertExtensions to parse the extension and then set the appropriate fields from DecodedCert. @ribes96 are you up for such a refactor or should one of us tackle this section?

@ribes96
Copy link
Contributor Author

ribes96 commented Jul 11, 2025

I don't like the growing complexity of wolfSSL_X509V3_EXT_d2i. At this point I would prefer to use DecodeCertExtensions to parse the extension and then set the appropriate fields from DecodedCert. @ribes96 are you up for such a refactor or should one of us tackle this section?

In fact this this function is just replicating what the following functions do:

DecodeBasicCaConstraint
DecodeSubjKeyId
DecodeAuthKeyId
DecodeKeyUsage

But they couldn't be used on the one hand because they are private of wolfcrypt, and on the other because they all receive as parameter a DecodedCert, which is not available in wolfSSL_X509V3_EXT_d2i because there is simply no certificate, just an extension.

So the path forward would be to add a version of these functions to the public API of wolfcrypt, that doesn't receive a DecodedCert but some specific data, and use them both inside current functions DecodeBasicCaConstraint, etc, and from wolfSSL_X509V3_EXT_d2i.

I can do that

@dgarske dgarske self-assigned this Jul 11, 2025
@dgarske
Copy link
Contributor

dgarske commented Jul 11, 2025

./configure CC="clang -fsanitize=address,undefined -g" --enable-all --enable-sp-math-all
FAIL: scripts/unit.test

See: https://github.com/wolfSSL/wolfssl/actions/runs/16224294061/job/45819565451?pr=8967

    710: test_wolfSSL_X509V3_EXT                            :tests/api.c:43770:5: runtime error: call to function (unknown) through pointer to incorrect function type 'char *(*)(struct WOLFSSL_v3_ext_method *, void *)'
(/home/davidgarske/GitHub/wolfssl/src/.libs/libwolfssl.so.43+0x6cd898): note: (unknown) defined here
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior tests/api.c:43770:5 
 passed (  0.00069)
    711: test_wolfSSL_X509V3_EXT_bc                         : passed (  0.00000)
    712: test_wolfSSL_X509V3_EXT_san                        : passed (  0.00000)
    713: test_wolfSSL_X509V3_EXT_aia                        : passed (  0.00001)
    714: test_wolfSSL_X509V3_EXT_print                      :=================================================================
==2033422==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7bafba8f4aa1 at pc 0x0000004af87f bp 0x7ffec4fbc410 sp 0x7ffec4fbbbd0
READ of size 611 at 0x7bafba8f4aa1 thread T0
    #0 0x0000004af87e  (/home/davidgarske/GitHub/wolfssl/tests/.libs/unit.test+0x4af87e) (BuildId: 0fc9b9dcb8ce3765825afd11856edfdf479144ea)
    #1 0x7fafbd0c2a15  (/home/davidgarske/GitHub/wolfssl/src/.libs/libwolfssl.so.43+0x6c2a15) (BuildId: b849fc0057905a409e0b93d1836dbe2acfb1bc78)
    #2 0x7fafbd1c4010  (/home/davidgarske/GitHub/wolfssl/src/.libs/libwolfssl.so.43+0x7c4010) (BuildId: b849fc0057905a409e0b93d1836dbe2acfb1bc78)
    #3 0x0000006f849e  (/home/davidgarske/GitHub/wolfssl/tests/.libs/unit.test+0x6f849e) (BuildId: 0fc9b9dcb8ce3765825afd11856edfdf479144ea)
    #4 0x000000974389  (/home/davidgarske/GitHub/wolfssl/tests/.libs/unit.test+0x974389) (BuildId: 0fc9b9dcb8ce3765825afd11856edfdf479144ea)
    #5 0x0000004f7476  (/home/davidgarske/GitHub/wolfssl/tests/.libs/unit.test+0x4f7476) (BuildId: 0fc9b9dcb8ce3765825afd11856edfdf479144ea)
    #6 0x7fafbc6c65f4  (/lib64/libc.so.6+0x35f4) (BuildId: c4b06a608071b2c9852fae62ca3b69cdc22cd022)
    #7 0x7fafbc6c66a7  (/lib64/libc.so.6+0x36a7) (BuildId: c4b06a608071b2c9852fae62ca3b69cdc22cd022)
    #8 0x00000040e074  (/home/davidgarske/GitHub/wolfssl/tests/.libs/unit.test+0x40e074) (BuildId: 0fc9b9dcb8ce3765825afd11856edfdf479144ea)

Address 0x7bafba8f4aa1 is located in stack of thread T0 at offset 161 in frame
    #0 0x7fafbd1c37c7  (/home/davidgarske/GitHub/wolfssl/src/.libs/libwolfssl.so.43+0x7c37c7) (BuildId: b849fc0057905a409e0b93d1836dbe2acfb1bc78)

  This frame has 3 object(s):
    [32, 161) 'tmp' (line 1474)
    [240, 245) 'isCa' (line 1501) <== Memory access at offset 161 partially underflows this variable
    [272, 278) 'notCa' (line 1502) <== Memory access at offset 161 partially underflows this variable
HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork
      (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow (/home/davidgarske/GitHub/wolfssl/tests/.libs/unit.test+0x4af87e) (BuildId: 0fc9b9dcb8ce3765825afd11856edfdf479144ea) 
Shadow bytes around the buggy address:
  0x7bafba8f4800: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
  0x7bafba8f4880: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
  0x7bafba8f4900: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
  0x7bafba8f4980: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
  0x7bafba8f4a00: f1 f1 f1 f1 00 00 00 00 00 00 00 00 00 00 00 00
=>0x7bafba8f4a80: 00 00 00 00[01]f2 f2 f2 f2 f2 f2 f2 f2 f2 f8 f2
  0x7bafba8f4b00: f2 f2 f8 f3 f3 f3 f3 f3 00 00 00 00 00 00 00 00
  0x7bafba8f4b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7bafba8f4c00: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
  0x7bafba8f4c80: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
  0x7bafba8f4d00: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==2033422==ABORTING

@SparkiDev
Copy link
Contributor

Consider putting in #ifdefs to have the library do the old behaviour for those that are expecting it.

@dgarske
Copy link
Contributor

dgarske commented Jul 14, 2025

Retest this please: "AgentOfflineException"

@julek-wolfssl
Copy link
Member

@ribes96 My plan was to expose DecodeCertExtensions and to allocate a DecodedCert on the stack to decode the extensions. This wasy asn.c changes stay minimal.

@ribes96
Copy link
Contributor Author

ribes96 commented Jul 15, 2025

@ribes96 My plan was to expose DecodeCertExtensions and to allocate a DecodedCert on the stack to decode the extensions. This wasy asn.c changes stay minimal.

I'm not seeing how that can be done. DecodeCertExtensions expects a full extensions sequence inside DecodedCert->{extensions, extensionsSz} and then fills DecodedCert with the extensions found there. Are you proposing to construct a dummy extensions sequence, containing the only one extension available in wolfSSL_X509V3_EXT_d2i, initialize a new DecodedCert by just filling extensions and extensionsSz with the dummy extensions sequence, then call DecodeCertExtensions and extract from DecodedCert the appropriate fields depending on the extension?

@ribes96
Copy link
Contributor Author

ribes96 commented Jul 17, 2025

Consider putting in #ifdefs to have the library do the old behaviour for those that are expecting it.

I am now working on this
I am considering adding a new private function that transforms a given WOLFSSL_ASN1_STRING from containing the full extension OCTET STRING into the old contents. Then function wolfSSL_X509_EXTENSION_get_data would call it in the end depending on the #ifdefs. wolfSSL_X509_EXTENSION_get_data should be split into an internal version and an external version, to ensure that internal callers get the expected behavior independently of the #ifdef.

Any proposal for the name of the feature flag?

Strictly speaking, wolfSSL_X509_EXTENSION_get_data should be updated to return an ASN1_OCTET_STRING instead of an ASN1_STRING. They are currently aliased:

#define ASN1_OCTET_STRING         WOLFSSL_ASN1_STRING

Should we change the function signature? I'm not sure how will this affect existing callers

SparkiDev
SparkiDev previously approved these changes Jul 20, 2025
@ribes96
Copy link
Contributor Author

ribes96 commented Aug 4, 2025

@dgarske as I suspected, the Zephyr tests are failing again due to to commit 97b2ef4f6 (Allow NULL parameters for 'DecodeAuthKeyId', 2025-08-03). Reverting it makes it pass again. Should I? The only thing that commit does is add a bunch of 'ifs', and that's enough to slown down dramatically the Zephyr tests

@ribes96
Copy link
Contributor Author

ribes96 commented Aug 4, 2025

haproxy failures have nothing to do with these commits. Repo https://github.com/wlallemand/VTest has been deleted

@dgarske
Copy link
Contributor

dgarske commented Aug 4, 2025

@dgarske as I suspected, the Zephyr tests are failing again due to to commit 97b2ef4f6 (Allow NULL parameters for 'DecodeAuthKeyId', 2025-08-03). Reverting it makes it pass again. Should I? The only thing that commit does is add a bunch of 'ifs', and that's enough to slown down dramatically the Zephyr tests

Seems like the better fix is to allow more time on the test?

DEBUG   - QEMU (12086): PKCS12   test passed!
DEBUG   - QEMU (12086) complete (unexpected eof) after 119.97149276733398 seconds
DEBUG   - return code from QEMU (None): 0
DEBUG   - run status: qemu_x86/zephyr/samples/wolfssl_test/sample.crypto.wolfssl_test_no_malloc failed
INFO    - 1/1 qemu_x86                  zephyr/samples/wolfssl_test/sample.crypto.wolfssl_test_no_malloc  FAILED Timeout (qemu 119.971s)

@ribes96
Copy link
Contributor Author

ribes96 commented Aug 4, 2025

@dgarske as I suspected, the Zephyr tests are failing again due to to commit 97b2ef4f6 (Allow NULL parameters for 'DecodeAuthKeyId', 2025-08-03). Reverting it makes it pass again. Should I? The only thing that commit does is add a bunch of 'ifs', and that's enough to slown down dramatically the Zephyr tests

Seems like the better fix is to allow more time on the test?

DEBUG   - QEMU (12086): PKCS12   test passed!
DEBUG   - QEMU (12086) complete (unexpected eof) after 119.97149276733398 seconds
DEBUG   - return code from QEMU (None): 0
DEBUG   - run status: qemu_x86/zephyr/samples/wolfssl_test/sample.crypto.wolfssl_test_no_malloc failed
INFO    - 1/1 qemu_x86                  zephyr/samples/wolfssl_test/sample.crypto.wolfssl_test_no_malloc  FAILED Timeout (qemu 119.971s)

Well, if it is not a problem that some workload will run considerably slower...

The required time increased from over 85 secs to over 140

@dgarske
Copy link
Contributor

dgarske commented Aug 5, 2025

Jenkins retest this please: "AgentOfflineException"

Copy link
Contributor

@Copilot Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull Request Overview

This PR changes how X.509 extension data is stored in WolfSSL to match OpenSSL's behavior by always storing the full OCTET STRING content in the extension value field, rather than different types of data depending on the extension type.

  • Extracts extension parsing logic into reusable functions with consistent interfaces
  • Modifies extension storage to always contain the complete OCTET STRING data
  • Adds backwards compatibility option via --enable-old-extdata-fmt configure flag

Reviewed Changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 1 comment.

Show a summary per file
File Description
zephyr/samples/wolfssl_test/sample.yaml Increases timeout for test sample from 120 to 200 seconds
wolfssl/wolfcrypt/asn.h Adds function declarations for new extension decoding functions
wolfcrypt/src/asn.c Refactors extension parsing into standalone functions and updates internal calls
tests/api.c Adds test to verify new extension data format behavior
src/x509.c Major restructuring of extension handling to store full OCTET STRING data
configure.ac Adds configure option for backwards compatibility with old extension format
Comments suppressed due to low confidence (4)

@dgarske
Copy link
Contributor

dgarske commented Aug 7, 2025

Jenkins retest this please: "AgentOfflineException"

@dgarske dgarske self-assigned this Aug 7, 2025
julek-wolfssl
julek-wolfssl previously approved these changes Aug 7, 2025
Copy link
Member

@julek-wolfssl julek-wolfssl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎆

Copy link
Contributor

@dgarske dgarske left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The work in this PR is excellent! I really appreciate your efforts. This PR is VERY close to being accepted and merged.

@dgarske
Copy link
Contributor

dgarske commented Aug 7, 2025

Jenkins retest this please: FIPS test failed with "RequestAbortedException"

@dgarske
Copy link
Contributor

dgarske commented Aug 8, 2025

Jenkins retest this please: "AgentOfflineException"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Get full OCTET STRING of an extension
5 participants