linux 6.12.103-10: strip canister Kconfig symbols when fips=0

[dcasota]

Rebased from 6.12.87-2 onto the current 5.0 head (6.12.103-9), which clears the CONFLICTING state this PR had been sitting in.

The defect (unchanged upstream)

When fips=0 — the aarch64 default, or an explicit x86_64 override — neither the %if 0%{?canister_build} nor the %if 0%{?canister_usage} branch in %prep runs, so the patch that introduces the GCC_PLUGIN_{MATCH,PAD}_CANISTER_STRUCTS Kconfig symbols is never applied. The shipped .config still carries their is not set comments, make olddefconfig silently drops them, and the check_for_config_applicability.inc diff guard then fails %prep.

Verified still present on vmware/photon@5.0 at 6.12.103-10: the canister seds sit at lines 692-697 guarded only by canister_build/canister_usage, with no fips=0 path.

The change

One guarded sed in %prep that strips the two comments up-front when fips=0, plus the release bump and changelog entry.

Passes support/spec-checker/check_spec.py cleanly (exit 0).

[dcasota]

Part of the Photon 5.0 installer/build fix set tracked for replication to vmware/photon. Related PRs:

• photon-os-installer 2.8-5: interactive install, STIG package set, initrd locale #19 — photon-os-installer 2.8-5 (interactive install fix + /etc/os-release UI overlay fix + btrfs-progs)
• stig-hardening: first-boot SELinux relabel + FIPS PAM (default and subrelease-90) #9 — stig-hardening 2.1-8 (first-boot SELinux relabel + FIPS PAM)

Installer-source changes upstreamed at dcasota/photon-os-installer#7 (interactive install) and dcasota/photon-os-installer#8 (tdnf output capture).

[dcasota]

Superseded by #24.

#24 moves this same fix into the new shared SPECS/linux/canister_config.inc, included by both linux.spec and linux-esx.spec, so the generic and ESX flavours can no longer diverge on the canister .config handling — which is what caused this bug in the first place (linux-esx.spec had always handled fips=0 correctly in its %else; linux.spec had no %else at all).

One behavioural note: #24 replaces this PR's broad sed

sed -i '/CONFIG_GCC_PLUGIN_MATCH_CANISTER_STRUCTS/d;/CONFIG_GCC_PLUGIN_PAD_CANISTER_STRUCTS/d' .config

with linux-esx's narrower pair matching only the # … is not set comment form. Verified equivalent by running both against all five shipped config files — byte-identical output in every case, because no config contains a CANISTER_STRUCTS=y form.

The two PRs touch the same lines and will conflict, so only one should be merged. #24 is the one to take; this can be closed once that is confirmed.

[dcasota]

Closing as superseded by #24, after verifying equivalence across the full permutation set rather than by inspection.

Behavioural equivalence — 36/36 cells identical. Compared the expanded %prep of both branches across arch {x86_64, aarch64} x subrelease {91, 92} x 9 flag combinations (default, canister_build 0/1, acvp_build, kat_build, acvp+cb, kat+acvp+cb, -D fips 0, -D fips 1). Every cell selects the same canister branches on both branches:

cell	effect on both
x86_64 default / fips forced either way	MATCHy (canister_usage)
x86_64 canister_build=1, kat, acvp+cb	delMATCH PADy
aarch64 default / canister_build either / fips forced	delMATCH delPAD — the cell this PR fixed
aarch64 acvp_build=1	MATCHy (acvp forces fips=1)
aarch64 kat, acvp+cb	delMATCH PADy

Sed-form equivalence — proven, not assumed. The branch-selection matrix above only shows the same branches fire; the two PRs use textually different seds there. This PR's broad form and #24's narrower pair were therefore executed against every shipped kernel config:

config_aarch64        IDENTICAL
config-esx_aarch64    IDENTICAL
config_x86_64         IDENTICAL
config-esx_x86_64     IDENTICAL
config_x86_64_acvp    IDENTICAL

They agree because no config contains a CANISTER_STRUCTS=y form — only the # ... is not set comment form, which is exactly what the narrow pair matches.

#24 is a strict superset. It also repairs linux-esx.spec and moves the logic into the shared canister_config.inc, so the generic and ESX flavours can no longer drift apart — which is what produced this bug in the first place. #24 is currently MERGEABLE/CLEAN and its include carries the %if 0%{?fips} == 0 branch.

No dependencies. No open PR in this fork or in vmware/photon uses linux-fips0-canister-kconfig-strip as head or base, and upstream has no branch of that name, so deleting it costs nothing.

Nothing is lost by closing this; take #24 instead.