A mirror of https://github.com/libressl/openbsd.git https://git.lua4.win/openbsd/atom?h=OPENBSD_7_7 2025-03-09T15:12:18+00:00 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-02-14T12:01:58+00:00 jsing 2025-02-14T12:01:58+00:00 urn:sha1:a89810379a758c9cd27af2462547dc646dcfaa61 Currently, SHA{1,256,512}_ASM defines are used to remove the C implementation of sha{1,256,512}_block_data_order() when it is provided by assembly. However, this prevents the C implementation from being used as a fallback. Rename the C sha*_block_data_order() to sha*_block_generic() and provide a sha*_block_data_order() that calls sha*_block_generic(). Replace the Makefile based SHA*_ASM defines with two HAVE_SHA_* defines that allow these functions to be compiled in or removed, such that machine specific verisons can be provided. This should effectively be a no-op on any platform that defined SHA{1,256,512}_ASM. ok tb@ 2025-01-27T14:02:32+00:00 jsing 2025-01-27T14:02:32+00:00 urn:sha1:d97873f8db01cd052f45675db2ed3d9584c93c44 The RC4_INDEX define switches between base pointer indexing and per-byte pointer increment. This supposedly made a huge difference to performance on x86 at some point, however compilers have improved somewhat since then. There is no change (or effectively no change) in generated assembly on a the majority of LLVM platforms and even when there is some change (e.g. aarch64), there is no noticable performance difference. Simplify the (still messy) macros/code and mop up RC4_INDEX. ok tb@ 2024-11-12T13:14:57+00:00 jsing 2024-11-12T13:14:57+00:00 urn:sha1:e5a8d62d4380136d1e13d26d8b9b2462456b96a7 2024-11-05T06:09:12+00:00 tb 2024-11-05T06:09:12+00:00 urn:sha1:843a9f265f386c844efd76e86f84452741cb03d6 It is gross that an internal detail leaked into a public header, but, hey, it's openssl. No hack is too terrible to appear in this library. opensslconf.h needs major pruning but the day that happens is not today. ok jsing 2024-10-19T13:06:11+00:00 jsing 2024-10-19T13:06:11+00:00 urn:sha1:5d1b4ec04e3e4da6a278a481334cacf007acd117 Move the IA32 specific code to arch/{amd64,i386}/crypto_cpu_caps.c, rather than polluting cryptlib.c with machine dependent code. A stub version of crypto_cpu_caps_ia32() still remains for now. 2024-10-18T14:44:02+00:00 jsing 2024-10-18T14:44:02+00:00 urn:sha1:6eadf86bd8224496dbe05e5aeb269a31b3033bec This is the same CPU capabilities code that is now used for amd64. Like amd64 we now only populate OPENSSL_ia32cap_P with bits used by perlasm. Discussed with tb@ 2024-08-31T10:44:39+00:00 tb 2024-08-31T10:44:39+00:00 urn:sha1:a39f98b1710f75361198c026bd5f09593af1c1f5 This allows us in particular to get rid of the MD Symbols.list which were needed on amd64 and i386 for llvm 16 a while back. OPENSSL_ia32cap_P was never properly exported since the symbols were marked .hidden in the asm. ok beck jsing 2024-08-11T13:02:39+00:00 jsing 2024-08-11T13:02:39+00:00 urn:sha1:5dcef2b3ea9eb7ace8ed74c27534785fc0b87130 Provide a per architecture crypto_arch.h - this will be used in a similar manner to bn_arch.h and will allow for architecture specific #defines and static inline functions. Move the HAVE_AES_* and HAVE_RC4_* defines here. ok tb@ 2024-03-29T11:00:57+00:00 jsing 2024-03-29T11:00:57+00:00 urn:sha1:2f6039e975b851c54c5857fe9253b02da013fb32 Always provide AES_{encrypt,decrypt}() via C functions, which then either use a C implementation or call the assembly implementation. ok tb@