summaryrefslogtreecommitdiff
path: root/src/lib/libcrypto/x509/x509_vpm.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Prepare to provide X509_VERIFY_PARAM_get_time()tb2022-07-041-1/+7
| | | | ok jsing sthen
* Prepare to provide X509_VERIFY_PARAM_set_auth_level()tb2022-06-271-1/+7
| | | | | | | | For some unknown reason this needed a different name than security_level, both internally and in the public API. Obviously it is exactly the same garbage. ok beck jsing
* Move the now internal X.509-related structs into x509_lcl.h.tb2021-11-011-1/+2
| | | | | | | | Garbage collect the now unused LIBRESSL_CRYPTO_INTERNAL and LIBRESSL_OPAQUE_X509. Include "x509_lcl.h" where needed and fix a couple of unnecessary reacharounds. ok jsing
* Enable X509_V_FLAG_TRUSTED_FIRST by default in the legacy verifier.jsing2021-09-301-1/+2
| | | | | | | | | | | | In order to work around the expired DST Root CA X3 certficiate, enable X509_V_FLAG_TRUSTED_FIRST in the legacy verifier. This means that the default chain provided by Let's Encrypt will stop at the ISRG Root X1 intermediate, rather than following the DST Root CA X3 intermediate. Note that the new verifier does not suffer from this issue, so only a small number of things will hit this code path. ok millert@ robert@ tb@
* Enable the new verifier again so hopefully the remaining kinks get ironedtb2021-04-241-2/+2
| | | | | | out in this release cycles. discussed with deraadt and jsing
* Switch back to the legacy verifier for the release.tb2021-04-151-2/+2
| | | | | | | | | | | This is disappointing as a lot of work was put into the new verifier during this cycle. However, there are still too many known bugs and incompatibilities. It is better to be faced with known broken behavior than with new broken behavior and to switch now rather than via errata. This way we have another cycle to iron out the kinks and to fix some of the remaining bugs. ok jsing
* Don't leak param->name in x509_verify_param_zero()tb2021-04-051-1/+2
| | | | | | | | | For dynamically allocated verify parameters, param->name is only ever set in X509_VERIFY_set1_name() where the old one is freed and the new one is assigned via strdup(). Setting it to NULL without freeing it beforehand is a leak. looks correct to millert, ok inoguchi
* Fix some KNF issuestb2020-12-161-7/+8
|
* re-enable new x509 chain verifier as the defaultbeck2020-09-141-3/+1
| | | | ok tb@
* revert previous, need to fix a problembeck2020-09-141-1/+3
|
* Enable the use of the new x509 chain validator by default.beck2020-09-141-3/+1
| | | | ok jsing@ tb@
* Add new x509 certificate chain validator in x509_verify.cbeck2020-09-131-1/+3
| | | | | | | | | | | | | | | | | | | The new validator finds multiple validated chains to handle the modern PKI cases which may frequently have multiple paths via different intermediates to different roots. It is loosely based on golang's x509 validator This includes integration so that the new validator can be used via X509_verify_cert() as well as a new api x509_verify() which will return multiple chains (similar to go). The new validator is not enabled by default with this commit, this will be changed in a follow on commit. The new public API is not yet exposed, and will be finalized and exposed with a man page and a library minor bump later. ok tb@ inoguchi@ jsing@
* poison for X509_VERIFY_PARAM'sbeck2018-04-061-27/+42
| | | | | | | | | | | | Tighten up checks for various X509_VERIFY_PARAM functions, and allow for the verify param to be poisoned (preculding future successful cert validation) if the setting of host, ip, or email for certificate validation fails. (since many callers do not check the return code in the wild and blunder along anyway) Inspired by some discussions with Adam Langley. ok jsing@
* Call strlen() if name length provided is 0, like OpenSSL does.beck2018-03-221-1/+3
| | | | | Issue notice by Christian Heimes <christian@python.org> ok deraadt@ jsing@
* Please variable decl before code.deraadt2017-12-091-2/+2
|
* Remove prototypes from the public header for X509_VERIFY_PARAM functionsjsing2016-12-211-1/+6
| | | | | | that were recently added but not intended to be made public at this stage. Discussed with beck@
* Commit a reminder that the default is not the default. This needs tobeck2016-11-061-1/+2
| | | | | be revisited. ok jsing@
* use the correct function for freebcook2016-11-061-2/+2
| | | | ok beck@
* Part one of the alt chains changes, bring in newer modifications tobeck2016-11-051-69/+311
| | | | | VERIFY_PARAMS - based on boringssl. ok jsing@ miod@
* X509_VERIFY_PARAM_set1_name(): if invoked with NULL as the secondmiod2014-09-291-1/+2
| | | | | parameter, correctly set param->name to NULL after having freed it. ok bcook@
* Kill a bunch more BUF_strdup's - these are converted to have a check forbeck2014-07-221-2/+4
| | | | | NULL before an intrinsic strdup. ok miod@
* Only import cryptlib.h in the four source files that actually need it.jsing2014-07-111-3/+2
| | | | | | | | Remove the openssl public includes from cryptlib.h and add a small number of includes into the source files that actually need them. While here, also sort/group/tidy the includes. ok beck@ miod@
* Stop including standard headers via cryptlib.h - pull in the headers thatjsing2014-07-101-1/+2
| | | | | | are needed in the source files that actually require them. ok beck@ miod@
* tags as requested by miod and teduderaadt2014-06-121-1/+1
|
* no need for null check before free. from Brendan MacDonelltedu2014-05-301-2/+1
|
* calloc instead of malloc/memset. from Benjamin Baiertedu2014-05-251-2/+1
|
* KNF.jsing2014-04-201-75/+96
|
* blunt force knftedu2014-04-181-73/+62
|
* Change library to use intrinsic memory allocation functions instead ofbeck2014-04-171-3/+3
| | | | | | | | OPENSSL_foo wrappers. This changes: OPENSSL_malloc->malloc OPENSSL_free->free OPENSSL_relloc->realloc OPENSSL_freeFunc->free
* import OpenSSL-1.0.0adjm2010-10-011-10/+18
|
* import of OpenSSL 0.9.8kdjm2009-04-061-3/+13
|
* import openssl-0.9.8jdjm2009-01-091-1/+1
|
* import of OpenSSL 0.9.8hdjm2008-09-061-0/+420
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-08-26 21:39:24 +0000