summaryrefslogtreecommitdiff
path: root/src/lib/libcrypto/asn1 (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Add a few to-do items to the crl_cb()tb2026-04-071-1/+6
| | | | | | | | Prompted by the "fix" fighting symptoms of misdesign in Delta CRL processing rather than addressing the root cause. Probably the best fix is to remove support for Indirect CRLs and Delta CRLs outright. ok jsing
* a_bitstr.c: fix includestb2026-02-081-3/+5
|
* Make truncation in ASN1_BIT_STRING_set_bit() explicittb2026-02-081-9/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of relying on i2c_ASN1_BIT_STRING() to determine the "unused" bits on encoding, set them explicitly in abs->flags via a call to asn1_abs_set_unused_bits(). This means ASN1_STRING_FLAGS_BITS_LEFT is now set on a bit string, which was previously explicitly cleared. This also means that the encoding of a non-zero ASN1_BIT_STRING populated by setting the bits individually will now go through the if (a->flags & ASN1_STRING_FLAG_BITS_LEFT) path in i2c_ASN1_BIT_STRING(). The most prominent usage of this function is in X.509 for the keyUsage extension or the CRL reason codes. There's also the NS cert type, TS PKIFailureInfo and general BITLIST config strings. The reason for the truncation logic comes from the DER for NamedBitLists X.690, 11.2.2 below: X.680, 22.7: When a "NamedBitList" is used in defining a bitstring type ASN.1 encoding rules are free to add (or remove) arbitrarily any trailing 0 bits to (or from) values that are being encoded or decoded. Application designers should therefore ensure that different semantics are not associated with such values which differ only in the number of trailing 0 bits. X.690, 11.2.2 Where ITU-T Rec. X.680 | ISO/IEC 8824-1, 22.7, applies, the bitstring shall have all trailing 0 bits removed before it is encoded. Note 1 - In the case where a size constraint has been applied, the abstract value delivered by a decoder to the application will be one of those satisfying the size constraint and differing from the transmitted value only in the number of trailing zero bits. Note 2 - If a bitstring value has no 1 bits, then an encoder shall encode the value with a length of 1 and an initial octet set to 0. ok kenjiro (on an earlier version) jsing
* asn1t.h: whitespace tweakstb2026-01-161-81/+74
| | | | | | Add missing space after commas, shorten a couple comments in structs, reflow weirdly wrapped long comments and improve the random line breaks in typedefs and prototypes.
* asn1t.h: Otherwiser -> Otherwisetb2026-01-161-2/+2
|
* asn1t.h: more macro cleanup, add missing C99 initializers for ADB_ENTRY()tb2026-01-161-69/+99
| | | | ok kenjiro
* More asn1t.h cleanuptb2026-01-111-58/+88
| | | | | | | | This converts more macros to C99 initializers. Rename flags and tags arguments by appending val because they collide with the field names. The remainder are whitespace changes. ok kenjiro
* asn1t.h: add C99 initializers for some ASN.1 templatestb2026-01-091-155/+195
| | | | | | | | | | | | | | This is a first pass at tidying up the unsightly mess that is asn1t.h. For better or worse, we have expanded the macros internally, and in base only rpki-client uses the templates. They are generally rarely used. Fortunately. Having C99 initializers helps a lot with debugging templated ASN.1 by combining cc -E with clang-format. They make the macros more readable, look tidier and help with grep. ok kenjiro
* asn1t.h: whitespace nittb2026-01-091-2/+2
|
* Fix ASN1_ADB_END macro, make it compatible with OpenSSLtb2026-01-071-4/+3
| | | | | | | | | | | | | | In asn1t.h r1.18 (commit 9b72422d) I removed the app_items member from ASN1_ADB and failed to fix up the ASN1_ADB_END() macro that populates the ASN1_ADB. This means ASN1_ADB_END() tried to initialize one member too many and would thus cause a compilation failure, so nobody uses this with LibreSSL. Internally, we have expanded all its uses. We could leave it broken or fix it up. Take the opportunity to add an unused adb_cb() argument instead, making the macro invocation compatible with OpenSSL. ok jsing kenjiro
* ASN.1 templates: make internal *_PUBKEY_it statictb2026-01-051-5/+5
|
* ASN.1 templates: make ASN1_EXTERN_FUNCS statictb2026-01-052-7/+7
| | | | These are used directly only as part of the ASN.1 item in the same file.
* a_bitstr: remove parentheses in return statementstb2026-01-041-5/+5
| | | | no binary change
* i2c_ASN1_BIT_STRING() vs ASN1_STRING_FLAG_BITS_LEFTtb2026-01-041-10/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A nasty quirk in the bit string handling is that the serialization produced by i2d_ASN1_BIT_STRING() depends on whether the the magic ASN1_STRING_FLAG_BITS_LEFT is set. If ASN1_STRING_FLAG_BITS_LEFT is set, the number of unused bits is carried in a->flags & 0x07 and the remainder of the bit string is in a->data. This is terrible and undocumented but handled correctly. If ASN1_STRING_FLAG_BITS_LEFT is not set, all trailing zero bits are (intended to be) chopped off with all sorts of hilarious side effects. I broke this quite thoroughly when I incorrectly ported an overflow check from BoringSSL in: https://github.com/openbsd/src/commit/f81cc285d2aed8b36615119a306533696f3eb66c The result is that we currently return ret = a->length + 1 for both NULL and non-NULL pp. The calls to asn1_ex_i2c() in asn1_i2d_ex_primitive() thus report consistent lengths back, making it succeed. asn1_i2d_ex_primitive() therefore skips a->length + 1 bytes, while i2c_ASN1_BIT_STRING() only overwrites len + 1 bytes, which are possibly fewer. So a caller passing in an output buffer containing garbage (malloc) will get some of that garbage back in the encoding. Further, i2c_ASN1_BIT_STRING() also advances that pointer by the possibly reduced len + 1, but that fortunately doesn't matter since that's an effect local to asn1_ex_i2c(), the only caller of i2c_ASN1_BIT_STRING(). The last bit is that the current behavior may set bogus unused bits coming from the scanning backward madness. I added such an example in the parent commit. The fix is simple: use len after the truncation effect was established, not the original a->length, turning this commit into what my backport should have been. This fixes the two currently failing regress tests, so remove expected failure marker again. ok jsing kenjiro
* i2c_ASN1_BIT_STRING(): zap nonsensical commenttb2026-01-041-2/+2
| | | | | | | | The /* should not happen */ happens if a->data is all zeroes (where there used to be an OOB access a few years back), which is a legitimate BIT STRING, so this is just nonsense. ok jsing kenjiro
* a_bitstr.c: whitespace nittb2026-01-041-2/+2
|
* Unexport ASN1_LONG_UNDEFtb2026-01-022-7/+8
| | | | | | | | | | This is another one of these weird magic values that nothing outside of libcrypto uses. Fix a confusing comment in long_i2c() while there. The skipping behavior is used in particular for omitting the optional length value in the non-standard OpenSSL-specific DHparam() ASN.1 encoding. ok jsing kenjiro
* Remove STABLE_FLAGS_MALLOCtb2025-12-311-2/+3
| | | | | | | | | | Formerly used by ASN1_STRING_TABLE_{add,cleanup}() which were removed two years ago. Annotate why STABLE_NO_MASK stays: as usual, security/xca ends up being the sole consumer of some nonsense. Apparently it needs its own reimplementation of ASN1_STRING_set_by_NID(), another removable public API that should never have been exposed. ok kenjiro
* Garbage collect V_ASN1_APP_CHOOSEtb2025-12-211-2/+1
| | | | ok kenjiro
* Remove last internal use of ASN1_STRING_data()tb2025-12-071-13/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | PKCS5_pbe_set0_algor() is no longer public, but its parameters are provided directly via public API, namely the wonderful PKCS8_encrypt() and PKCS12_pack_p7encdata(). Muppetry abounds. To wit: If saltlen < 0, the call to ASN1_STRING_set(pbe->salt, NULL, saltlen) would error. Let's do that up front in a more obvious way. We don't care about side-effects to pbe->salt since we free it on error anyway. If saltlen == 0, we default it to PKCS5_PBE1_SALT_LEN. This is particularly funky in case the caller passed in salt != NULL, in which case we can only hope and pray this buffer is long enough. If the caller passed a salt, copy it to pbe->salt via ASN1_STRING_set(). If there's no salt, allocate a buffer of the appropriate length, fill it with random and transfer ownership to pbe->salt via ASN1_STRING_set0(). There's a change of behavior in that this will not be NUL-terminated (why should it be?). If we wanted to preserve behavior, we'd just use calloc(1, saltlen + 1) instead of the malloc(). The exit path is quite special, too, but I didn't want to change this right now. tweaks/ok kenjiro
* Replace trivial uses of ASN1_STRING_data()tb2025-12-052-6/+6
| | | | | | | | | Almost entirely mechanical diff that ensures that for read-only accesses we use the const correct ASN1_STRING_get0_data(). Arguably, in most places the better fix would be to reach into ASN1_STRING but then we have to think and bikeshed... ok beck kenjiro
* libcrypto: add header guards to *_local.htb2025-11-261-1/+6
| | | | | | | | | An upcoming change requires the inclusion of asn1_local.h in x509_local.h which doesn't work due to missing header guards. Add guards to all local headers that don't have them, although reacharounds and multiple inclusions are unlikely to occur for most of those. ok jsing
* Hide primitive BOOLEAN itemstb2025-08-221-1/+4
| | | | Rides the libcrypto bump from a couple days ago
* x_crl.c: wont -> won't + KNF for a commenttb2025-08-191-3/+4
|
* Tweak comment in asn1_item_free: KNF, missing comma, wont -> won't.tb2025-08-141-3/+4
|
* Merge the two functions from x_pkey.c into pem_info.ctb2025-07-121-124/+0
| | | | It looks like those can be unexported.
* Merge the two functions from x_info.c into pem_info.ctb2025-07-121-97/+0
| | | | | X509_INFO_new() isn't used directly outside of this file, so this is a bit tidier.
* Add missing check to X509_CRL_verify()tb2025-07-101-1/+7
| | | | | | | | | | | | | When fixing CVE-2014-8275 in commit 684400ce, Henson added a check that the AlgorithmIdentifier in the certificate's signature matches the one in the tbsCertificate. A corresponding check for CRLs was missed. BoringSSL added such a check in 2022, so this should be fine for us to do as well even though OpenSSL still doesn't have it. The only caller will set an error on the stack, so we don't do it here. There's no obvious check that X509_REQ_verify() could do. ok beck kenjiro
* X509_print: emit UIDs unless X509_FLAG_NO_IDS is settb2025-07-011-1/+28
| | | | | | | | | | | | | | | | | | | | | issuerUID and subjectUID are a curiosity introduced in X.509v2 before extensions were a thing. Their purpose is to help distinguishing certs with identical subject. They are rarely used and are MUST NOT use in the CA/BF baseline requirements. They do occasionally show up in test certificates and it is confusing that openssl x509 silently ignores them. Their encoding also makes them relatively hard to spot in the output of asn1 parsing tools. The output is identical to OpenSSL < 3 and BoringSSL, but due to some weird tweaks added leading up to OpenSSL 3 their output is no longer compatible with that. It is not entirely correct anyway. Since it is a (not further specified) bit string, you shouldn't be ignoring its unused bits... The X509_FLAG_NO_IDS flag has no effect for CSRs. discussed with beck ok job kenjiro (on an earlier version)
* X509_print and friends: switch from BIO_write() to BIO_printf()tb2025-06-251-17/+16
| | | | | | Manually counting letters in const strings is ... suboptimal. ok beck jsing
* Fix smatch warning in asn1_primitive_print()tb2025-06-071-2/+2
| | | | | | | | Remove unnecessary and inconsistent NULL check for 'it', which the only caller, asn1_item_print_ctx(), already dereferenced. found by jsg ok kenjiro
* correct indentation, no functional changejsg2025-06-021-3/+4
| | | | found with smatch, ok tb@
* Crank default salt length of PBE2 to 16 octetstb2025-05-242-4/+13
| | | | | | | | | | FIPS is currently revising their PBKDF2 recommendations and apparently they want to require 16 octets. https://github.com/pyca/cryptography/issues/12949 https://github.com/libressl/portable/issues/1168 ok kenjiro joshua jsing
* Switch the default PBMAC to hmacWithSHA256tb2025-05-241-2/+2
| | | | | | | | | | Using hmacWithSHA1 isn't outrageously bad, but newly generated encrypted password files ought to be using something better. Make it so. https://github.com/pyca/cryptography/issues/12949 https://github.com/libressl/portable/issues/1168 ok joshua
* asn_moid: move inclusion of err_local.h to the proper placetb2025-05-101-2/+2
|
* Use err_local.h rather than err.h in most placestb2025-05-1035-71/+70
| | | | ok jsing
* Plug a memory leak in x509_name_encode()tb2025-03-201-2/+4
| | | | | | | | | This is nearly identical to a leak fixed by miod 10 years ago in x509_name_canon() but was missed in r1.30. This entire file needs a metric ton of bleach, but my head currently spins too much for tackling this, so go with the cheap one-liner. From Niels Dossche
* Fix traditional SSLeay X509_NAME printingtb2025-03-191-29/+1
| | | | | | | | | | | | | | The gibberish that was there before the rewrite didn't actually skip names whose SN representation was different start with /O= or /OU= (with one or two capital letters between '/' and '='), it simply failed to separate them, resulting in nonsense such as CN=Microsec e-Szigno Root CA 2009/emailAddress=info@e-szigno.hu So ditch the code doing that, simplifying this now internal function quite a bit. ok jsing
* Unexport X509_NAME_print()tb2025-03-091-3/+2
| | | | | | | | | | Nothing uses this anymore. M2Crypto has been patched and a fix for opensc has been upstreamed. ok jsing This is the start of a major bump. Don't build the tree until I have synced sets in about 20 commits.
* asn1_multi: remove a pointless casttb2025-03-061-2/+2
| | | | | There's no need to cast away const from a const char * if you're going to pass it to a const char * argument of a function.
* Rename X509V3_get_section() to X509V3_get0_section()tb2025-03-061-2/+2
| | | | | | | | This makes it clear for those fluent in OpenSSL API gibberish that nothing needs to be freed here. This is because it returns something hanging off a hash entry owned by cnf. ok jsing
* Garbage collect X509V3_section_free()tb2025-03-061-5/+2
| | | | | | | | Historically, X509V3_section_free() could be customized by the conf db method to release memory allocated by X509V3_get_section(). This is no longer supported, so it is always a noop and can be removed. ok jsing
* Rename the crl_inf_cb() to crl_info_cb()tb2025-02-271-3/+3
|
* Hoist X509_REVOKED_cmp() above its only callertb2025-02-271-9/+7
| | | | | This way we don't need a prototype and things that belong together are together. Slight KNF tweak while there
* x_crl.c: remove two NULL checks before *_free()tb2025-02-241-5/+3
|
* Remove unused name member from x509_sttb2025-02-211-9/+1
| | | | | | | As far as I can tell this has never been used since the beginning of git history with SSLeay 0.8.1b, so we can simplify the x509_cb() a little. ok jsing miod
* Remove unused valid member of x509_sttb2025-02-201-2/+1
| | | | | | internal_verify() (now x509_vfy_internal_verify()) used to cache the validity of the signature of a cert in this field. This is no longer the case since x509_vfy.c 1.57 (2017).
* Move X509_NAME_print() next to its only internal callertb2025-02-082-93/+91
| | | | Fix includes while there
* X509_NAME_print(): remove no longer useful length checktb2025-01-271-4/+1
| | | | | This was needed to avoid truncation on BIO_write(). With the switch to BIO_printf() in the previous commit this is no longer needed.
* X509_NAME_print: NUL-terminate and switch to BIO_printf()tb2025-01-271-2/+5
| | | | | | This handles the empty string, which ruby-openssl checks. Pointed out by anton
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2026-08-27 23:04:33 +0000