Rollback 11.0.4+11.2 to resolve macos breakage

[sxa]

The release promoted in #102 has introduced some bad regressions as covered in adoptium/temurin-build#1211 and adoptium/temurin-build#1214 (and maybe elsewhere).

On this basis, despite that fact that this will undo the work which was implemented to assist with issue adoptium/temurin-build#1130 which was implemented under adoptium/temurin-build#1199 I believe the best approach is to roll back these changes to resolve the regressions the updated release has introduced. 11.0.3 did not have the hardend runtime support so this will not result in any regression relative to 11.0.3.

We built a 11.0.4+11.3 (Sent for approval under #103) but I would propose backing out all the changes and, in effect, release the original11.0.4+11 as 11.0.4+11.4 to avoid naming confusion (I'm not sure where .1 went in the history but I'm sure there was a reason for avoiding it.

@AdoptOpenJDK/tsc please we have approvals please?

[gdams]

+1

[lumpfish]

If we build an 11.0.4+11.4, what packaging code will be run? Do we need to back out any installer code changes first?

[gdams]

I think the easiest approach would be to manually copy the binaries from the working release and just edit the json file in the process. That way we don't need to rebuild.

[sxa]

While it might be easier I'm not such a fan of "hacking" this and would prefer to have it done cleanly

[johnoliver]

yeah, if anything its good practice at doing this as this wont be the last time

[gdams]

okay, @sxa555 just remember to rollback the OpenJDK-installer and openjdk-build repo commits.

[lumpfish]

Which commits need to be backed out?
When we tested the 11.0.4+11 were we then still testing unsigned code? If we back out all the installer and build changes does that mean we'll go back to testing unsigned code?

[sxa]

Rollbacks being done under:

• Roll back hardening adoptium/temurin-build#1230
• Roll back hardening adoptium/installer#154

[sxa]

Unanimous agreement in today's TSC call. Tests executing at the moment and awaiting finalisation in #108