summaryrefslogtreecommitdiff
path: root/src/lib/libcrypto (follow)
Commit message (Collapse)AuthorAgeFilesLines
...
* Document X509_STORE_CTX_get_chain(3).schwarze2021-07-211-5/+15
| | | | | It is deprecated, but it is still called by various application programs, so let's better mention it.
* Split X509_NAME_hash(3) out of d2i_X509_NAME(3) and documentschwarze2021-07-204-25/+102
| | | | | | | | | | X509_issuer_name_hash(3), X509_subject_name_hash(3), and the _old variants. Even though this is only tangentially related to decoding and encoding, including a single function in d2i_X509_NAME(3) was probably OK, but let's not bog down that page with six functions that are likely to become obsolete at some point - even though right now, they are still being used both internally and by external software.
* document X509_CRL_print(3) and X509_CRL_print_fp(3)schwarze2021-07-195-7/+124
|
* new manual page X509_print_ex(3)schwarze2021-07-124-5/+287
|
* Use the x509_verify_cert_cache_extensions fuction instead of manuallybeck2021-07-121-9/+4
| | | | | | | calling the OpenSSL legacy cache extensions goo. Requested by tb@ ok tb@
* document X509V3_extensions_print(3)schwarze2021-07-126-7/+112
|
* document X509V3_EXT_print(3)schwarze2021-07-125-8/+167
|
* While the traditional OpenSSL return value and behaviour of BIO_dump(3)beck2021-07-112-31/+17
| | | | | | | | | | | is pure comedy gold, and now documented as such, sadly this bit of pure Muppet genius can't really in good consience stay in the tree as is. Change BIO_dump to always return the number of bytes printed on success and to stop printing and return -1 on failure if a writing function fails. ok tb@, jsing@
* new manual page ASN1_parse_dump(3)schwarze2021-07-115-7/+222
|
* document ASN1_get_object(3)schwarze2021-07-114-5/+207
|
* Fix a read buffer overrun in X509_CERT_AUX_print(3),schwarze2021-07-101-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | which by implication also affects X509_print(3). The ASN1_STRING_get0_data(3) manual explitely cautions the reader that the data is not necessarily NUL-terminated, and the function X509_alias_set1(3) does not sanitize the data passed into it in any way either, so we must assume the alias->data field is merely a byte array and not necessarily a string in the sense of the C language. I found this bug while writing manual pages for these functions. OK tb@ As an aside, note that the function still produces incomplete and misleading results when the data contains a NUL byte in the middle and that error handling is consistently absent throughout, even though the function provides an "int" return value obviously intended to be 1 for success and 0 for failure, and even though this function is called by another function that also wants to return 1 for success and 0 for failure and even does so in many of its code paths, though not in others. But let's stay focussed. Many things would be nice to have in the wide wild world, but a buffer overflow must not be allowed to remain in our backyard.
* new manual page BIO_dump(3)schwarze2021-07-103-3/+149
|
* Add a bunch of workarond in the verifier to support partial chains andbeck2021-07-102-16/+135
| | | | | | | | | the saving of the first error case so that the "autochain" craziness from openssl will work with the new verifier. This should allow the new verification code to work with a bunch of the autochain using cases in some software. (and should allow us to stop using the legacy verifier with autochain) ok tb@
* Fix mixup between localKeyID and friendlyName.tb2021-07-091-3/+3
| | | | "please commit" schwarze
* KNF: remove whitespace between functions and parenthesestb2021-07-096-28/+28
|
* new manual page for X509_keyid_set1(3), X509_keyid_get0(3),schwarze2021-07-095-9/+184
| | | | X509_alias_set1(3), X509_alias_get0(3)
* document X509_add1_reject_object(3) and X509_reject_clear(3)schwarze2021-07-081-7/+24
|
* add new manual page for X509_add1_trust_object(3) and X509_trust_clear(3)schwarze2021-07-083-3/+87
|
* document X509_signature_dump(3) and X509_signature_print(3)schwarze2021-07-065-9/+97
|
* Fix a bug in X509_print_ex(3).schwarze2021-07-061-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | If the user set nmflags == X509_FLAG_COMPAT and X509_NAME_print_ex(3) failed, the error return value of 0 was misinterpreted as an indicator of success, causing X509_print_ex(3) to ignore the error, continue printing, and potentially return successfully even though not all the content of the certificate was printed. The X509_NAME_print_ex(3) manual page explains that this function indicates failure by returning 0 if nmflags == X509_FLAG_COMPAT and by returning -1 if nmflags != X509_FLAG_COMPAT. That's definitely atrocious API design (witnessed by the complexity of the code needed for correct error checking), but changing the API contract and becoming incompatible with OpenSSL would make matters even worse. Note that just checking for <= 0 in all cases would not be correct either because X509_NAME_print_ex(3) returns 0 to indicate that it successfully printed zero bytes in some cases, for example when all three of the following conditions hold: 1. nmflags != X509_FLAG_COMPAT 2. indent == 0 (which X509_print_ex(3) does use in some cases) 3. the name object is NULL or empty I found the bug by code inspection and proposed an incomplete patch, then jsing@ proposed this improved version of the patch. OK jsing@.
* document i2a_ASN1_OBJECT(3)schwarze2021-07-051-8/+61
|
* document X509_find_by_subject(3) and X509_find_by_issuer_and_serial(3)schwarze2021-07-043-3/+74
|
* Bugfix: when X509_NAME_dup(3) failed, X509_NAME_set(3) indicated successschwarze2021-07-041-14/+8
| | | | | | | | | | | | | | | | | even though it did not actually set the name. Instead, indicate failure in this case. This commit sneaks in a small, unrelated change in behaviour. If the first argument of X509_NAME_set(3) was NULL, the function used to return failure. Now it crashes the program by accessing the NULL pointer, for compatibility with the same change in OpenSSL. This merges the following two commits from the OpenSSL-1.1.1 branch, which is still available under a free license: 1. 180794c5 Rich Salz Sep 3 11:33:34 2017 -0400 2. c1c1783d Richard Levitte May 17 09:53:14 2018 +0200 OK tb@
* Document X509_NAME_set(3).schwarze2021-07-031-3/+41
| | | | | | It is not particularly well-designed and sets a number of traps for the unwary, but it is a public API function in both OpenSSL and LibreSSL and used at various places.
* Document the read-only (sic!) accessor function X509_NAME_ENTRY_set(3).schwarze2021-07-021-9/+77
| | | | | While here, stress that X509_NAME objects cannot share X509_NAME_ENTRY objects, and polish a few misleading wordings.
* Add a roff comment saying that X509_certificate_type(3) is intentionallyschwarze2021-07-021-2/+5
| | | | | | undocumented. It is archaic and practically unused and unusable. tb@ and jsing@ agree with marking it as undocumented. Put the comment here because EVP_PKEY_base_id(3) is a viable alternative.
* call the API function X509_NAME_cmp(3) instead of the obsolete,schwarze2021-07-021-2/+2
| | | | | | undocumented macro alias X509_name_cmp(3); no change to the assembler code generated by the compiler; OK tb@
* Add a roff comment saying that X509_name_cmp(3) is intentionallyschwarze2021-07-021-2/+4
| | | | | undocumented because it is almost unused in real-world code. OK tb@
* document and deprecate the macros X509_extract_key(3)schwarze2021-06-301-6/+35
| | | | and X509_REQ_extract_key(3), using feedback from tb@ and jsing@
* space between macro args and punctuation;jmc2021-06-121-3/+3
|
* space between RFC and number;jmc2021-06-111-3/+3
|
* sync cert.pem with Mozilla's CA list generated from certdata.txtsthen2021-06-111-476/+163
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (certificates with the "server auth" trust purpose permitted). ok tb@ -AC Camerfirma S.A. - /C=EU/L=Madrid (see current address at www.camerfirma.com/address)/serialNumber=A82743287/O=AC Camerfirma S.A./CN=Chambers of Commerce Root - 2008 - /C=EU/L=Madrid (see current address at www.camerfirma.com/address)/serialNumber=A82743287/O=AC Camerfirma S.A./CN=Global Chambersign Root - 2008 - FNMT-RCM /C=ES/O=FNMT-RCM/OU=AC RAIZ FNMT-RCM + /C=ES/O=FNMT-RCM/OU=Ceres/2.5.4.97=VATES-Q2826004J/CN=AC RAIZ FNMT-RCM SERVIDORES SEGUROS -GeoTrust Inc. - /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA - /C=US/O=GeoTrust Inc./OU=(c) 2007 GeoTrust Inc. - For authorized use only/CN=GeoTrust Primary Certification Authority - G2 - GlobalSign nv-sa + /C=BE/O=GlobalSign nv-sa/CN=GlobalSign Root E46 + /C=BE/O=GlobalSign nv-sa/CN=GlobalSign Root R46 /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA Staat der Nederlanden /C=NL/O=Staat der Nederlanden/CN=Staat der Nederlanden EV Root CA - /C=NL/O=Staat der Nederlanden/CN=Staat der Nederlanden Root CA - G3 Unizeto Technologies S.A. /C=PL/O=Unizeto Technologies S.A./OU=Certum Certification Authority/CN=Certum Trusted Network CA + /C=PL/O=Unizeto Technologies S.A./OU=Certum Certification Authority/CN=Certum Trusted Network CA 2 - -VeriSign, Inc. - /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2008 VeriSign, Inc. - For authorized use only/CN=VeriSign Universal Root Certification Authority (Note, "Staat der Nederlanden Root CA - G3" was changed to email trust only, so is removed from this due to it only listing "server auth" purposes).
* Fix pkg-config .pc files with LibreSSLinoguchi2021-06-081-2/+2
| | | | | | | | In libssl.pc, Libs: should not have '-lcrypto', and Requires.private: should have it as 'libcrypto'. openssl.pc does not need Libs: and Cflags:, but should have Requires:. OK millert@
* EVP_Digest*: fix documented return values.tb2021-05-202-10/+6
| | | | | | | | | | EVP_DigestSign{,Init,Update,Final}() and EVP_DigestVerify{Init,Update}() always returned 1 for success and 0 for failure. EVP_DigestVerify() and EVP_DigestVerifyFinal() can return -1 or -2, though. Based on OpenSSL 1.1.1 56c59ddd99da05c2f30832cccaffb873a8481555 ok inoguchi
* Adjust libcrypto obj_xref.txt to obj_xref.hinoguchi2021-05-191-2/+2
| | | | | | | | | | | | To generate current obj_xref.h, third item of lines id_tc26_signwithdigest_gost3410_2012_256/512 should be id_GostR3410_2001. obj_xref.txt r1.2 and obj_xref.h r1.3 were committed at the same time, and these third item were coded different value each other. This adjusts obj_xref.txt to current obj_xref.h. ok tb@
* whitespace/KNFtb2021-05-141-4/+4
|
* Improve libcrypto obj_xref.h generatorinoguchi2021-05-141-0/+4
| | | | | | | Modify objxref.pl to output $OpenBSD$ header and __BEGIN_HIDDEN_DECLS / __END_HIDDEN_DECLS . ok and comment from tb@
* Add missing .Pp in HISTORY section.tb2021-05-132-4/+6
|
* Add missing .Pptb2021-05-131-2/+3
|
* Add obj_xref for ECDH schemes in RFC 5753inoguchi2021-05-122-1/+34
| | | | | | | | | | Found missing sigoid_srt record in crypto/objects/obj_xref.h, and this causes error while executing openssl cms -encrypt with EC key/cert. Added required definitions to obj_xref.txt and obj_xref.h. Issue reported by Theodore Wynnychenko (tmw <at> uchicago.edu) on misc. ok tb@
* Merge some details from OpenSSL 1.1.1.tb2021-05-112-6/+24
|
* missing word in previoustb2021-05-111-1/+2
|
* Merge documentation for EVP_DigestVerify() from OpenSSL 1.1.1.tb2021-05-111-4/+37
|
* Merge documentation for EVP_DigestSign from OpenSSL 1.1.1.tb2021-05-111-4/+39
|
* zap stray commatb2021-05-111-3/+3
|
* Merge documentation for EC_GROUP_{set,get}_curve(3) from OpenSSL 1.1.1.tb2021-05-101-20/+57
|
* Merge documentation for EC_POINT_{get,set}_coordinates andtb2021-05-101-20/+70
| | | | for EC_POINT_set_compressed_coordinates from OpenSSL 1.1.1.
* bump libcrypto minor after symbol additiontb2021-05-101-1/+1
|
* Expose EVP_Digest{Sign,Verify}(3)tb2021-05-102-5/+3
| | | | ok jsing
* Expose EC_POINT_{get,set}_affine_coordinates(3) andtb2021-05-102-7/+11
| | | | | | EC_POINT_set_compressed_coordinates(3) ok jsing
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-03-22 03:04:02 +0000