[openssl-project] Release Criteria Update

[Richard Levitte]

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.

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/