A mirror of https://github.com/libressl/openbsd.git https://git.lua4.win/openbsd/atom?h=OPENBSD_7_9_BASE 2025-09-28T07:52:53+00:00 2025-09-28T07:52:53+00:00 tb 2025-09-28T07:52:53+00:00 urn:sha1:dee41641c860153d9ff3214fdf9f43ae9a10429c This wasn't part of the initial proposal and causes issues in curl downstream. We could pile more hacks on top of this, but at some point this is getting too silly. Relatedly, most of the FOOerr() could be removed, although PEMerr(), RSAerr() and SSLerr() are used by some downstreams and probably not worth patching out. Discussed with @vszakats in https://github.com/libressl/portable/issues/1154 2025-03-09T15:29:56+00:00 tb 2025-03-09T15:29:56+00:00 urn:sha1:9175c6902a8e145ca23903d60576f90eb073d460 CRYPTO_set_mem_ex_functions() was renamed to CRYPTO_set_mem_functions(), replacing the latter while also correcting the arguments for the free pointer. The backstory is that a commit that was never compiled was fixed the wrong way an hour later (both committed without review, obviously), and here we are, still cleaning up the mess 23 years later. We carry patches in cjose and stunnel for this; dovecot and links+ have autoconf checks and will adapt. Oh, and then there's the mariadb configure time insanity passing wrong function pointers... ok jsing 2025-03-09T15:12:18+00:00 tb 2025-03-09T15:12:18+00:00 urn:sha1:b8acfd2983c50474382bf8ed132a5b7e7bdedb34 Some people are concerned that leaking a user name is a privacy issue. Allow disabling the __FILE__ and __LINE__ argument in the error stack to avoid this. This can be improved a bit in tree. From Viktor Szakats in https://github.com/libressl/portable/issues/761 ok bcook jsing 2025-01-20T17:50:12+00:00 tb 2025-01-20T17:50:12+00:00 urn:sha1:d2ee6a6329cb6b037f3949082396fa72b53b5ee8 2024-10-03T03:47:40+00:00 tb 2024-10-03T03:47:40+00:00 urn:sha1:def4f5be584e1e58aabc7ae8ee299b0c32171887 The brilliant idea of installing a fragile non-idempotent cleanup atexit handler as a library has bitten many people over time. This gets particularly exciting when you can't control who dlopens the lib first (don't we all love Python bindings) or if you are in a threaded context. Fake OpenSSL clones chose not to do this but now get to carry a noop flag since people start opting out of this madness (there's a good old tradition at work here). ok beck joshua jsing millert miod 2024-08-31T12:43:58+00:00 jsing 2024-08-31T12:43:58+00:00 urn:sha1:c74050854a91b50d2192e2e05fedaf0366d8ab81 OPENSSL_cpu_caps() is currently machine dependent and exposes CPUID data on amd64 and i386. However, what it is really used for is to indicate whether specific algorithms are accelerated on the given hardware. Change OPENSSL_cpu_caps() so that it returns a machine indepent value, which decouples it from amd64/i386 and will allow it to be used appropriately on other platforms in the future. ok tb@ 2024-04-10T15:13:23+00:00 beck 2024-04-10T15:13:23+00:00 urn:sha1:df8ba0807626929e32b1568f0bbc683c7864b793 accidentally not included in crypto.h commit requested and ok tb@ 2024-04-10T14:51:02+00:00 beck 2024-04-10T14:51:02+00:00 urn:sha1:8f5c098da9d2f4cfab60d5924c5dda86cf4709a2 crypto.h already had the symbols not hidden behind LIBRESSL_INTERNAL hidden - This now picks up the reset of them marking them as LCRYPTO_UNUSED, and removes the LIBRESSL_INTERNAL guard. These symbols will now be hidden, but if we use them inside the library in a namespaced build we will get a deprecation warning. use outside the library will be as with any other hidden symbol, so fine. ok tb@ 2024-03-02T15:40:05+00:00 tb 2024-03-02T15:40:05+00:00 urn:sha1:4707ea1a5a0270017a7093f76a62233c3d1d9196 ok millert miod 2024-03-02T11:40:53+00:00 tb 2024-03-02T11:40:53+00:00 urn:sha1:ea629aae9a31aaf5e0a39626102e231bdca5616e Requested by jsing