summaryrefslogtreecommitdiff
path: root/src/regress/lib (follow)
Commit message (Collapse)AuthorAgeFilesLines
* wycheproof: skip BLS test vectors to prepare for updatetb2026-04-211-1/+3
|
* pkcs7test: factor main into a helper so we can add some unit tests easilytb2026-04-211-3/+13
|
* keypairtest: zero out tls_error before running teststb2026-04-151-2/+2
| | | | | | | Otherwise tls_error_clear() (called e.g. via tls_error_vset()) will free the bad error->msg pointer. From Michael Forney
* Prior to this we substring matched and allowed a leading .beck2026-04-131-2/+49
| | | | | | | | | | | on a SAN DNSname constraint. This is not correct, as with a DNSname constraint, it may exacly match or match zero or more additional components on the front of the candidte to match. Spotted by Haruto Kimura <hkimura2026@gmail.com> ok tb@ kenjiro@
* Fix min vs max in failure output.jsing2026-04-031-3/+3
|
* Use DTLS_client_method() instead of DTLSv1_client_method().jsing2026-04-031-3/+3
|
* Adjust depth check to match change in verifier.jsing2026-04-011-2/+2
|
* Add additional X.509 verifier test cases.jsing2026-03-312-2/+28
| | | | The second case (14b) currently triggers a bug in the new verifier.
* Run new test certificate bundles through Go's verifier.jsing2026-03-311-0/+2
|
* Add additional certificate test bundles.jsing2026-03-314-0/+1450
|
* Generate two additional certificate test scenarios which have deep chains.jsing2026-03-311-0/+16
|
* libssl regress: adjust golden numbers for RSASSA-PSStb2026-03-302-39/+44
| | | | | | Add the three RSASSA-PSS SignatureScheme 0x080b, 0x080a, 0x0809 in the appropriate spots in (components of) the ClientHello and adjust various length octets by adding 6.
* Add missing include path required to reach newly added crypto_assembly.hanton2026-03-291-2/+3
| | | | include.
* rfc3779 regress: explain where the range comes fromtb2026-03-131-1/+5
|
* rfc3779 regress: add an actual rangetb2026-03-131-1/+52
| | | | | | This improves the test coverage of make_addressRange() where there is an annoyance with unused bits in the RFC 3779 ASN.1 encoding versus trailing ones in the network encoding that the X509v3_addr_add_range() API expects.
* assembly regress: use make's MACHINE_ARCH rather than handrolling ittb2026-01-251-4/+3
| | | | discussed with jsing
* Fix tyojsing2026-01-251-2/+2
|
* Hook assembly regressjsing2026-01-251-1/+2
|
* Add a regress test that ensures our pure assembly code builds with gccjsing2026-01-251-0/+36
| | | | | | This requires egcc to be installed, if not we'll just skip the test. Discussed with tb@
* unusally -> unusuallytb2026-01-233-30/+30
|
* bn_ffdh: unifdef HAVE_SCAPY_SPECIALtb2026-01-231-7/+1
|
* bn_ffdh: unifdef HAVE_RFC7919_PRIMEStb2026-01-231-8/+1
|
* bn regress: add test that double checks the RFC 2409 and 3526 primestb2026-01-232-1/+505
| | | | | Also has code to check the RFC 7919 primes and run DH_check() once that knows about these.
* wycheproof regress: wycheproof-testvectors was renamed to wycheprooftb2026-01-221-2/+2
| | | | | Installed packages will update and pkg_add wycheproof-testvectors will continue to work.
* policy test: parital -> partialtb2026-01-221-2/+2
|
* ML-KEM: unstub runMLKEMKeyGenTest()tb2026-01-221-1/+50
| | | | | This adds coverage for MLKEM_private_key_from_seed(), which was previously only minimal teted from our regress.
* ML-KEM: improve the EncapsTesttb2026-01-221-4/+46
| | | | | New testvectors want some more detailed handling, which brings these Wycheproof encapsulation tests about on par with our existing tests.
* ML-KEM: add handler stub for the new KeyGenTesttb2026-01-221-1/+7
|
* ML_KEM: fix broken test: the encapsulated key is eK, not C...tb2026-01-221-2/+2
|
* ML-KEM: don't treat API failure as test failure for invalid test casestb2026-01-221-5/+11
| | | | | An update to the test vectors adds tests which verifies that the API correctly rejects some inputs.
* While almost all the libc locks are taken and released in the sameguenther2026-01-193-1/+85
| | | | | | | | | | libc call, flockfile() and ftrylockfile() can be called when single-threaded and then--while 'holding' the lock--the process can create another thread, resulting in a broken state. Have the f{lock,trylock,unlock}file() APIs *always* do real locking so the exposed state is always consistent. ok dlg@
* unusally -> unusuallytb2026-01-041-10/+10
|
* i2c_ASN1_BIT_STRING() vs ASN1_STRING_FLAG_BITS_LEFTtb2026-01-041-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A nasty quirk in the bit string handling is that the serialization produced by i2d_ASN1_BIT_STRING() depends on whether the the magic ASN1_STRING_FLAG_BITS_LEFT is set. If ASN1_STRING_FLAG_BITS_LEFT is set, the number of unused bits is carried in a->flags & 0x07 and the remainder of the bit string is in a->data. This is terrible and undocumented but handled correctly. If ASN1_STRING_FLAG_BITS_LEFT is not set, all trailing zero bits are (intended to be) chopped off with all sorts of hilarious side effects. I broke this quite thoroughly when I incorrectly ported an overflow check from BoringSSL in: https://github.com/openbsd/src/commit/f81cc285d2aed8b36615119a306533696f3eb66c The result is that we currently return ret = a->length + 1 for both NULL and non-NULL pp. The calls to asn1_ex_i2c() in asn1_i2d_ex_primitive() thus report consistent lengths back, making it succeed. asn1_i2d_ex_primitive() therefore skips a->length + 1 bytes, while i2c_ASN1_BIT_STRING() only overwrites len + 1 bytes, which are possibly fewer. So a caller passing in an output buffer containing garbage (malloc) will get some of that garbage back in the encoding. Further, i2c_ASN1_BIT_STRING() also advances that pointer by the possibly reduced len + 1, but that fortunately doesn't matter since that's an effect local to asn1_ex_i2c(), the only caller of i2c_ASN1_BIT_STRING(). The last bit is that the current behavior may set bogus unused bits coming from the scanning backward madness. I added such an example in the parent commit. The fix is simple: use len after the truncation effect was established, not the original a->length, turning this commit into what my backport should have been. This fixes the two currently failing regress tests, so remove expected failure marker again. ok jsing kenjiro
* asn1basic: add missing test from BoringSSL's test suitetb2026-01-041-1/+32
| | | | This is another test that fails due to the bug in i2c_ASN1_BIT_STRING().
* asn1basic: switch test to expect correct encodingtb2026-01-042-4/+6
| | | | This test fails, so mark the asn1basic test as an expected failure
* asn1basic: add example showing current bogus encodingtb2026-01-041-1/+38
| | | | | | There is a bug in i2c_ASN1_BIT_STRING() resulting in nonsense encoding of some BIT STRINGs with trailing zeroes if ASN1_STRING_FLAG_BITS_LEFT is not set (a rare corner case). This test currently passes when it shouldn't.
* check_complete: ASN1_LONG_UNDEF is now internaltb2026-01-021-1/+0
|
* Rename RANK{768,1024} to MLKEM{768,1024}_RANKtb2026-01-014-22/+22
| | | | | | | | | RANK768 and RANK1024 are awfully short and generic names for public constants. Before we make it worse with similarly named constants for ML-DSA, let's fix this. This follows the naming convention used by the other macros in the mlkem code. ok kenjiro jsing
* constaints -> constraintstb2025-12-311-2/+2
|
* preprended -> prependedtb2025-12-271-2/+2
|
* "SCREW_THE_PARITY is not ment to be defined."tb2025-12-261-13/+1
| | | | alright. go home.
* astrix -> asterisktb2025-12-251-2/+2
|
* wycheproof: add minimal glue for the decaps validation teststb2025-12-201-1/+8
|
* Port most of BoringSSL's TEST(ASN1Test, SetBit)tb2025-12-181-1/+425
| | | | | | | Exercises the batshit crazy truncation behavior of ASN1_BIT_STRING_set_bit() Based on https://boringssl-review.googlesource.com/c/boringssl/+/48225 (still under ISC).
* ec_asn1_test: change a comma to a full stoptb2025-12-071-2/+2
|
* asn1complex: use ASN1_STRING_get0_data() instead of ASN1_STRING_data()tb2025-12-071-4/+4
|
* check_complete: remove the BN_*FMT1 macros as welltb2025-12-051-4/+1
|
* check_complete: adjust for BN_ macro removaltb2025-12-051-5/+2
| | | | pointed out by kenjiro
* bn_word.c: include bn_local.h in preparation for an upcoming changetb2025-12-051-1/+3
|
* Hook up X25519MKLEM768 to the TLS 1.3 handshakebeck2025-12-041-27/+333
| | | | | | | | | | | | | | | | | | | | | | | | This does the following: 1) Adds a second key share prediction to the TLS 1.3 handshake. We only add one as we are unlikely to want to send more than one PQ one, and one classical one and are unlikely to waste bytes on a second PQ algorithm (anything that wants something else that we support can HRR to get it) 2) Adds X25519MLKEM768 (4588) to our list of supported groups. We add this to our preferred client and server key shares for TLS 1.3 and we now have a separate list for TLS 1.2 which does not do this, cleaning up the old "full list" from the comments. 3) Updates the golden magic numbers in the regression tests to allow for the above two things changing the handshake, so the regress tests pass. With this you can successfully hybrid PQ with servers and clients that support it. ok tb@ kenjiro@
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2026-08-27 22:43:47 +0000