On 07/09/18 10:09, Richard Levitte wrote:
> In message <bb7d9b84-f8df-00b0-c5b4-eef354d82...@openssl.org> on Fri, 7 Sep
> 2018 09:56:01 +0100, Matt Caswell <m...@openssl.org> said:
>> On 07/09/18 01:51, Richard Levitte wrote:
>>> I think this one should be part of the lot as well:
>>> 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.
openssl-project mailing list