<feed xmlns='http://www.w3.org/2005/Atom'>
<title>openbsd/src/lib/libcrypto/asn1, branch libressl-v3.4.1</title>
<subtitle>A mirror of https://github.com/libressl/openbsd.git
</subtitle>
<id>https://git.lua4.win/openbsd/atom?h=libressl-v3.4.1</id>
<link rel='self' href='https://git.lua4.win/openbsd/atom?h=libressl-v3.4.1'/>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/'/>
<updated>2021-09-02T12:41:44+00:00</updated>
<entry>
<title>Lay groundwork to support X.509 v3 extensions for IP Addresses and AS Identifiers</title>
<updated>2021-09-02T12:41:44+00:00</updated>
<author>
<name>job</name>
<email></email>
</author>
<published>2021-09-02T12:41:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/commit/?id=3ed206d7bde4191b37ba53a167ddc2090f5e4860'/>
<id>urn:sha1:3ed206d7bde4191b37ba53a167ddc2090f5e4860</id>
<content type='text'>
These extensions are defined in RFC 3779 and used in the RPKI (RFC 6482, RFC 8360).
Imported from OpenSSL 1.1.1j (aaf2fcb575cdf6491b98ab4829abf78a3dec8402b8b81efc8f23c00d443981bf)
This changeset is a no-op, as there are 10+ issues and at least 2 security issues.
Work will continue in-tree.

OK tb@, discussed with beck@
</content>
</entry>
<entry>
<title>Zap blanks before tabs.</title>
<updated>2021-08-28T08:22:48+00:00</updated>
<author>
<name>tb</name>
<email></email>
</author>
<published>2021-08-28T08:22:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/commit/?id=c93f167815632d920b3a51ad67dbdac3c395179c'/>
<id>urn:sha1:c93f167815632d920b3a51ad67dbdac3c395179c</id>
<content type='text'>
</content>
</entry>
<entry>
<title>Fix various read buffer overflow when printing ASN.1 strings (which are</title>
<updated>2021-08-24T15:23:03+00:00</updated>
<author>
<name>tb</name>
<email></email>
</author>
<published>2021-08-24T15:23:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/commit/?id=52abe2974a6ccf1fbf26a380d1f675aacc9aae28'/>
<id>urn:sha1:52abe2974a6ccf1fbf26a380d1f675aacc9aae28</id>
<content type='text'>
not necessarily NUL terminated). Same as schwarze's fix in t_x509a.c r1.9.

From David Benjamin and Matt Caswell (part of the fixes in OpenSSL 1.1.1l)

ok inoguchi
</content>
</entry>
<entry>
<title>Add error checks for i2d_X509_NAME()</title>
<updated>2021-07-26T16:54:20+00:00</updated>
<author>
<name>tb</name>
<email></email>
</author>
<published>2021-07-26T16:54:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/commit/?id=d451f46105c4e36fe5a7fd74ba8e22091d8511dd'/>
<id>urn:sha1:d451f46105c4e36fe5a7fd74ba8e22091d8511dd</id>
<content type='text'>
This avoids potential malloc(-1) and malloc(0), spotted by schwarze
while documenting X509_ocspid_print().

ok schwarze
</content>
</entry>
<entry>
<title>Fix a read buffer overrun in X509_CERT_AUX_print(3),</title>
<updated>2021-07-10T17:45:16+00:00</updated>
<author>
<name>schwarze</name>
<email></email>
</author>
<published>2021-07-10T17:45:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/commit/?id=9cc8c5c14a3841b57172d4f4c8ef4f4b337398d4'/>
<id>urn:sha1:9cc8c5c14a3841b57172d4f4c8ef4f4b337398d4</id>
<content type='text'>
which by implication also affects X509_print(3).

The ASN1_STRING_get0_data(3) manual explitely cautions the reader
that the data is not necessarily NUL-terminated, and the function
X509_alias_set1(3) does not sanitize the data passed into it in
any way either, so we must assume the alias-&gt;data field is merely
a byte array and not necessarily a string in the sense of the C
language.

I found this bug while writing manual pages for these functions.

OK tb@

As an aside, note that the function still produces incomplete and
misleading results when the data contains a NUL byte in the middle
and that error handling is consistently absent throughout, even
though the function provides an "int" return value obviously intended
to be 1 for success and 0 for failure, and even though this function
is called by another function that also wants to return 1 for success
and 0 for failure and even does so in many of its code paths, though
not in others.  But let's stay focussed.  Many things would be nice
to have in the wide wild world, but a buffer overflow must not be
allowed to remain in our backyard.
</content>
</entry>
<entry>
<title>Fix a bug in X509_print_ex(3).</title>
<updated>2021-07-06T11:26:25+00:00</updated>
<author>
<name>schwarze</name>
<email></email>
</author>
<published>2021-07-06T11:26:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/commit/?id=84591be6964a33e26a27765180efae3d29c3c04f'/>
<id>urn:sha1:84591be6964a33e26a27765180efae3d29c3c04f</id>
<content type='text'>
If the user set nmflags == X509_FLAG_COMPAT and X509_NAME_print_ex(3)
failed, the error return value of 0 was misinterpreted as an indicator
of success, causing X509_print_ex(3) to ignore the error, continue
printing, and potentially return successfully even though not all
the content of the certificate was printed.

The X509_NAME_print_ex(3) manual page explains that this function
indicates failure by returning 0 if nmflags == X509_FLAG_COMPAT
and by returning -1 if nmflags != X509_FLAG_COMPAT.
That's definitely atrocious API design (witnessed by the
complexity of the code needed for correct error checking),
but changing the API contract and becoming incompatible
with OpenSSL would make matters even worse.

Note that just checking for &lt;= 0 in all cases would not be correct
either because X509_NAME_print_ex(3) returns 0 to indicate that it
successfully printed zero bytes in some cases, for example when all
three of the following conditions hold:
1. nmflags != X509_FLAG_COMPAT
2. indent == 0 (which X509_print_ex(3) does use in some cases)
3. the name object is NULL or empty

I found the bug by code inspection and proposed an incomplete patch,
then jsing@ proposed this improved version of the patch.
OK jsing@.
</content>
</entry>
<entry>
<title>Bugfix: when X509_NAME_dup(3) failed, X509_NAME_set(3) indicated success</title>
<updated>2021-07-04T11:38:37+00:00</updated>
<author>
<name>schwarze</name>
<email></email>
</author>
<published>2021-07-04T11:38:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/commit/?id=a06339d81445a0884fa78a518c413221f7898012'/>
<id>urn:sha1:a06339d81445a0884fa78a518c413221f7898012</id>
<content type='text'>
even though it did not actually set the name.
Instead, indicate failure in this case.

This commit sneaks in a small, unrelated change in behaviour.
If the first argument of X509_NAME_set(3) was NULL, the function
used to return failure.  Now it crashes the program by accessing
the NULL pointer, for compatibility with the same change in OpenSSL.

This merges the following two commits from the OpenSSL-1.1.1 branch,
which is still available under a free license:
1. 180794c5  Rich Salz        Sep  3 11:33:34 2017 -0400
2. c1c1783d  Richard Levitte  May 17 09:53:14 2018 +0200

OK tb@
</content>
</entry>
<entry>
<title>Plug leak in c2i_ASN1_OBJECT</title>
<updated>2021-05-01T13:16:30+00:00</updated>
<author>
<name>tb</name>
<email></email>
</author>
<published>2021-05-01T13:16:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/commit/?id=be451ae58527f84289f4ad8c0ebc74bb5995f2df'/>
<id>urn:sha1:be451ae58527f84289f4ad8c0ebc74bb5995f2df</id>
<content type='text'>
When using the object reuse facility of c2i_ASN1_OBJECT, the dynamically
allocated strings a may contain are set to NULL, so we must free them
beforehand. Also clear the flag, because that's what OpenSSL chose to do.

From Richard Levitte OpenSSL 1.1.1 65b88a75921533ada8b465bc8d5c0817ad927947

ok inoguchi
</content>
</entry>
<entry>
<title>Remove two reduntat memset calls.</title>
<updated>2020-12-16T18:46:29+00:00</updated>
<author>
<name>tb</name>
<email></email>
</author>
<published>2020-12-16T18:46:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/commit/?id=6beaabfe49252420dfbd80598c2dc71f85ea6a6f'/>
<id>urn:sha1:6beaabfe49252420dfbd80598c2dc71f85ea6a6f</id>
<content type='text'>
pointed out by jsing
</content>
</entry>
<entry>
<title>Avoid potential use of uninitialized in ASN1_time_parse</title>
<updated>2020-12-16T18:35:59+00:00</updated>
<author>
<name>tb</name>
<email></email>
</author>
<published>2020-12-16T18:35:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/commit/?id=25fba608b24a7bf868f7cd6c3cb19e964a7ffcd4'/>
<id>urn:sha1:25fba608b24a7bf868f7cd6c3cb19e964a7ffcd4</id>
<content type='text'>
When parsing an UTCTime into a struct tm that wasn't cleared by the caller,
the years would be added to the already present value, which could give an
incorrect result.  This is an issue in ASN1_UTCTIME_cmp_time_t(), which is
practically unused.  Fix this by always zeroing the passed struct tm.

Issue reported by Olivier Taïbi, thanks!

ok jsing
</content>
</entry>
</feed>
