<feed xmlns='http://www.w3.org/2005/Atom'>
<title>openbsd/src/lib/libtls/tls_util.c, branch OPENBSD_6_8_BASE</title>
<subtitle>A mirror of https://github.com/libressl/openbsd.git
</subtitle>
<id>https://git.lua4.win/openbsd/atom?h=OPENBSD_6_8_BASE</id>
<link rel='self' href='https://git.lua4.win/openbsd/atom?h=OPENBSD_6_8_BASE'/>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/'/>
<updated>2019-04-13T18:47:58+00:00</updated>
<entry>
<title>Null out pointers on asprintf() failure.</title>
<updated>2019-04-13T18:47:58+00:00</updated>
<author>
<name>tb</name>
<email></email>
</author>
<published>2019-04-13T18:47:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/commit/?id=22aa80a8806f00247678b585c491dcd94a5e7b3f'/>
<id>urn:sha1:22aa80a8806f00247678b585c491dcd94a5e7b3f</id>
<content type='text'>
These pointers will be passed to free. According to asprintf(3), "on
OpenBSD, ret will be set to the null pointer, but this behavior should
not be relied upon."

ok jsing
</content>
</entry>
<entry>
<title>Only assign destlen when src is non-NULL.</title>
<updated>2019-04-04T15:10:10+00:00</updated>
<author>
<name>jsing</name>
<email></email>
</author>
<published>2019-04-04T15:10:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/commit/?id=5dd1c6b96f9dc9a54b9f610ec892e291593d83b6'/>
<id>urn:sha1:5dd1c6b96f9dc9a54b9f610ec892e291593d83b6</id>
<content type='text'>
This avoids ever having a non-zero len with a NULL pointer.
</content>
</entry>
<entry>
<title>Assert tedu's copyright since some of the code moved here is his.</title>
<updated>2018-02-08T07:55:29+00:00</updated>
<author>
<name>jsing</name>
<email></email>
</author>
<published>2018-02-08T07:55:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/commit/?id=20d3f0b613b887234b6a954c2ca54d79098b3cf5'/>
<id>urn:sha1:20d3f0b613b887234b6a954c2ca54d79098b3cf5</id>
<content type='text'>
</content>
</entry>
<entry>
<title>Split keypair handling out into its own file - it had already appeared</title>
<updated>2018-02-08T05:56:49+00:00</updated>
<author>
<name>jsing</name>
<email></email>
</author>
<published>2018-02-08T05:56:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/commit/?id=8a01a8361d1add29153f53a3721130f62d3d4389'/>
<id>urn:sha1:8a01a8361d1add29153f53a3721130f62d3d4389</id>
<content type='text'>
in multiple locations.

ok beck@
</content>
</entry>
<entry>
<title>Be consistent with the goto label names used in libtls code.</title>
<updated>2018-02-05T00:52:24+00:00</updated>
<author>
<name>jsing</name>
<email></email>
</author>
<published>2018-02-05T00:52:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/commit/?id=bc472499298f03ebe5c71920633cfa2b20046c93'/>
<id>urn:sha1:bc472499298f03ebe5c71920633cfa2b20046c93</id>
<content type='text'>
No change to generated assembly.
</content>
</entry>
<entry>
<title>Use the tls_password_cb() callback with all PEM_read_bio_*() calls, so that</title>
<updated>2017-06-22T18:03:57+00:00</updated>
<author>
<name>jsing</name>
<email></email>
</author>
<published>2017-06-22T18:03:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/commit/?id=c9b1852dc910671bb8042219d73820d7a47138dd'/>
<id>urn:sha1:c9b1852dc910671bb8042219d73820d7a47138dd</id>
<content type='text'>
we can prevent libcrypto from going behind our back and trying to read
passwords from standard input (which we may not be permitted to do).

Found by jsg@ with httpd and password protected keys.
</content>
</entry>
<entry>
<title>Use freezero() for the tls_load_file() failure case, since we're</title>
<updated>2017-05-06T21:34:13+00:00</updated>
<author>
<name>jsing</name>
<email></email>
</author>
<published>2017-05-06T21:34:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/commit/?id=f800e2af932fc15fd1b0f859931d131037126b37'/>
<id>urn:sha1:f800e2af932fc15fd1b0f859931d131037126b37</id>
<content type='text'>
potentially dealing with key material. Also switch a calloc to malloc,
since we immediately copy the same amount of data to the newly allocated
buffer.
</content>
</entry>
<entry>
<title>BIO_free_all() and EVP_PKEY_free() can be called with NULL.</title>
<updated>2017-05-06T21:25:15+00:00</updated>
<author>
<name>jsing</name>
<email></email>
</author>
<published>2017-05-06T21:25:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/commit/?id=7fdd55381849b52c576c091fe9567074a3b389be'/>
<id>urn:sha1:7fdd55381849b52c576c091fe9567074a3b389be</id>
<content type='text'>
</content>
</entry>
<entry>
<title>Provide a tls_unload_file() function, that frees the memory returned from</title>
<updated>2017-05-06T20:57:45+00:00</updated>
<author>
<name>jsing</name>
<email></email>
</author>
<published>2017-05-06T20:57:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/commit/?id=7046952f9f5fae47726c165667e46169d74cdfae'/>
<id>urn:sha1:7046952f9f5fae47726c165667e46169d74cdfae</id>
<content type='text'>
a tls_load_file() call, ensuring that it the contents become inaccessible.
This is specifically needed on platforms where the library allocators may
be different from the application allocator.

ok beck@
</content>
</entry>
<entry>
<title>Address some signed vs unsigned warnings and check that an integer value</title>
<updated>2016-11-04T15:59:16+00:00</updated>
<author>
<name>jsing</name>
<email></email>
</author>
<published>2016-11-04T15:59:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/commit/?id=78e68d71838891e44ddbb5238203ccfce3b62d80'/>
<id>urn:sha1:78e68d71838891e44ddbb5238203ccfce3b62d80</id>
<content type='text'>
is positive before passing it to several functions as a size_t.
Additionally, in tls_load_file() there is not much point using calloc(),
when we're immediately reading into the buffer (having an extra byte for
NUL termination seems pointless given the API).

ok beck@ miod@
</content>
</entry>
</feed>
