summaryrefslogtreecommitdiff
path: root/src (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Garbage collect .group_init()tb2025-01-013-37/+3
| | | | | | | | For both in-tree methods these are just complicated ways of zeroing part of the group object. The group is allocated with calloc(), so it's all entirely pointless. ok jsing
* Use the shorthand p rather than &group->p in one more placetb2025-01-011-2/+2
|
* NID_sxnet and NID_proxyCertInfo are no longer supportedtb2024-12-311-7/+2
| | | | The code supporting it was removed in April 2023.
* Zap extraneous -DLIBRESSL_INTERNALtb2024-12-291-2/+1
|
* Prefer the constants EVP_CTRL_AEAD_* over EVP_CTRL_CCM_* and EVP_CTRL_GCM_*schwarze2024-12-292-12/+110
| | | | | | | | | | | | | | because that's what OpenSSL 1.1 suggests. Even though that "unification" doesn't really simplify anything but is more akin to repainting the bikeshed, at least it doesn't cause any additional harm, so keeping recommendations consistent may reduce the risk of code breaking in the future. Provide an example of decryption with AES-CCM in addition to the example of encryption already in place, because there are a number of subtle and non-obvious differences that users have to pay attention to. Both ideas originally suggested by tb@.
* Remove flags argument from obj_bsearch_ex()tb2024-12-281-9/+5
| | | | | | | | | The only caller passes in OBJ_BSEARCH_FIRST_VALUE_ON_MATCH, so the condition involving this flag is always true. On the other hand, while OBJ_BSEARCh_VALUE_ON_NOMATCH is left unset hence the condition involving this flag is also true (since negated). ok jsing
* stack: inline internal_find() in sk_find()tb2024-12-281-10/+4
| | | | | | | internal_find() was a generalization needed for sk_find_ex(), which was removed a while ago. ok jsing
* Document X509V3_ADD_OP_MASK and clarify the description of the flags argument.schwarze2024-12-281-5/+31
| | | | | While here, also add a (c) line for tb@ because he added Copyright-worthy amounts of text to this page during the last two years.
* Document X509_supported_extension(3).schwarze2024-12-281-6/+28
| | | | | | The sentence about X509_EXTENSION_get_critical(3) in the DESCRIPTION contained broken grammar or at least broken punctuation, and more importantly, redundant and misplaced information. While he, shorten it.
* Document X509V3_EXT_print_fp(3).schwarze2024-12-281-28/+67
| | | | | Sort the list of decoding functions alphabetically by extension type. List the printing functions that are already documented.
* new manual page a2i_ipadd(3) written from scratchschwarze2024-12-276-11/+157
|
* parse test file: add helper to skip to end of linetb2024-12-271-8/+12
|
* OpenSSL 1.1 is dead. Make this optionally use 3.3 instead.tb2024-12-271-4/+4
|
* Plug a bunch of leaks in the PKCS 12 codetb2024-12-261-8/+24
| | | | | | | The competition whether the code or the standard it implements is worse is still ongoing, and still has two strong competitors... ok jsing
* Error check sk_push() in crl2p7tb2024-12-261-23/+21
| | | | | | | also remove a few NULL checks before free and drop a cryptic comment about not needing to free x - hard to free what's not there... ok jsing
* Fix the unittest with Emscriptentb2024-12-261-5/+26
| | | | | | Split main into two helper functions since having a few ML-KEM key blobs on the stack makes Emscripten's stack explode, leading to inscrutable silent failures unles ASAN is enabled. Go figure.
* mlkem iteration test: drop extraneous typedeftb2024-12-261-4/+1
|
* mlkem tests: whitespace tweak and fix an error messagetb2024-12-261-5/+7
|
* fat fingerstb2024-12-261-2/+2
|
* Overhaul ML-KEM regress once moretb2024-12-2620-2571/+2110
| | | | | | | | | | | | | | | | | | | | | | Implement a file parser that drives a state machine to extract the test data from the .txt files and manages the parsed data. Comments and empty lines are ignored. The code currently assumes that instruction lines are at the start of the file (which isn't generally true) and only supports two line types for now. This is good enough for all the ML-KEM tests but should be easy enough to extend. Once all data for a test case is parsed in the expected order, a test handler is called which can retrieve the test data via a simple API and throw warnings and errors with information on the test case line number, etc. Merge the tests into three programs: one parsing the .txt files and running the corresponding test cases, a unit test and the iteration tests. Deduplicate the actual test code and let the caller pass in an object containing the API functions, private keys and arrays that need to be different between the 768 version and the 1024 version. This way we don't have two sets of half a dozen .c files differing only in 3 or 4 occurrences of 768 and 1024. All this will also make it a lot easier to hook these tests into portable.
* Remove disabled code supporting elliptic curves of small ordertb2024-12-241-1014/+1
| | | | ok jsing
* Remove already disabled tests for elliptic curves of small ordertb2024-12-243-880/+3
|
* Tweak doc comment of _X509_CHECK_FLAG_DOT_SUBDOMAINStb2024-12-241-4/+3
| | | | | Now that it lives in a .c file, there's no need to point out that it is non-public...
* new manual page v2i_ASN1_BIT_STRING(3) written from scratchschwarze2024-12-246-11/+141
|
* Internal linkage for one constant struct where that was accidentallyschwarze2024-12-241-2/+2
| | | | | | | | | forgotten in rev. 1.3 on July 13 this year. No library bump and no ABI change because libcrypto.so.55.0 did not export the symbol because it wasn't in Symbols.list. Found in a partial code audit focusing on X509V3_EXT_METHOD objects.
* ealier -> earlierjsg2024-12-231-4/+4
|
* Move _X509_CHECK_FLAG_DOT_SUBDOMAINS to x509_utl.ctb2024-12-232-9/+9
| | | | | | | | Unclear why this ever had to be made public since it's only used in a single file. Anyway, nothing uses this, so remove it. This went through a full bulk pointed out by/ok schwarze
* Remove the EXT_* table building macrostb2024-12-231-19/+1
| | | | | | | | These were used in x509_bitst.c and x509_ia5.c for populating tables that have been expanded a long time ago. Nothing uses them, so remove them. This went through a full bulk pointed out by/ok schwarze
* Annotate ENUMERATED_NAMES for potential removaltb2024-12-231-1/+2
| | | | | Only security/xca uses it for no good rean. It can use BIT_STRING_BITNAME if it really needs to.
* Remove X509V3_EXT_{DYNAMIC,CTX_DEP}tb2024-12-231-4/+2
| | | | | | | | | | LibreSSL has removed support for dynamically allocated custom extension methods. The mysterious CTX_DEP define was part of an experimental code dump and that part of the experimental code was never shown hence never reviewed. This went through a full amd64 bulk noticed by/ok schwarze
* Fix the error handling in X509V3_parse_list(3); it ignored failuresschwarze2024-12-231-6/+9
| | | | | | | | | | | | | of the internal subroutine X509V3_add_value(), which could result in silently losing part of the input data on memory exhaustion. I independently rediscovered this bug while writing the documentation, then noticed after fixing it that Zhou Qingyang <zhou1615 at umn dot edu> fixed it in essentially the same way in OpenSSL 3 (commit bcd5645b on Apr 11 02:05:19 2022 +0800), but it wasn't backported to the OpenSSL 1.1.1 branch. OK tb@
* new manual page X509V3_parse_list(3) written from scratchschwarze2024-12-232-1/+102
|
* Tweak previous wording a bit to avoid suggesting all built-in nidstb2024-12-231-2/+2
| | | | | | correspond to an extension method. ok schwarze
* more precision below CAVEATSschwarze2024-12-231-3/+5
|
* Make the description of i2s_ASN1_ENUMERATED_TABLE(3) more precise,schwarze2024-12-231-9/+12
| | | | | fix the name of its last parameter in the SYNOPSIS to match the DESCRIPTION, and let the .Dt argument match the file name.
* mark six #define'd constants as intentionally undocumentedschwarze2024-12-221-2/+7
|
* Add an EXAMPLES section.schwarze2024-12-211-2/+129
| | | | | | | | | | | | | | | | I admit this is unusually long for a manual page. But that's not my fault as a documentation author. An example in a manual page ought to be minimal to show what needs to be demonstrated, and this example is minimal in that sense. Making it shorter without loosing important aspects does not seem possible. When an API is poorly designed, one of the consequences is that that documentation becomes harder to understand and often longer - in this case to the point of becoming outright intimidating. If people dislike that, they should design better APIs in the first place rather than blasting the poor manual page for being too long or too complicated. OK tb@
* If EVP_CIPHER_CTX_ctrl(3) is called on EVP_chacha20_poly1305(3)schwarze2024-12-201-2/+2
| | | | | | | | | | | | | | | | | | | | | | | with an unsupported control command, return -1 rather than 0 to the caller to indicate the error because in general, these control hooks ought to return -1 for unsupported control commands and 0 for other errors, for example other invalid arguments. Not a big deal because this change does not change when operations succeed or fail, and because callers are unlikely to pass unsupported control commands in the first place. The only functional change is that if a calling program inspects the ERR(3) stack after this failure, it will now find the correct error code rather than nothing. Even that wasn't a huge problem because for most EVP_CIPHER control failures, getting no reason for the error is the usual situation. Then again, giving the reason when easily possible may occasionally be useful. OpenSSL also returns -1 in this case, so it also helps compatibility a tiny bit. Found while auditing the return values of all the EVP_CIPHER control hooks in our tree. This was the only fishy one i found. OK tb@
* mlkem regress: garbage collect two global variablestb2024-12-201-4/+1
|
* hidden mlkem.h: add comment to #endiftb2024-12-201-2/+2
|
* Annotate yet another greasy stinky tentacle of xcatb2024-12-201-1/+2
| | | | I'm so tired of this.
* Move the horrific EVP_aes_128_ccm(3) API out of the important,schwarze2024-12-204-75/+357
| | | | | | | | | | | | algorithm-independent EVP_EncryptInit(3) manual as another step in making the latter leaner and more palatable. As a side benefit, the new EVP_aes_128_ccm(3) manual page may provide a better fighting chance to programmers who see themselves forced to support CCM for whatever reason. It documents the mandatory, but so far undocumented EVP_CTRL_CCM_GET_TAG control command and makes the description of the three EVP_CTRL_CCM_SET_* control commands and the numerous related quirks more precise.
* Fix whitespace in Makefiletb2024-12-201-22/+22
|
* That works better with a Gtb2024-12-201-2/+2
|
* cant't -> can'ttb2024-12-2010-20/+20
| | | | (the mystery of spotting typos right after commit strikes again)
* Rework and fix the mlkem teststb2024-12-2016-997/+1824
| | | | | | | | | | | | | | | | | Make proper use of CBB and CBS. If a CBS ever owns data, you're holding it wrong. Ditch gross macros, sscanf, and globals. The use of fgets is annoying here, so replace it with getline, which be provided by portable if needed. Most importantly, make the tests actually signal failure rather than only printing an error. Fix the state machines in a few of them. Some tests didn't parse the .txt file at all. Others mostly did but didn't actually test what they were supposed to be testing. Such failures were hidden by the way the tests were written. This basically needed a complete revamp. It still isn't pretty and much of it could be deduplicated, but I only have so much time alotted on this blue planet.
* Do not install mlkem.h and bytestring.h into /usr/include/openssl for nowtb2024-12-191-3/+1
| | | | | | More work in mlkem is needed and this was premature. discussed with beck and jsing
* #ifdef out the inclusion of openssl/mlkem.h for nowtb2024-12-191-3/+4
| | | | discussed with beck and jsing
* Do not assume mlkem.h and bytestring.h are public in libcryptotb2024-12-194-14/+8
| | | | | | | As long as is not quite clear what we want to do about the public API aspect of MLKEM, keep things internal for now. discussed with beck and jsing
* mlkem regress: reach around into bytestring againtb2024-12-191-1/+2
|
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-03-27 14:23:24 +0000