openbsd/src/lib/libssl/bs_cbb.c, branch OPENBSD_6_8_BASE A mirror of https://github.com/libressl/openbsd.git https://git.lua4.win/openbsd/atom?h=OPENBSD_6_8_BASE 2020-09-16T05:52:04+00:00 Avoid memset() before memcpy() for CBB_add_bytes(). 2020-09-16T05:52:04+00:00 jsing 2020-09-16T05:52:04+00:00 urn:sha1:cdfaa096c0627eb79cb2944893d873d3aa00f2fc CBB_add_bytes() calls CBB_add_space(), which now explicitly zeros memory to avoid information leaks. However CBB_add_bytes() calls memcpy() for the same memory region, so the memset() is unnecessary. Avoid this by inlining part of CBB_add_space() rather than calling it directly. ok beck@ tb@ Ensure that CBB_add_space() always provides zeroed memory. 2020-03-13T15:54:34+00:00 jsing 2020-03-13T15:54:34+00:00 urn:sha1:13b054b349060ec4ab6863bdeb5c18f1992b6e5e ok tb@ Use calloc() rather than malloc() when allocating initial CBB buffer. 2020-03-12T17:17:12+00:00 jsing 2020-03-12T17:17:12+00:00 urn:sha1:5bd2365f596fdaf1fd5d5feb218d8a3e4c99a2f1 CBB uses recallocarray() to expand buffers, however was still using malloc() for the initial buffer, which could result in memory being leaked in incorrect use cases. While here also use calloc() to allocate internal structs. ok inoguchi@ tb@ assert.h is often misused. It should not be used in a library 2019-01-23T22:20:40+00:00 beck 2019-01-23T22:20:40+00:00 urn:sha1:5f0a8a144321350e4fbf1de6dd8937ff85055a6d ok bcook@ jsing@ Provide CBB_add_u32(), as needed for an upcoming conversion. 2018-08-16T18:39:37+00:00 jsing 2018-08-16T18:39:37+00:00 urn:sha1:376676d240a487534ae7527150946472cd5c131b ok tb@ Add CBB_discard_child(), which allows for a child CBB to be discarded. 2017-11-28T16:34:20+00:00 jsing 2017-11-28T16:34:20+00:00 urn:sha1:76849a9caf0c93472d0fa91e5211a18f1b3afd18 Based on BoringSSL. Clear the child pointer in CBB_cleanup(), so that we have fewer pointers 2017-08-12T02:50:05+00:00 jsing 2017-08-12T02:50:05+00:00 urn:sha1:b316f9f277648e3f7b8d4b8e8c5efe957a0fd85c hanging around to potentially invalid address space. Discussed with beck@ and doug@ Instead of starting a 'zero-sized' CBB at the size of the first addition 2017-05-07T05:03:41+00:00 jsing 2017-05-07T05:03:41+00:00 urn:sha1:b238007c9db07d24cda00ffe301ec662ec5e1cc3 to the CBB, then doubling, start with an initial size of 64 bytes. Almost all uses will exceed this size and we avoid multiple small recallocarray() calls during the initial usage. ok beck@ Use freezero(3) in the CBB clean up path, since this could hold sensitive 2017-04-14T15:20:55+00:00 jsing 2017-04-14T15:20:55+00:00 urn:sha1:20fe51a87fb3b0e34b655fb34fa44eb6a33f33c9 information (such as master keys). Switch CBB to use recallocarray() - this ensures that we do not leak 2017-03-10T15:16:20+00:00 jsing 2017-03-10T15:16:20+00:00 urn:sha1:80ffcb28d3d130a0e90e846f64c44e610b999acf secrets via realloc(). ok inoguchi@