[8u-252] [urgent] 8241823: SignedObject throws NullPointerException for null keys with an initialized Signature object

[Volker Simonis]

Andrew Hughes <gnu.andrew at redhat.com> schrieb am Fr., 3. Apr. 2020, 06:06:
>
> On 02/04/2020 15:11, Volker Simonis wrote:
> > Andrew Hughes, Severin,
> >
> > could please have a quick look at this? I still think it makes sense
> > to bring it into 8u252 and the faster we push it, the more time we'll
> > give others to test it (although I don't expect this change to make
> > any problems - on the contrary, it will save others from investigating
> > TCK failures :)
> >
> > Thank you and best regards,
> > Volker
> >
> > On Tue, Mar 31, 2020 at 11:05 AM Andrew Haley <aph at redhat.com> wrote:
> >>
> >> On 3/31/20 9:43 AM, Volker Simonis wrote:
> >>> I know we're late for 8u252 but I'd still like to bring this trivial
> >>> fix into 8u252 because we think it fixes a serious regression which
> >>> will impact many users:
> >>>
> >>> https://bugs.openjdk.java.net/browse/JDK-8241823
> >>> http://cr.openjdk.java.net/~simonis/webrevs/2020/8241823
> >>
> >> That looks reasonable. OK by me, as long as Andrew Hughes doesn't
> >> object because of time pressure.
> >>
> >> --
> >> Andrew Haley  (he/him)
> >> Java Platform Lead Engineer
> >> Red Hat UK Ltd. <https://www.redhat.com>
> >> https://keybase.io/andrewhaley
> >> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
> >>
> >
>
> It's not just late, we're now frozen for release [0], so there are no
> more public changes to 8u252.
>
> I can include this with the CPU patchset.

I think that's a good idea and I'm fine with that. Could you please
include it into an updated patchset and send that to the VG list. I
think that will give the change enough exposure.

> For cases like this in future,
> it would be better to raise it via the vulnerability group so it isn't
> missed. It's lucky I just spotted this before starting the CPU builds.

Sure, will do so.

> If you want public testing prior to release of 8u252, I suggest pushing
> to 8u-dev (i.e. 8u262). As this is not a public bug, take this as my
> jdk8u-fix-yes for that commit.

Thanks, but I'm not sure. If you'll include it into the 8u252 CPU
patchset, I think that would be enough. I don't particularly like it
if we have multiple instances of the same change in the repository.

> While I think fixing the regression is the right thing to do, I do worry
> that this may create a compatibility difference between OpenJDK 8u and
> the Oracle fork.

Unfortunately, we can't say it either way, because it is a closed bug.
So the Oracle fork may have the fix already or not.

But because it is clearly a regression, I'd rather prefer to prevent
breaking running systems than having 100% compatibility with Oracle
JDK.

> [0] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-March/011476.html
>
> Thanks,
> --
> Andrew :)
>
> Senior Free Java Software Engineer
> Red Hat, Inc. (http://www.redhat.com)
>
> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
> Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
>