summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Rewrite X509_ALGOR_set0()tb2023-10-111-17/+13
| | | | | | | | | | | | | | | | | | | | The current implementation is a complete mess. There are three cases: 1) ptype == V_ASN1_UNDEF: parameter must be freed and set to NULL. 2) ptype == 0: existing non-NULL parameters are left untouched, NULL parameters are replaced with ASN1_TYPE_new()'s wacky defaults. 3) otherwise allocate new parameters if needed and set them to ptype/pval. In all three cases free the algorithm and set it to aobj. The challenge now is to implement this using nine if statements and one else clause... We can do better. This preserves existing behavior. There would be cleaner implementations possible, but they would change behavior. There are many callers in the ecosystem that do not error check X509_ALGOR_set0() since OpenSSL failed to do so. So this was carefully rewritten to leave alg in a consisten state so that unchecking callers don't encounter corrupted algs. ok jsing
* x509_algor: Turn expected failure into actual failure now that the API istb2023-10-111-3/+3
| | | | fixed.
* Ensure that out_value is initialized even if out_type is NULLtb2023-10-111-1/+5
| | | | | | This fixes the printf in the x509_algor regress. ok jsing
* Rewrite X509_ALGOR_get0()tb2023-10-111-13/+19
| | | | | | | | Make the logic slightly less convoluted. Preserve the behavior that *ppval remains unset if pptype == NULL for now. However, ensure that *ppval is set to NULL if pptype is V_ASN1_UNDER. ok jsing
* Add internal version of X509_ALGOR_set_md()tb2023-10-112-7/+17
| | | | | | | | | | | | | | | | | | | X509_ALGOR_set_md() is a void function that cannot easily be error checked. The caller has to jump through hoops to make sure this function doesn't fail. Prepare replacing this internally with X509_ALGOR_set_evp_md(), which allows error checking. There is one slight change of behavior: if the EVP_MD object passed in does not have an OID known to the library, then this new API fails. It is unclear what the library should do with such an object and people who use EVP_MD_meth_new() need to know what they are doing anyway and they are better off teaching the lib about the OID if they're going to be messing with certs. Oh, and the prototype is in x509_local.h because the rest of this API is in x509.h despite being implemented in asn1/. ok jsing
* Add preallocation dance for X509_ALGOR_set_md() as documentedtb2023-10-111-1/+5
|
* Clean up X509_ALGOR_cmp()tb2023-10-111-10/+10
| | | | | | | This is currently written in what is likely the most stupid way possible. Rewrite this function in a more straightforward way. ok jsing
* Add regress coverage for X509_ALGOR_*tb2023-10-112-2/+377
| | | | | | | | | This covers the setters and getters. Serialization and deserialization as well as comparison is already well covered by the pieces of regress using certs. There is currently one printf indicating failure. This will be fixed shortly.
* I forgot that we now have ASN1_INTEGER_set_uint64()tb2023-10-111-13/+6
|
* Be more precise about X509_ALGOR_get0()tb2023-10-111-11/+26
|
* Improve X509_ALGOR_new(3) documentationtb2023-10-101-14/+33
| | | | | | | | | | | | | | | The previous wording was misleading since the result of X509_ALGOR_new() is not actually an empty X509_ALGOR object. Rather, it contains the undefined ASN1_OBJECT returned by OBJ_nid2obj(NID_undef). Therefore using X509_ALGOR_get0(3) for error checking X509_ALGOR_set_md() is not trivial. So: change the initial paragraph into a general intro referring to the OpenSSL API needed to interface with X509_ALGOR and write a new paragraph documenting X509_ALGOR_new(3) and drop the incorrect suggestion of an error check. Notably there's now a reference to the OBJ_nid2obj() family without which one cannot really use X509_ALGOR_* for anything at all. With and ok schwarze
* Use the usual text for X509_ALGOR_free()tb2023-10-091-2/+8
|
* Clarify that 'undefined type' means V_ASN1_UNDEFtb2023-10-091-3/+4
|
* Clarify documentation of X509_ALGOR_{set0,set_md}()tb2023-10-091-7/+45
| | | | | | | | | | | | | | | The X509_ALGOR_set0() and X509_ALGOR_set_md() documentation comes from upstream, which means it is as sloppy as the code and as vague as your average upstream manpage. Be precise on what X509_ALGOR_set0() does on different inputs and document return values and failure modes. X509_ALGOR_set_md() is a void function that calls X509_ALGOR_set0() in a way that can fail, leaving alg in a corrupted state. Document when that can occur and how to avoid or detect that, but do not go too far, because EVP_MD_meth_new(), one potential source of failures, is a whole another can of worms. joint work with schwarze
* Add regress coverage for ASN1_UTCTIME_cmp_time_t()tb2023-10-051-5/+12
|
* Fix a typo and move a wordtb2023-10-031-5/+5
|
* Add some coverage for ASN1_TIME_cmp_time_t() as welltb2023-10-021-1/+14
| | | | | ASN1_UTCTIME_cmp_tim_t() could be done similarly, but then I have to mess with LIBRESSL_INTERNAL. Let's do this after unlock.
* Add regress coverage for ASN1_TIME_compare()tb2023-10-021-1/+78
|
* Minor asn1time tweakstb2023-10-021-26/+12
| | | | Sprinkle some (static) const and garbage collect an unused struct.
* Example code tweak: do not hardcode the size of arraytb2023-10-011-2/+2
|
* Fix a copy-paste bug in ASN1_TIME_compare()tb2023-10-011-2/+2
| | | | | | | | | | | | | | | | | | | | | | | ASN1_TIME_compare() compares two times t1 and t2. Due to a copy-paste error, we would do ASN1_time_parse(t1->data, t2->length, &tm2, t2->type) Now if t1 is a UTCTime (length 13) and t2 is a GeneralizedTime (length 15), the worst that could happen is a 2-byte out-of-bounds read. Fortunately, t1 will already have parsed as a UTCTime, so it will have a Z where there should be the first digit of the seconds for a GeneralizedTime and we will error out. Now if both t1 and t2 have the same type, we will parse t1's data twice and we will return an incorrect comparison. This could have some security impact if anything relied on this function for security purposes. It is unused in our tree and unused in our ports tree ports and the only consumer I could find was some MongoDB things doing OCSP, so this won't be too bad. Then of course there's also the language bindings. Issue reported by Duncan Thomson at esri dot com via libressl-security ok beck deraadt
* Document EVP_CIPHER_CTX_iv_length() return valuestb2023-10-011-3/+7
| | | | | | | | | | | | We aligned with upstream behavior. Let's document it properly. Surprisingly, OpenSSL 1.1 half-assed the docs: two parts of the manual contradict each other. The part getting EVP_CIPHER_CTX_iv_length() right, incorrectly documents possible -1 return value to EVP_CIPHER_iv_length(). OpenSSL 3 documentation improvement efforts seem to have tried to address this issue with the result that the manual is now entirely wrong when it comes to the EVP_CIPHER_CTX_iv_length() replacement. Par for the course.
* The colons separate the octets, not the digits; add missing link totb2023-10-011-4/+5
| | | | crypto(3)
* Improve a code comment in the EXAMPLES sectiontb2023-10-011-3/+3
|
* Refer to RFC 3779, 2.1.2 for encoding of rangestb2023-10-011-2/+7
| | | | Mention sections 2.1.1 and 2.1.2 in STANDARDS
* Point out that the result of IPAddressRange_new() is an invalid rangetb2023-10-011-3/+3
| | | | since it should be a prefix.
* encoding -> decoding for d2itb2023-10-011-3/+3
|
* Add an empty linetb2023-10-011-1/+2
|
* Reorder list of additional validation checks neededtb2023-09-301-9/+8
|
* Switch copyright year to 2023.tb2023-09-302-4/+4
| | | | | | | Apparently I should have used 2023 despite sharing versions of these files with several people under this license (and thus permitting them to redistribute and share with the public). It makes no sense to me, but shrug.
* Use addrblocks for .Fatb2023-09-301-2/+2
|
* avoid using the string "a" without markup as a placeholderschwarze2023-09-301-4/+9
| | | | | where that feels potentially confusing, and add one missing .Pp macro; no change of meaning
* consistently use "allow_inherit" for the argument nameschwarze2023-09-301-6/+6
| | | | and fix whitespace on one text line; no change of meaning
* drop one pair of needless parenthesesschwarze2023-09-301-5/+5
| | | | and polish one wording; no change of meaning
* remove a useless repetition of a function nameschwarze2023-09-301-6/+4
| | | | | that was also followed by a bogus argument, and fix one grammatical error; no change of meaning
* polish an awkward wordingschwarze2023-09-301-9/+7
| | | | | and capitalize "AFI" where is does not refer to the function argument; no change of meaning
* two instances of missing .Fa macrosschwarze2023-09-301-13/+15
| | | | and some missing escaping of HYPHEN-MINUS; no text change
* fix one copy and paste error: d2i_*() decode rather than encode;schwarze2023-09-301-7/+7
| | | | plus some minor markup and punctuation fixes
* garbage collect two stray words, no change of meaningschwarze2023-09-301-4/+4
|
* Allow IP addresses to be specified in a URI.beck2023-09-293-19/+70
| | | | | | | | | | | | Our checking here was a bit too aggressive, and did not permit an IP address in a URI. IP's in a URI are allowed for things like CRLdp's AIA, SAN URI's etc.). The check for this was also slightly flawed as we would permit an IP if memory allocation failed while checking for an IP. Correct both issues. ok tb@
* Some wording tweaks to make things a bit more precise.tb2023-09-291-6/+7
|
* Fix a wrong tag and work around an ugly linebreaktb2023-09-291-5/+6
|
* Document X509v3_{addr,asid}_validate_{path,resource_set}(3)tb2023-09-296-10/+217
| | | | | | | These were the last four RFC 3779 things that check_complete.pl x509v3 complained about. I will surely tweak and try to improve a few things in the coming days, but the pages should now be stable enough that review efforts will likely not be wasted. Any feedback appreciated.
* Appease coveritytb2023-09-291-2/+4
| | | | This is a static pointer, so it ain't ever NULL, but shrug
* Fix error messagetb2023-09-281-2/+2
|
* Don't leak ctx on failuretb2023-09-281-3/+2
|
* Document X509v3_{addr,asid}_subset.3 take two (missed cvs add)tb2023-09-281-0/+176
| | | | | | First RFC 3779 page without a BUG section. It could have one, but I'm in a lenient mood right now. Maybe it's just that this is bad but not quite as bad as EVP.
* Document X509v3_{addr,asid}_subset.3tb2023-09-287-30/+40
| | | | | | First RFC 3779 page without a BUG section. It could have one, but I'm in a lenient mood right now. Maybe it's just that this is bad but not quite as bad as EVP.
* Add more regress coverage for EVP_CIPHER_CTX_iv_length()tb2023-09-281-1/+268
| | | | | | | Awesome: the IV length for GCM is only bounded by INT_MAX or malloc limits. In the absence of an overflowing issue tracker, I'm labeling this "good first issue", "help wanted" here.
* Check that EVP_CIPHER_CTX_iv_length() matches what was settb2023-09-281-1/+9
| | | | | | This really only covers AES-GCM. From beck
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-03-28 22:17:41 +0000