A mirror of https://github.com/libressl/openbsd.git https://git.lua4.win/openbsd/atom?h=OPENBSD_7_6 2024-07-08T16:23:27+00:00 2024-07-08T16:23:27+00:00 beck 2024-07-08T16:23:27+00:00 urn:sha1:4c8d22f29be015c6c02c809813e9a931e88c2575 ok tb@ 2024-06-24T06:43:23+00:00 tb 2024-06-24T06:43:23+00:00 urn:sha1:c9802a5afe29675d69b605ce906d34fd89c024ac These constitute the bulk of the remaining global mutable state in libcrypto. This commit moves most of them into data.rel.ro, leaving out ERR_str_{functs,libraries,reasons} (which require a slightly different approach) and SYS_str_reasons which is populated on startup. The main observation is that if ERR_load_strings() is called with a 0 lib argument, the ERR_STRING_DATA argument is not actually modified. We could use this fact to cast away const on the caller side and be done with it. We can make this cleaner by adding a helper ERR_load_const_strings() which explicitly avoids the assignment to str->error overriding the error code already set in the table. In order for this to work, we need to sprinkle some const in err/err.c. CMS called ERR_load_strings() with non-0 lib argument, but this didn't actually modify the error data since it ored in the value already stored in the table. Annoyingly, we need to cast const away once, namely in the call to lh_insert() in int_err_set_item(). Fixing this would require changing the public API and is going to be tricky since it requires that the LHASH_DOALL_FN_* types adjust. ok jsing 2024-04-20T10:11:55+00:00 tb 2024-04-20T10:11:55+00:00 urn:sha1:dbc91b02b46414edaa98f5ae533bc4c44c5b6ef7 ok jsing 2024-02-19T15:37:44+00:00 tb 2024-02-19T15:37:44+00:00 urn:sha1:ba75d785d11bc2d4cd808be68b8aa03ff79cab79 2024-02-18T15:45:42+00:00 tb 2024-02-18T15:45:42+00:00 urn:sha1:ff3e386de60f6149938edb124d31bc2fd7ae04f6 ok jsing 2024-01-25T13:44:08+00:00 tb 2024-01-25T13:44:08+00:00 urn:sha1:26fee542e65d530cdacb9282bf510602c1e2b5fd The PKCS #7 ContentInfo has a mandatory contentType, but the content itself is OPTIONAL. Various unpacking API assumed presence of the content type is enough to access members of the content, resulting in crashes. Reported by Bahaa Naamneh on libressl-security, many thanks ok jsing 2023-11-15T00:55:43+00:00 tb 2023-11-15T00:55:43+00:00 urn:sha1:3eab11b039ccf9e5a83480f4974c83fb6d83fe86 2023-11-15T00:52:44+00:00 tb 2023-11-15T00:52:44+00:00 urn:sha1:43b6d8a7eb229e4edf4cb7593f9a3a4d24349355 These use static helper functions which don't need prototypes this way. 2023-11-09T19:08:07+00:00 tb 2023-11-09T19:08:07+00:00 urn:sha1:6663cdc1da1880b08eb1e374997c22892bd0e407 2023-11-09T19:00:53+00:00 tb 2023-11-09T19:00:53+00:00 urn:sha1:efa83e8b7e6299bbebd3ad2f680ed137acfca9e7 This is a straightforward conversion because I'm not going to start a cleanup here. Explain why this is not using X509_ALGOR_set_md(). See below. ok jca Let me include a beautiful note from RFC 5754 in its entirety: NOTE: There are two possible encodings for the AlgorithmIdentifier parameters field associated with these object identifiers. The two alternatives arise from the loss of the OPTIONAL associated with the algorithm identifier parameters when the 1988 syntax for AlgorithmIdentifier was translated into the 1997 syntax. Later, the OPTIONAL was recovered via a defect report, but by then many people thought that algorithm parameters were mandatory. Because of this history, some implementations encode parameters as a NULL element while others omit them entirely. The correct encoding is to omit the parameters field; however, when some uses of these algorithms were defined, it was done using the NULL parameters rather than absent parameters. For example, PKCS#1 [RFC3447] requires that the padding used for RSA signatures (EMSA-PKCS1-v1_5) MUST use SHA2 AlgorithmIdentifiers with NULL parameters (to clarify, the requirement "MUST generate SHA2 AlgorithmIdentifiers with absent parameters" in the previous paragraph does not apply to this padding).