summaryrefslogtreecommitdiff
path: root/src/lib/libcrypto/man/d2i_X509_NAME.3 (follow)
Commit message (Collapse)AuthorAgeFilesLines
* .Lb libcrypto ; OK tb@schwarze2025-06-081-2/+3
|
* const correct d2i_* prototypestb2025-03-141-4/+4
|
* two more "the the" fixes;jmc2021-12-111-3/+3
|
* Split X509_NAME_hash(3) out of d2i_X509_NAME(3) and documentschwarze2021-07-201-22/+3
| | | | | | | | | | 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_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.
* found a complete archive of SSLeay-0.4 to SSLeay-0.8.1b tarballsschwarze2018-03-271-5/+8
| | | | on the web, so fix up SSLeay HISTORY accordingly
* finish crypto HISTORY; mostly 1.1.0/6.3, but also various other fixesschwarze2018-03-231-2/+6
|
* x509.h HISTORY up to SSLeay 0.8.1b; researched from OpenSSL gitschwarze2018-03-211-2/+13
|
* In x509.h rev. 1.32 2018/02/20 17:09:20, jsing@ providedschwarze2018-02-221-5/+28
| | | | | | | | X509_NAME_get0_der(3). Document it without using anything from the existing OpenSSL X509_NAME_get0_der(3) manual page because that page fails to mention the similarity to i2d_X509_NAME(3) and also fails to explain how both differ, likely causing users to pick the wrong one for their purposes.
* a little more cleanup;jmc2017-01-071-2/+2
|
* Document X509_NAME_hash(3), listed in <openssl/x509.h>;schwarze2017-01-071-3/+20
| | | | | | | jmc@ reported that X509_LOOKUP_hash_dir(3) references it. Even though OpenSSL does not document it, given that it is used for file names that users have to create, it is sufficiently exposed to users to be worth documenting.
* Use the same parameter names as in ASN1_item_d2i(3).schwarze2016-12-281-53/+32
| | | | | Use simpler standard wordings. Add X.509 references.
* Consistently mark up various ASN.1 type names defined in standardsschwarze2016-12-251-4/+8
| | | | related to X.509 with .Vt such that they can be searched for.
* Document X509_NAME_dup(3) and X509_NAME_ENTRY_dup(3) listed inschwarze2016-12-141-2/+84
| | | | | | OpenSSL doc/man3/X509_dup.pod and d2i_X509_NAME_ENTRY(3) and i2d_X509_NAME_ENTRY(3) listed in OpenSSL doc/man3/d2i_X509.pod. Also add a RETURN VALUES section.
* Complete rewrite to improve clarity.schwarze2016-12-141-61/+49
| | | | Add some cross references and STANDARDS.
* various cleanup;jmc2016-12-081-6/+5
|
* Copyright and licenseschwarze2016-12-051-2/+50
|
* first pass; ok schwarzejmc2016-11-061-1/+3
|
* convert X509 manuals from pod to mdocschwarze2016-11-041-0/+34