Add a temporary hack to enable ML-KEM for Post Quantum Cryptography support#811
Add a temporary hack to enable ML-KEM for Post Quantum Cryptography support#811hroyrh wants to merge 1 commit into
Conversation
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
WalkthroughThe Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
📝 Coding Plan
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: hroyrh The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@Dockerfile.ocp`:
- Around line 11-12: The runtime image never receives the PQ crypto policy
because the COPY --from=policy /etc/crypto-policies /etc/crypto-policies is
performed in the builder stage only; update the Dockerfile so the final stage
also copies /etc/crypto-policies from the policy stage into the final image (add
the same COPY --from=policy /etc/crypto-policies /etc/crypto-policies inside the
final stage after its FROM ... AS <final> line), ensuring the path and
ownership/permissions are preserved.
In `@Dockerfile.scos`:
- Around line 11-12: The Dockerfile currently copies /etc/crypto-policies only
into the builder stage (COPY --from=policy /etc/crypto-policies
/etc/crypto-policies) so the final runtime image never receives it; modify the
final/runtime stage to also copy the PQ policy from the policy stage (or from
builder if you prefer) into /etc/crypto-policies (e.g., add a COPY --from=policy
/etc/crypto-policies /etc/crypto-policies inside the final stage after the stage
declaration that produces the shipped image) and ensure file
ownership/permissions are preserved so ML-KEM can use the policy at runtime.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository: openshift/coderabbit/.coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: ebca49b3-320c-47d1-9d74-a0003e6dd62c
📒 Files selected for processing (2)
Dockerfile.ocpDockerfile.scos
| # Temporary hack to enable Post Quantum(PQ) platform support | ||
| COPY --from=policy /etc/crypto-policies /etc/crypto-policies |
There was a problem hiding this comment.
The runtime OCP image still misses the PQ policy.
This COPY only affects builder. The final stage at Line 17 is a new image and never receives /etc/crypto-policies, so the released OCP image will continue using its default crypto policy.
Suggested fix
FROM registry.ci.openshift.org/ocp/4.22:base-rhel9
+COPY --from=policy /etc/crypto-policies /etc/crypto-policies
+
ENV REMOTE_SOURCES=${REMOTE_SOURCES:-"requirements*.cachito"}
ENV REMOTE_SOURCES_DIR=${REMOTE_SOURCES_DIR:-"/remote_sources_dir/"}
ENV PKGS_LIST=main-packages-list.ocp🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@Dockerfile.ocp` around lines 11 - 12, The runtime image never receives the PQ
crypto policy because the COPY --from=policy /etc/crypto-policies
/etc/crypto-policies is performed in the builder stage only; update the
Dockerfile so the final stage also copies /etc/crypto-policies from the policy
stage into the final image (add the same COPY --from=policy /etc/crypto-policies
/etc/crypto-policies inside the final stage after its FROM ... AS <final> line),
ensuring the path and ownership/permissions are preserved.
|
/hold |
openshift-ci
Bot
added
the
do-not-merge/hold
|
/test images |
|
This pr is not needed, we will wait for the right image to be available. |
There was a problem hiding this comment.
🧹 Nitpick comments (2)
Dockerfile.scos (1)
4-4: Use a fixedpolicybase image version/digest, notubi:latest.Using
latestintroduces non-deterministic builds and weakens supply-chain traceability. Pin to a known tag or digest.Suggested change
-FROM registry.redhat.io/ubi9/ubi:latest as policy +ARG POLICY_BASE_IMAGE=registry.redhat.io/ubi9/ubi:9.5 +FROM ${POLICY_BASE_IMAGE} AS policyAs per coding guidelines, "-Focus on major issues impacting performance, readability, maintainability and security. Avoid nitpicks and avoid verbosity."
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@Dockerfile.scos` at line 4, The Dockerfile's build stage named "policy" uses an unpinned base image ("FROM registry.redhat.io/ubi9/ubi:latest as policy"), causing non-deterministic builds; update that FROM line to reference a specific, immutable image tag or digest (e.g., a UBI9 version tag or `@sha256`:... digest) so the "policy" stage is reproducible and supply-chain traceable, and then rebuild/verify the image with the pinned reference.Dockerfile.ocp (1)
4-4: Pin thepolicybase image instead of usingubi:latest.A floating tag makes builds non-reproducible and can change PQ policy behavior unexpectedly over time. Prefer a fixed tag (or digest) for stability and traceability.
Suggested change
-FROM registry.redhat.io/ubi9/ubi:latest as policy +ARG POLICY_BASE_IMAGE=registry.redhat.io/ubi9/ubi:9.5 +FROM ${POLICY_BASE_IMAGE} AS policyAs per coding guidelines, "-Focus on major issues impacting performance, readability, maintainability and security. Avoid nitpicks and avoid verbosity."
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@Dockerfile.ocp` at line 4, The Dockerfile currently uses a floating base image tag in the build stage ("FROM registry.redhat.io/ubi9/ubi:latest as policy"); change this to a pinned, immutable reference (specific version tag or digest) for the "policy" stage to ensure reproducible builds and stable PQ behavior—replace the "ubi:latest" tag with a fixed tag (e.g., a specific ubi9 minor patch tag) or an `@sha256` digest for the registry.redhat.io/ubi9/ubi image so the "policy" build stage always uses the exact same base image.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@Dockerfile.ocp`:
- Line 4: The Dockerfile currently uses a floating base image tag in the build
stage ("FROM registry.redhat.io/ubi9/ubi:latest as policy"); change this to a
pinned, immutable reference (specific version tag or digest) for the "policy"
stage to ensure reproducible builds and stable PQ behavior—replace the
"ubi:latest" tag with a fixed tag (e.g., a specific ubi9 minor patch tag) or an
`@sha256` digest for the registry.redhat.io/ubi9/ubi image so the "policy" build
stage always uses the exact same base image.
In `@Dockerfile.scos`:
- Line 4: The Dockerfile's build stage named "policy" uses an unpinned base
image ("FROM registry.redhat.io/ubi9/ubi:latest as policy"), causing
non-deterministic builds; update that FROM line to reference a specific,
immutable image tag or digest (e.g., a UBI9 version tag or `@sha256`:... digest)
so the "policy" stage is reproducible and supply-chain traceable, and then
rebuild/verify the image with the pinned reference.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 2b022a9f-c37d-46fa-9f60-a0d7ed3bdcd7
📒 Files selected for processing (2)
Dockerfile.ocpDockerfile.scos
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@Dockerfile.ocp`:
- Around line 3-4: The Dockerfile has a `RUN update-crypto-policies --set
DEFAULT:PQ` placed before any `FROM`, which is invalid; move that command into a
build stage by adding a new stage (e.g., a `policy` stage) that starts with a
`FROM` and runs `update-crypto-policies` there, then have later stages inherit
from that stage (or run the `update-crypto-policies` command in each stage that
needs PQ) so the final runtime stage (currently around line 46) either uses
`FROM policy as runtime` or copies the updated policy from the `policy` stage
into the runtime stage; update references to the `policy` stage name
accordingly.
In `@Dockerfile.scos`:
- Around line 3-4: Move the standalone RUN update-crypto-policies into a new
intermediate stage named "policy" that is created FROM the same base image, run
update-crypto-policies in that "policy" stage, and then change the existing
"builder" stage and the final runtime stage to inherit from that policy stage
(use FROM ... AS builder and FROM --from=policy for the final stage) so both
builder and final images pick up the updated crypto policy and the RUN no longer
appears before any FROM.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 09b65fdb-c7e2-4e7e-ad62-64740ac9d5f8
📒 Files selected for processing (2)
Dockerfile.ocpDockerfile.scos
| # Temporary hack to enable Post Quantum(PQ) platform support | ||
| RUN update-crypto-policies --set DEFAULT:PQ |
There was a problem hiding this comment.
RUN before FROM is invalid Dockerfile syntax — build will fail.
A RUN instruction requires a base image context and cannot precede the first FROM. Hadolint correctly flags this as error DL3061.
To apply the crypto policy, the RUN must execute inside a build stage. If PQ policy is needed in multiple stages (including the final runtime image at line 46), each stage must either inherit from a common policy stage or run the command independently:
Suggested approach using a shared policy stage
-# Temporary hack to enable Post Quantum(PQ) platform support
-RUN update-crypto-policies --set DEFAULT:PQ
-
-FROM registry.ci.openshift.org/ocp/4.22:base-rhel9 AS builder
+FROM registry.ci.openshift.org/ocp/4.22:base-rhel9 AS policy
+# Temporary hack to enable Post Quantum(PQ) platform support
+RUN update-crypto-policies --set DEFAULT:PQ
+
+FROM policy AS builderThen also update the final runtime stage to inherit from policy:
-FROM registry.ci.openshift.org/ocp/4.22:base-rhel9
+FROM policy📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| # Temporary hack to enable Post Quantum(PQ) platform support | |
| RUN update-crypto-policies --set DEFAULT:PQ | |
| FROM registry.ci.openshift.org/ocp/4.22:base-rhel9 AS policy | |
| # Temporary hack to enable Post Quantum(PQ) platform support | |
| RUN update-crypto-policies --set DEFAULT:PQ | |
| FROM policy AS builder |
🧰 Tools
🪛 Hadolint (2.14.0)
[error] 4-4: Invalid instruction order. Dockerfile must begin with FROM, ARG or comment.
(DL3061)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@Dockerfile.ocp` around lines 3 - 4, The Dockerfile has a `RUN
update-crypto-policies --set DEFAULT:PQ` placed before any `FROM`, which is
invalid; move that command into a build stage by adding a new stage (e.g., a
`policy` stage) that starts with a `FROM` and runs `update-crypto-policies`
there, then have later stages inherit from that stage (or run the
`update-crypto-policies` command in each stage that needs PQ) so the final
runtime stage (currently around line 46) either uses `FROM policy as runtime` or
copies the updated policy from the `policy` stage into the runtime stage; update
references to the `policy` stage name accordingly.
| # Temporary hack to enable Post Quantum(PQ) platform support | ||
| RUN update-crypto-policies --set DEFAULT:PQ |
There was a problem hiding this comment.
Same invalid RUN before FROM — mirrors Dockerfile.ocp.
As with Dockerfile.ocp, this RUN precedes any FROM and will cause the build to fail (Hadolint DL3061). Apply the same fix: create a policy stage from the base image, run the crypto-policy command there, then have both builder (line 6) and the final stage (line 13) inherit from it.
Suggested fix
-# Temporary hack to enable Post Quantum(PQ) platform support
-RUN update-crypto-policies --set DEFAULT:PQ
-
-FROM quay.io/centos/centos:stream9 AS builder
+FROM quay.io/centos/centos:stream9 AS policy
+# Temporary hack to enable Post Quantum(PQ) platform support
+RUN update-crypto-policies --set DEFAULT:PQ
+
+FROM policy AS builderAnd for the final runtime stage:
-FROM quay.io/centos/centos:stream9
+FROM policy🧰 Tools
🪛 Hadolint (2.14.0)
[error] 4-4: Invalid instruction order. Dockerfile must begin with FROM, ARG or comment.
(DL3061)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@Dockerfile.scos` around lines 3 - 4, Move the standalone RUN
update-crypto-policies into a new intermediate stage named "policy" that is
created FROM the same base image, run update-crypto-policies in that "policy"
stage, and then change the existing "builder" stage and the final runtime stage
to inherit from that policy stage (use FROM ... AS builder and FROM
--from=policy for the final stage) so both builder and final images pick up the
updated crypto policy and the RUN no longer appears before any FROM.
…upport Signed-off-by: Himanshu Roy <hroy@redhat.com>
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@prepare-image.sh`:
- Around line 11-13: Guard the post-quantum policy activation by making the
install/enable conditional: only attempt to install crypto-policies-scripts if
the package is available (check with rpm -q or dnf list), check that the
DEFAULT:PQ profile exists/is supported (e.g., use update-crypto-policies --show
or --list to verify) before calling update-crypto-policies --set DEFAULT:PQ, and
skip this whole block when the system is in FIPS mode (detect via
/etc/system-fips or /proc/cmdline). If any check fails, emit a clear log message
and continue without changing the global crypto policy. Ensure you reference the
exact commands in the script: crypto-policies-scripts and update-crypto-policies
--set DEFAULT:PQ, and the FIPS detection using /etc/system-fips or
/proc/cmdline.
| # Enable PQC | ||
| dnf install -y crypto-policies-scripts | ||
| update-crypto-policies --set DEFAULT:PQ |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, find and inspect the prepare-image.sh file
find . -name "prepare-image.sh" -type fRepository: openshift/ironic-image
Length of output: 84
🏁 Script executed:
# List repository structure to understand context
git ls-files | head -20Repository: openshift/ironic-image
Length of output: 438
🏁 Script executed:
# Read the prepare-image.sh file to verify the context
wc -l ./prepare-image.shRepository: openshift/ironic-image
Length of output: 87
🏁 Script executed:
# Read the file with line numbers
cat -n ./prepare-image.shRepository: openshift/ironic-image
Length of output: 2903
🌐 Web query:
update-crypto-policies DEFAULT:PQ profile availability RHEL Fedora crypto-policies-scripts
💡 Result:
The DEFAULT:PQ profile is a valid system-wide cryptographic subpolicy that enables post-quantum cryptography (PQC) algorithms, such as hybrid ML-KEM (e.g., ML-KEM-768 with X25519) and ML-DSA, on top of the DEFAULT policy. It is available in RHEL 9.7+ and RHEL 10+, and in recent Fedora releases (e.g., Fedora 42, 43, rawhide) via the crypto-policies package. To use it: 1. Ensure crypto-policies-scripts is installed: sudo dnf install crypto-policies-scripts 2. Set the policy: sudo update-crypto-policies --set DEFAULT:PQ 3. Reboot for full effect: sudo reboot 4. Verify: update-crypto-policies --show In RHEL 10.0, PQC required the crypto-policies-pq-preview package and TEST-PQ subpolicy (Technology Preview). From RHEL 10.1, PQC (including PQ subpolicy support) is enabled by default in predefined policies; use NO-PQ to disable. Fedora integrates upstream changes from the fedora-crypto-policies GitLab repo, including PQ support in modules like TEST-PQ.pmod and NO-PQ.pmod, with recent changelogs confirming ML-KEM/ML-DSA integration.
Citations:
- 1: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/security_hardening/using-the-system-wide-cryptographic-policies_security-hardening
- 2: https://docs.redhat.com/documentation/red_hat_enterprise_linux/10/html/security_hardening/using-system-wide-cryptographic-policies
- 3: https://packages.fedoraproject.org/pkgs/crypto-policies/crypto-policies-scripts/fedora-43.html
- 4: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/10.0_release_notes/technology-preview-features
- 5: https://packages.fedoraproject.org/pkgs/crypto-policies/crypto-policies/fedora-43-updates.html
- 6: https://www.redhat.com/en/blog/post-quantum-cryptography-red-hat-enterprise-linux-10
- 7: https://packages.fedoraproject.org/pkgs/crypto-policies/crypto-policies/fedora-42.html
- 8: https://packages.fedoraproject.org/pkgs/crypto-policies/crypto-policies/fedora-43.html
🌐 Web query:
crypto-policies PQ.pmod module post-quantum DEFAULT:PQ
💡 Result:
The PQ.pmod is a policy module file in the crypto-policies system used in RHEL, Fedora, and derivatives like Oracle Linux for enabling post-quantum cryptography (PQC) algorithms system-wide. It is located at /usr/share/crypto-policies/policies/modules/PQ.pmod (or TEST-PQ.pmod in earlier tech preview versions). To enable it: sudo update-crypto-policies --set DEFAULT:PQ (requires crypto-policies-pq-preview package in older versions; integrated in RHEL 10.1+ DEFAULT policy). Reboot to apply. It prioritizes hybrid ML-KEM (e.g., MLKEM768-X25519) key exchange and ML-DSA signatures in TLS/SSH/etc., protecting against quantum "harvest now, decrypt later" attacks. Supported in OpenSSL, GnuTLS, NSS, OpenSSH. .pmod files modify base policies (.pol) by adding (+item) or removing (-item) algorithms, e.g., +MLKEM768-X25519 to group= list with highest priority.
Citations:
- 1: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/security_hardening/using-the-system-wide-cryptographic-policies_security-hardening
- 2: https://www.redhat.com/en/blog/whats-new-post-quantum-cryptography-rhel-101
- 3: https://www.redhat.com/en/blog/post-quantum-cryptography-red-hat-enterprise-linux-10
- 4: https://packages.fedoraproject.org/pkgs/crypto-policies/crypto-policies/fedora-43.html
🌐 Web query:
update-crypto-policies --set FIPS override behavior unintended
💡 Result:
The command update-crypto-policies --set FIPS sets the system-wide cryptographic policy to the FIPS level on RHEL and compatible systems (e.g., AlmaLinux, Rocky Linux). This configures cryptographic backends like OpenSSL, GnuTLS, NSS, and others to use only FIPS-approved algorithms by generating policy files in /etc/crypto-policies/back-ends/. No widespread bugs or unintended override behaviors were found in official documentation for this specific command on the host system. It behaves as documented: it overwrites /etc/crypto-policies/config with "FIPS", applies the policy (unless --no-reload is used), and recommends a reboot for full effect since policies load at application startup. Potential related issues include: - Running without root privileges causes "permission denied" errors. - update-crypto-policies --check may report mismatches if back-end files were manually edited or after package updates without re-running the command. - In containers (e.g., Podman on FIPS-enabled hosts), Podman intentionally bind-mounts host FIPS back-ends but strips subpolicy modifiers (e.g., FIPS:TEST-MOD shows as plain FIPS inside container). This is by design to avoid config incompatibilities between host/container library versions; run update-crypto-policies inside the container or build custom images. - fips-mode-setup --enable (for full FIPS mode) sets plain FIPS even if a subpolicy like FIPS:OSPP was active, requiring re-application afterward (fixed in later versions). - Some apps (e.g., sshd in FIPS mode) may need explicit config includes (RHEL 9: Include /etc/crypto-policies/back-ends/opensshserver.config in sshd_config; RHEL 8 uses systemd). Testing sshd -T requires sourcing the policy file for accurate runtime view. - Ubuntu's crypto-policies package generates files but lacks integration, so policies have no effect. For full FIPS compliance, use fips-mode-setup --enable (adds fips=1 kernel param, dracut module), regenerate keys, and reboot. update-crypto-policies --set FIPS alone does not enable kernel FIPS mode or guarantee FIPS 140 compliance.
Citations:
- 1: https://manpages.ubuntu.com/manpages/focal/en/man8/update-crypto-policies.8.html
- 2: https://oneuptime.com/blog/post/2026-03-04-view-change-system-wide-crypto-policies-rhel-9/view
- 3: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/security_hardening/using-the-system-wide-cryptographic-policies_security-hardening
- 4: https://man.linuxreviews.org/man8/update-crypto-policies.8.html
- 5: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/security_hardening/switching-rhel-to-fips-mode_security-hardening
- 6: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/using-the-system-wide-cryptographic-policies_security-hardening
- 7: https://security.stackexchange.com/questions/278931/rhel-in-fips-mode-ignores-crypto-subpolicy
- 8: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/security_hardening/switching-rhel-to-fips-mode_security-hardening
- 9: https://manpages.opensuse.org/Leap-16.0/crypto-policies-scripts/fips-mode-setup.8.en.html
- 10: https://bugzilla.redhat.com/show_bug.cgi?id=1804193
- 11: Podman ignores FIPS policy modifiers containers/podman#23214
🏁 Script executed:
# Check the Dockerfiles for base images and FIPS-related content
head -20 Dockerfile.fcos Dockerfile.ocp Dockerfile.okd Dockerfile.scos 2>/dev/null | grep -E "FROM|FIPS|crypto|RUN.*prepare-image"Repository: openshift/ironic-image
Length of output: 398
🏁 Script executed:
# More comprehensive check of all Dockerfiles for prepare-image.sh invocation and base images
for f in Dockerfile.*; do
echo "=== $f ==="
head -30 "$f"
doneRepository: openshift/ironic-image
Length of output: 3836
🏁 Script executed:
# Verify OS versions in the base images to see DEFAULT:PQ support likelihood
rg "crypto-policies|DEFAULT:PQ|PQ\.pmod" --type shell --type bashRepository: openshift/ironic-image
Length of output: 95
🏁 Script executed:
# Check if there's any version pinning or OS version info in comments/docs
cat README.md | head -50Repository: openshift/ironic-image
Length of output: 2329
Guard PQ policy activation; unconditional global override risks build failures and FIPS compliance.
Lines 12–13 unconditionally enable post-quantum cryptography under strict error mode (line 3). This can break builds when DEFAULT:PQ profile or PQ.pmod module is unavailable in the base image, and unintentionally overrides FIPS-configured environments—a concern given the existing FIPS awareness in the script (lines 34–36).
Suggested hardening
-# Enable PQC
-dnf install -y crypto-policies-scripts
-update-crypto-policies --set DEFAULT:PQ
+# Enable PQC (explicit opt-in)
+if [[ "${ENABLE_PQC:-false}" == "true" ]]; then
+ dnf install -y crypto-policies-scripts
+
+ current_policy="$(update-crypto-policies --show || true)"
+ if [[ "${current_policy}" == FIPS* ]]; then
+ echo "Refusing to override FIPS crypto policy with DEFAULT:PQ" >&2
+ exit 1
+ fi
+
+ if [[ -f /usr/share/crypto-policies/policies/modules/PQ.pmod ]]; then
+ update-crypto-policies --set DEFAULT:PQ
+ else
+ echo "PQC policy module (PQ.pmod) not available in this image" >&2
+ exit 1
+ fi
+fi📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| # Enable PQC | |
| dnf install -y crypto-policies-scripts | |
| update-crypto-policies --set DEFAULT:PQ | |
| # Enable PQC (explicit opt-in) | |
| if [[ "${ENABLE_PQC:-false}" == "true" ]]; then | |
| dnf install -y crypto-policies-scripts | |
| current_policy="$(update-crypto-policies --show || true)" | |
| if [[ "${current_policy}" == FIPS* ]]; then | |
| echo "Refusing to override FIPS crypto policy with DEFAULT:PQ" >&2 | |
| exit 1 | |
| fi | |
| if [[ -f /usr/share/crypto-policies/policies/modules/PQ.pmod ]]; then | |
| update-crypto-policies --set DEFAULT:PQ | |
| else | |
| echo "PQC policy module (PQ.pmod) not available in this image" >&2 | |
| exit 1 | |
| fi | |
| fi |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@prepare-image.sh` around lines 11 - 13, Guard the post-quantum policy
activation by making the install/enable conditional: only attempt to install
crypto-policies-scripts if the package is available (check with rpm -q or dnf
list), check that the DEFAULT:PQ profile exists/is supported (e.g., use
update-crypto-policies --show or --list to verify) before calling
update-crypto-policies --set DEFAULT:PQ, and skip this whole block when the
system is in FIPS mode (detect via /etc/system-fips or /proc/cmdline). If any
check fails, emit a clear log message and continue without changing the global
crypto policy. Ensure you reference the exact commands in the script:
crypto-policies-scripts and update-crypto-policies --set DEFAULT:PQ, and the
FIPS detection using /etc/system-fips or /proc/cmdline.
|
/test images |
1 similar comment
|
/test images |
|
/retest-required |
|
@hroyrh: all tests passed! Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
🐛 fix: correct dhcp tag for ipv6 pxe
2 participants
Summary by CodeRabbit