[openssl-project] Release Criteria Update

Matt Caswell matt at openssl.org
Fri Sep 7 09:17:11 UTC 2018



On 07/09/18 10:09, Richard Levitte wrote:
> In message <bb7d9b84-f8df-00b0-c5b4-eef354d82869 at openssl.org> on Fri, 7 Sep 2018 09:56:01 +0100, Matt Caswell <matt at openssl.org> said:
> 
>>
>>
>> On 07/09/18 01:51, Richard Levitte wrote:
>>> I think this one should be part of the lot as well:
>>>
>>> #7144
>>> ASN.1 DER: Make INT32 / INT64 types read badly encoded LONG zeroes
>>>
>>> For example, *all* two-prime RSA keys from pre-1.1.1 become unreadable
>>> in 1.1.1, because pre-1.1.1 encodes the version indicator (zero) as
>>> 02 00 (zero length INTEGER, which is invalid) instead of 02 01 00
>>> (proper zero).  That's simply because the internal version number was
>>> changed from a LONG (custom ASN.1 type, mapping to a C long) to a INT32
>>> (new custom ASN.1 type, mapping to a C int32).
>>> (no, we don't want to go back to using LONG)
>>
>> So...that PR seems to be labelled for 1.1.0 too? So why is the problem
>> specific to 1.1.1?
> 
> Because of commit 6a32a3c058dbd9fa7cec5b020e4f027808972e4a, which is
> only present in master.  In that commit, we switch a number of uses of
> LONGs (all the remaining) to INT32.
> 
> Of course, one way would be to revert that commit, but that doesn't
> fix the actual issue with INT32 not reading in a backward compatible
> way (that issue exists in 1.1.0 as well).
> 
> So yeah, in summary, it's a regression that exists only in 1.1.1, but
> is really caused by a bug that exists in 1.1.0 as well.
> 
> I hope that's a good enough explanation.

Makes sense.

Matt



More information about the openssl-project mailing list