summaryrefslogtreecommitdiff
path: root/src/regress/lib/libcrypto (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
|
* 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@
* 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
|
* 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.
* 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
|
* bn_test: avoid last use of BN_HEX_FMT1 in libressltb2025-11-151-2/+4
|
* bn_test: remove dead codetb2025-11-151-12/+1
| | | | | | We haven't defined SIXTY_FOUR_BITS in a long time, if ever. The last #undef SIXTY_FOUR_BITS were removed when we cleaned up opensslconf.h. Code behind #ifdef SIXTY_FOUR_BITS is therefore dead.
* Avoid the use of _LP64 in libcrypto regress.jsing2025-11-051-2/+2
| | | | | | | What the tests actually care about is the size of a BN_ULONG, hence condition on BN_BYTES instead. Discussed with tb@
* Revert previous. Let's deal with it when the portable release is out.tb2025-10-071-7/+3
|
* test framework: allow overriding the "/tmp/" directorytb2025-10-071-3/+7
| | | | | Windows is super picky when it comes to paths, so it needs some special massaging. Will let us avoid a patch or hack in portable.
* ec_asn1_test: add an example using BLS12-377tb2025-09-171-1/+80
| | | | | | This exercises the cofactor guessing code with a large cofactor. Thanks to Daniel Bleichenbacher for pointing out this example. This contains a hack to use a bogus OID since this curve has none.
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2026-08-28 01:11:55 +0000