summaryrefslogtreecommitdiff
path: root/src/regress (follow)
Commit message (Collapse)AuthorAgeFilesLines
* 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
|
* openssl appstest: remove to-do item for compress/uncompresstb2025-12-201-5/+1
|
* 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
|
* Make the openssh test pass after adding mlkem.beck2025-12-041-8/+9
| | | | | | | | | | This has a magic value looking for what happens when we HRR, more or less assuming it might never change. it now has. Commenting it out get us by it, unsure if we should change this or get rid of it. ok tb@
* 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@
* Add a MLKEM768_X25519 hybrid key share.beck2025-12-041-5/+5
| | | | | | | | | | | | This implements the currently in use MLKEM768_X25519 hybrid key share as outlined in https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/ This commit does not yet wire this up to anything, that is done in follow on changes. ok tb@ jsing@ kenjiro@
* 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.
* Let this compile on m88k.miod2025-11-061-1/+3
|
* 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@
* Needs <sys/param.h> for hppa.miod2025-10-311-3/+3
|
* This test takes *days* to complete on older platforms, reduce the loop countmiod2025-10-261-2/+8
| | | | for them.
* Add some regress coverage for SSL_SESSION_dup()tb2025-10-241-2/+22
| | | | ok kenjiro
* The ssl_verify_param.c test can now link dynamically against libcryptotb2025-10-241-3/+1
|
* Use X509_VERIFY_PARAM_get_hostflags() prototype from x509_vfy.htb2025-10-241-3/+2
|
* Give this test a chance to pass on 32-bit platforms.miod2025-10-201-1/+2
|
* const correct X509_VERIFY_PARAM_get_hostflags()tb2025-10-101-2/+2
| | | | | | | This is currently an internal helper only used by a regress test. We'll have to expose in the public API for Python 3.14: https://github.com/libressl/portable/issues/1202
* Revert previous. Let's deal with it when the portable release is out.tb2025-10-071-7/+3
|
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2026-02-24 11:02:18 +0000