summaryrefslogtreecommitdiff
path: root/src/lib/libcrypto/x509 (follow)
Commit message (Collapse)AuthorAgeFilesLines
* x509_obj.c: be better at sortingtb2025-01-271-2/+2
|
* x509_obj.c: fix includestb2025-01-261-4/+5
|
* Rewrite X509_NAME_ENTRY_oneline() using CBB and CBStb2025-01-262-104/+123
| | | | | | | | | | | | | | | | | | | | | | This splits the horrid spaghetti into a few relatively straightforward helpers which do one thing at a time. There are still some spectacular dances around ASN1_GENERALSTRING, but let's blame that one on X.500. In brief, X509_NAME_ENTRY_oneline() iterates over the name entries, and writes out a line /name1=value1,/name2=value2,... which you may have seen variations of in issuer or subject output. The name is the short name or the long name or the textual representation of the OID (truncated to 79 characters) and the value is a string where printable ASCII characters are represented as themselves and otherwise as hexadecimal digits preceded by \x. Except for GENERALSTRING, where the four octet representation is shortened to single-octet representation if none of the top three octets in the entire string is populated. It's the mother of all pretty things. But, hey, you could do worse and try to parse this garbage... ok jsing
* x509_utl.c: use normal order of internal headerstb2025-01-261-3/+2
|
* typo: slighty -> slightlytb2025-01-061-2/+2
|
* 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...
* 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.
* 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@
* Annotate yet another greasy stinky tentacle of xcatb2024-12-201-1/+2
| | | | I'm so tired of this.
* Use ASIdentifiers rather than struct ASIdentifiers_sttb2024-12-041-2/+2
| | | | | | This matches the other members of X509 and is what's used everywhere else. ok miod
* x509_policy.c: point at RFC 9618tb2024-11-141-3/+3
|
* Move cryptlib.h to crypto_local.htb2024-11-051-2/+2
| | | | discussed with jsing
* Drop some pointless parenthesestb2024-11-011-7/+7
|
* Only include cryptlib.h where it's neededtb2024-11-011-4/+3
| | | | Clean up the other includes while there.
* Rewrite X509V3_add_value() to a single exit idiomtb2024-08-311-19/+32
| | | | ok jsing
* Expose X509_get_signature_infotb2024-08-311-3/+1
| | | | | | | | To compensate for all the removals, a single, small, constructive piece of this bump: expose X509_get_signature_info() so that libssl's security level API can handle RSA-PSS certificates correctly. ok beck jsing
* Make X509at_* API internaltb2024-08-313-54/+18
| | | | | | | | The only consumer, yara, has been adjusted. It will be some more work to remove this idiocy internally, but at least we will no longer have to care about external consumers. ok beck jsing
* Remove EVP_PKEY.*attr* APItb2024-08-311-19/+1
| | | | | | I ranted enough about this recently. PKCS#12. Microsoft. 'nuff said. ok beck jsing
* Move BIT_STRING_BITNAME tables to consttb2024-08-312-6/+6
| | | | | | | | | Another bunch of const correctness fixes for global tables. These are used to map ns cert types, key usage types and CRL reasons to strings and vice versa. By the looks of it, nobody ever figured out how to use this (need I mention that it's convoluted?). ok beck jsing
* const correct X509_LOOKUP_METHODtb2024-08-316-19/+19
| | | | | | | With this another family of global tables becomes const as it should always have been. ok beck jsing
* Remove X509_REQ_{set,get}_extension_nids()tb2024-08-312-23/+2
| | | | | | | | LibreSSL no longer supports non-standard OIDs for use in the extensions attribute of CSRs. The API that enabled that (and nobody used of course) can now go. ok beck jsing
* Make X509_VAL opaquetb2024-08-312-6/+8
| | | | | | | Nothing needs to reach into this structure, which is part of certificates. So hide its innards. ok beck jsing
* Remove X509_check_trust() and some related definestb2024-08-313-32/+10
| | | | | | | | | Someone thought it would be a good idea to append non-standard trust information to the certs in the trust store. This API is used to inspect that depending on the intended purpose of the cert. Only M2Crypto thought it necessary to expose this. It was adjusted. ok beck jsing
* The X509V3_CONF_METHOD goes awaytb2024-08-311-10/+1
| | | | | | No longer used, never really needed. ok beck jsing
* Remove X509V3_get_string/X509V3_string_freetb2024-08-312-19/+2
| | | | | | | These have always been unused, but the db_meth abstraction hid that very well. Bye. ok beck jsing
* Make some more x509 conf stuff internaltb2024-08-3110-48/+39
| | | | | | | This internalizes a particularly scary layer of conf used for X.509 extensions. Again unused public API... ok beck jsing
* Retire X509V3_set_conf_lhash()tb2024-08-312-13/+2
| | | | | | | | Thankfully sthen removed the out-of-support PHP versions 7.4 and 8.0, which were the last users of this API, which in turn permitted much of this conf rampage. Now the stub can join its guts in the attic. ok beck jsing
* Retire X509V3_EXT_{,CRL_,REQ_}add_conf()tb2024-08-312-35/+2
| | | | | | | | Fortunately all projects who want to configure their extensions using a dangerous string DSL/API figured out the fact that one was supposed to be using the nconf version of these (the hint is the 'n', as in new). ok beck jsing
* Unexport some conf layers unused outside of libcryptotb2024-08-311-1/+3
| | | | | | | | | | | | | imodules are called imodules because they contain Information about modules that have been Initialized. Which one of these two I it is is anyone's best guess. Why anything outside of libcrypto would ever possibly care will also remain a mystery. Remove the old way of adding a conf module, user data, stop allowing to set a method (it's opaque now, remember?) and drop a couple bits more from the public api interface. ok beck jsing
* Make CONF_METHOD opaquetb2024-08-311-1/+2
| | | | | | | Much of conf is designed in such a way that you really have to reach into its structs. This one piece can be hidden. It might even be removed soon. ok beck jsing
* Get rid of last use of db_methtb2024-08-281-38/+11
| | | | | | | | | | | | Nothing touches db_meth in ports. Thus only way a db_meth can be set is now as a side effect X509V3_set_conf() in which case the db is an NCONF database and the db_meth will be a thin wrapper of NCONF_get_section(). Make that explicit in the implementation, remove the guts of the unused X509V3_get_string() and X509V3_string_free(), turn X509V3_section_free() into a noop and replace several checks for ctx->db, ctx->db->meth, ... with a simple ctx->db != NULL check. ok beck jsing
* Remove a few obvious comments, unwrap a few lines and annotate sometb2024-08-281-26/+9
| | | | functions for removal
* Turn X509V3_set_conf_lhash() into a nooptb2024-08-281-26/+1
| | | | | | Another legacy turd that was only used by PHP 7.4 and 8.0. ok beck jsing
* Disable X509V3_EXT{,_CRL,_REQ}_add_conf()tb2024-08-281-17/+7
| | | | | | | These legacy interfaces were only used by PHP 7.4 and 8.0 and they will be removed in an upcoming bump. ok beck jsing
* Annotate X509V3_CONF_CTX and its only instance for removaltb2024-08-281-4/+3
| | | | | | | A comment saying /* Maybe more here */ in a public also goes (yuck). Of course the promise was fulfilled by OpenSSL 3. ok beck jsing
* Make use of X509_get_signature_info() in check_sig_level()tb2024-08-281-20/+3
| | | | | | | | | | | | | | | If an auth_level (i.e., security_level, but not quite, because Viktor) was set on the X509_VERIFY_PARAM in the X509_STORE_CTX, the verifier would reject RSA-PSS or EdDSA certificates for insufficient security bits due to incorrect use of OBJ_find_sigid_algs() (this was also a bug in the initial security level implementation in OpenSSL 1.1). Using X509_get_signature_info() fixes this while preserving behavior for all other algorithms. Reported by Steffen Ullrich as one of multiple issues with RSA-PSS. ok jsing
* Implement X509_get_signature_info()tb2024-08-282-1/+122
| | | | | | | | | | | | | | | | This is a slightly strange combination of OBJ_find_sigid_algs() and the security level API necessary because OBJ_find_sigid_algs() on its own isn't smart enough for the special needs of RSA-PSS and EdDSA. The API extracts the hash's NID and the pubkey's NID from the certificate's signatureAlgorithm and invokes special handlers for RSA-PSS and EdDSA for retrieving the corresponding information. This isn't entirely free for RSA-PSS, but for now we don't cache this information. The security bits calculation is a bit hand-wavy, but that's something that comes along with this sort of numerology. ok jsing
* x509_vfy.c: drop some unnecessary parenthesestb2024-08-041-6/+5
|
* Disable X509at_get_attr{,_count}() and X509at_delete_attr()tb2024-07-261-12/+7
| | | | | | | | | These are (not so) thin wrappers around the stack API and only make things unreadable by adding an unneccesary layer of indirection and repeating checks already present in the stack API. X509at_delete_attr() is a masterpiece. ok jsing
* Inline last user of X509at_get_attr()tb2024-07-261-2/+2
| | | | ok jsing
* Inline trivial X509at_* calls in x509_reqtb2024-07-261-4/+4
| | | | ok jsing
* Unify X.509v3 extension methodstb2024-07-1320-320/+620
| | | | | | | | | | | | Use C99 initializers for all structs (some were forgotten). Make all the structs static, call them x509v3_ext_* matching NID_*. Add accessors called x509v3_ext_method_* and use these to implement X509V3_EXT_get_nid(). This adds consistency and avoids a few contortions like grouping a few extensions in arrays to save a couple externs. ok beck jsing
* Fix the horrible and undocumented behaviour of X509_check_trustbeck2024-07-123-51/+70
| | | | | | | | | | | | | | | | | | | | Of allowing you to pass in a NID directly, instead of a trust_id, and have it work, as long as the trust_id's and the NID's did not overlap. This screwball behaviour was depended upon by the OCSP code that called X509_check_trust with the NID, instead of the trust id, so let's fix that. We also rename the confusingly named X509_TRUST_DEFAULT to X509_TRUST_ACCEPT_ALL which makes a lot more sense, and rototill this to remove the confusingly named static functions. This will shortly be follwed up by making this function private, so we have not bothered to fix the amazingly obtuse man page as it will be taken behind the barn at that time. ok tb@
* Clean up in X509_check_trust.beck2024-07-121-14/+8
| | | | | | | | | | | | | | | The XXX comment in here is now outdated. Our behaviour matches boringssl in that passing in a 0 trust gets the default behavior, which is to trust the certificate only if it has EKU any, or is self signed. Remove the goofy unused nid argument to "trust_compat" and rename it to what it really does, instead of some bizzare abstraction to something simple so the code need not change if we ever change our mind on what "compat" is for X.509, which will probably only happen when we are back to identifying things by something more sensible like recognizable grunts and smells. ok jsing@
* Drop the unused evp includetb2024-07-121-2/+1
|
* Rename the sk in this file to extstb2024-07-121-16/+16
|
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-08-25 07:21:29 +0000