Bug 1221225

Summary:	[Build 2.271] openQA test fails in installation because unsigned .appx
Product:	[openSUSE] PUBLIC SUSE Linux Enterprise Server 15 SP6	Reporter:	Pablo Herranz Ramírez <pablo.herranz>
Component:	WSL	Assignee:	E-mail List <sle-ms>
Status:	RESOLVED FIXED	QA Contact:	QE Containers and Public Cloud team qa-c <qa-c>
Severity:	Normal
Priority:	P2 - High	CC:	scott.bradnick, swayammitra.tripathy
Version:	unspecified
Target Milestone:	---
Hardware:	Other
OS:	Other
URL:	https://openqa.suse.de/tests/13752430/modules/install_wsl/steps/20
Whiteboard:
Found By:	openQA	Services Priority:
Business Priority:		Blocker:	Yes
Marketing QA Status:	---	IT Deployment:	---
Attachments:	New signkey is either wrong, unusable in current state or broken overall

Description Pablo Herranz Ramírez 2024-03-11 08:41:12 UTC

## Observation

openQA test in scenario sle-15-SP6-Windows 10 BIOS-x86_64-wsl-main+register@win10_64bit fails in
[install_wsl](https://openqa.suse.de/tests/13752430/modules/install_wsl/steps/20)

## Test suite description
Basic WSL test Test scope:
    1) Prepare WSL and other features in Windows
    2) Download the image
    3) Import embedded certificate from the image
    4) Load image
    5) Define users
    6) Register SUT
    7) Exit WSL



## Reproducible

Fails since (at least) Build [2.265](https://openqa.suse.de/tests/13749186)


## Expected result

Last good: [2.257](https://openqa.suse.de/tests/13742337) (or more recent)


## Further details

Always latest result in this scenario: [latest](https://openqa.suse.de/tests/latest?arch=x86_64&distri=sle&flavor=Windows+10+BIOS&machine=win10_64bit&test=wsl-main%2Bregister&version=15-SP6)

Seems like the downloaded package was not signed, causing the installation to fail.

Comment 1 Scott Bradnick 2024-03-12 18:23:20 UTC

Created attachment 873452 [details]
New signkey is either wrong, unusable in current state or broken overall

The resulting .appx builds have started using "SUSE Linux Enterprise Secure Boot Signkey" which is signed by "SUSE Linux Enterprise Secure Boot CA" vs "15720A30-FA72-4BF5-8077-C1376E0B561C" (also signed by that CA) and that *new* signkey is either broken or there's just no way that swap of signing keys was ever going to work.

Comment 2 Scott Bradnick 2024-03-12 18:29:56 UTC

SUSE:SLE-15-SP6:Update:WSL has been using v0.4 of appx-util since inception and that's been building fine until February 17, 2024 04:59 - I'm sure it's been using that last good build even after it fails to [re]build.

Maybe something on a larger scale changed on the openssl-3 side and now v0.5 is _required_ ==> https://build.suse.de/request/show/323804

At any rate, can't hurt 👍

Comment 3 Swayammitra Tripathy 2024-03-20 15:01:19 UTC

Hello Scott,

Do you have any update on this?

Comment 4 Scott Bradnick 2024-03-20 15:05:36 UTC

The appx-util package wasn't the direct cause of the issue, but it's been updated to v0.5 for openssl-3 compatibility as it seems that was updated in SLE-15-SP6 overall.

I don't know that "because unsigned .appx" was technically true, as it was signed - but signed improperly because the autobuild team made a SLE-15-SP6 wide certificate change but didn't include the WSL contingency in that change.

After I emailed them about the issue of "SUSE Linux Enterprise Secure Boot CA" vs "15720A30-FA72-4BF5-8077-C1376E0B561C" - they fixed it and we get a properly signed .appx ...

There seem to be other issues w/ the WSL image itself in openQA, but a usable .appx shouldn't be a problem going forward.