<feed xmlns='http://www.w3.org/2005/Atom'>
<title>openbsd/src/lib/libcrypto, branch libressl-v3.5.3</title>
<subtitle>A mirror of https://github.com/libressl/openbsd.git
</subtitle>
<id>https://git.lua4.win/openbsd/atom?h=libressl-v3.5.3</id>
<link rel='self' href='https://git.lua4.win/openbsd/atom?h=libressl-v3.5.3'/>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/'/>
<updated>2022-05-14T15:06:09+00:00</updated>
<entry>
<title>Fix d2i_ASN1_OBJECT()</title>
<updated>2022-05-14T15:06:09+00:00</updated>
<author>
<name>tb</name>
<email></email>
</author>
<published>2022-05-14T15:06:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/commit/?id=9f9c4fab3ed4b876aac3fa82d052dca0c1af9827'/>
<id>urn:sha1:9f9c4fab3ed4b876aac3fa82d052dca0c1af9827</id>
<content type='text'>
Due to a confusion of two CBS, the API would incorrectly advance the
*der_in pointer, resulting in a DER parse failure.

Issue reported by Aram Sargsyan

ok jsing

This is patches/7.1/004_asn1.patch.sig
</content>
</entry>
<entry>
<title>Set ASN1_OBJECT_FLAG_DYNAMIC_DATA flag with t2i_ASN1_OBJECT_internal</title>
<updated>2022-04-10T12:42:33+00:00</updated>
<author>
<name>inoguchi</name>
<email></email>
</author>
<published>2022-04-10T12:42:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/commit/?id=c694612e6569c6b13f7f2c75a3a1c4d9479509c2'/>
<id>urn:sha1:c694612e6569c6b13f7f2c75a3a1c4d9479509c2</id>
<content type='text'>
'flags' should have ASN1_OBJECT_FLAG_DYNAMIC_DATA bit to free 'data'
by ASN1_OBJECT_free as c2i_ASN1_OBJECT_cbs does.

ok jsing@ tb@
</content>
</entry>
<entry>
<title>Avoid infinite loop on parsing DSA private keys</title>
<updated>2022-04-07T17:38:24+00:00</updated>
<author>
<name>tb</name>
<email></email>
</author>
<published>2022-04-07T17:38:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/commit/?id=3340c71f78097b15a0cacb114e0b6c483ad85c02'/>
<id>urn:sha1:3340c71f78097b15a0cacb114e0b6c483ad85c02</id>
<content type='text'>
DSA private keys with ill-chosen g could cause an infinite
loop on deserializing. Add a few sanity checks that ensure
that g is according to the FIPS 186-4: check 1 &lt; g &lt; p and
g^q == 1 (mod p). This is enough to ascertain that g is a
generator of a multiplicative group of order q once we know
that q is prime (which is checked a bit later).

Issue reported with reproducers by Hanno Boeck.
Additional variants and analysis by David Benjamin.

ok beck jsing
</content>
</entry>
<entry>
<title>Avoid infinite loop for custom curves of order 1</title>
<updated>2022-04-07T17:37:25+00:00</updated>
<author>
<name>tb</name>
<email></email>
</author>
<published>2022-04-07T17:37:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/commit/?id=1061feec63ce8eec5e559ca2697b80bc73044484'/>
<id>urn:sha1:1061feec63ce8eec5e559ca2697b80bc73044484</id>
<content type='text'>
If a private key encoded with EC parameters happens to have
order 1 and is used for ECDSA signatures, this causes an
infinite loop since a random integer x in the interval [0,1)
will be 0, so do ... while (x == 0); will loop indefinitely.

Found and reported with a reproducer by Hanno Boeck.
Helpful comments and analysis from David Benjamin.

ok beck jsing
</content>
</entry>
<entry>
<title>man pages: fix some typos found while looking for other issues</title>
<updated>2022-03-31T17:30:05+00:00</updated>
<author>
<name>naddy</name>
<email></email>
</author>
<published>2022-03-31T17:30:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/commit/?id=3d8a2499d7a0a70420723f21fbf735e079a6e74c'/>
<id>urn:sha1:3d8a2499d7a0a70420723f21fbf735e079a6e74c</id>
<content type='text'>
</content>
</entry>
<entry>
<title>man pages: add missing commas between subordinate and main clauses</title>
<updated>2022-03-31T17:27:26+00:00</updated>
<author>
<name>naddy</name>
<email></email>
</author>
<published>2022-03-31T17:27:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/commit/?id=3d8be07546f5ec331a0f851b0ea88212376ebb95'/>
<id>urn:sha1:3d8be07546f5ec331a0f851b0ea88212376ebb95</id>
<content type='text'>
jmc@ dislikes a comma before "then" in a conditional, so leave those
untouched.

ok jmc@
</content>
</entry>
<entry>
<title>Fix leak in ASN1_TIME_adj_internal()</title>
<updated>2022-03-31T13:04:47+00:00</updated>
<author>
<name>tb</name>
<email></email>
</author>
<published>2022-03-31T13:04:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/commit/?id=31dad1243d69de787b0589750cc4b78379c43734'/>
<id>urn:sha1:31dad1243d69de787b0589750cc4b78379c43734</id>
<content type='text'>
p is allocated by asprintf() in one of the *_from_tm() functions, so
it needs to be freed as in the other error path below.

CID 346194

ok jsing
</content>
</entry>
<entry>
<title>Simplify priv_key handling in d2i_ECPrivateKey()</title>
<updated>2022-03-31T13:00:58+00:00</updated>
<author>
<name>tb</name>
<email></email>
</author>
<published>2022-03-31T13:00:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/commit/?id=91087446015ebb4341a9f7c6accff0e586a0ba5d'/>
<id>urn:sha1:91087446015ebb4341a9f7c6accff0e586a0ba5d</id>
<content type='text'>
d2i_EC_PRIVATEKEY() can handle the allocation of priv_key internally,
no need to do this up front and reach it through the dangerous reuse
mechanism. There's also no point in freeing a variable we know to be
NULL.

ok jsing
</content>
</entry>
<entry>
<title>Avoid segfaults in EVP_PKEY_CTX_free()</title>
<updated>2022-03-30T07:17:48+00:00</updated>
<author>
<name>tb</name>
<email></email>
</author>
<published>2022-03-30T07:17:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/commit/?id=c650ef2b4f969ce6b8d9a39f9e86c5e181dfafbc'/>
<id>urn:sha1:c650ef2b4f969ce6b8d9a39f9e86c5e181dfafbc</id>
<content type='text'>
It is possible to call pmeth-&gt;cleanup() with an EVP_PKEY_CTX whose data
is NULL. If pmeth-&gt;init() in int_ctx_new() fails, EVP_PKEY_CTX_free() is
called with such a context. This in turn calls pmeth-&gt;cleanup(), and thus
these cleanup functions must be careful not to use NULL data.  Most of
them are, but one of GOST's functions and HMAC's aren't.

Reported for HMAC by Masaru Masada
https://github.com/libressl-portable/openbsd/issues/129

ok bcook jsing
</content>
</entry>
<entry>
<title>pkey_hmac_init(): use calloc()</title>
<updated>2022-03-30T07:12:30+00:00</updated>
<author>
<name>tb</name>
<email></email>
</author>
<published>2022-03-30T07:12:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/commit/?id=4f0946cf87d94f094252f696625cc100be8bbd76'/>
<id>urn:sha1:4f0946cf87d94f094252f696625cc100be8bbd76</id>
<content type='text'>
Instead of using malloc() and setting most struct members to 0,
simply use calloc().

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