Exécutez n'importe quel Skill dans Manus
en un clic

Exécutez n'importe quel Skill dans Manus en un clic

Commencer

check-payload

Étoiles3

Forks1

Mis à jour19 mai 2026 à 02:40

Run check-payload locally to scan container images for FIPS compliance issues before they block a Konflux release

Installation

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Exécuter dans Manus

Source

ckhordiasma

ckhordiasma/konflux-cookbook

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Exécuter dans Manus

Métiers associésSOC

Basé sur la classification professionnelle SOC

Analystes en assurance qualité des logiciels et testeursProfessions informatiques et mathématiques·SOC 15-1253

SKILL.md

readonly

name	check-payload
description	Run check-payload locally to scan container images for FIPS compliance issues before they block a Konflux release
version	1.0.0

Run check-payload for FIPS Compliance

Read guides/check-payload.md (relative to the plugin root) thoroughly before starting. It is the source of truth for all check-payload details — do not duplicate its content, reference it as you go.

Steps

Check prerequisites: Ask the user what platform they're on (macOS vs Linux) — macOS runs the scan under QEMU emulation, which is slower. Confirm podman is installed and running. Ask whether they've already built the check-payload container image — if not, walk them through the one-time setup from the guide.
Determine what to scan: Ask the user whether they want to scan:
- A registry image (they'll need the full image reference with tag or digest)
- A locally built image (they'll need the local image name/tag)
If they're unsure which image to scan, help them identify the right one — ask what component they're working on and whether they have a recent build.
Run the scan: Follow the manual podman commands in the guide (skopeo copy, umoci unpack, check-payload scan). Let the user know the scan may take a minute. If the image requires registry authentication, help them mount their pull secret.
Interpret results:
- If the scan passes (exit code 0), confirm and move on.
- If it fails, walk through each failure using the "Common FIPS Errors and Fixes" section in the guide. For Go binary errors, point to the specific build flags needed. For OpenSSL/OS errors, identify what needs to change in the base image or Dockerfile.
Handle false positives: If any failures look like false positives (e.g., statically linked binaries that don't do crypto), explain the exception process from the guide. Offer to generate the TOML exception syntax with --print-exceptions and help draft the check-payload PR.
Next steps: Based on what was found, point the user to relevant guides and skills — dockerfile-productization for build flag changes, hermeto-prefetch for hermetic build setup, or conforma for broader release policy validation.

Plus depuis ce dépôt

même dépôt

refine-guide-hermeto

ckhordiasma/konflux-cookbook

Clone a repo with working hermetic builds and compare the implementation against the hermeto guide to identify gaps and improvements

2026-05-193

beaker-vm

ckhordiasma/konflux-cookbook

Provision a VM on Red Hat Beaker for multi-arch testing

2026-05-193

conforma

ckhordiasma/konflux-cookbook

Run Conforma (Enterprise Contract) validation against a Konflux snapshot or a single image to check release policy compliance

2026-05-193

create-pr-pipeline

ckhordiasma/konflux-cookbook

Create a temporary pull request PipelineRun from an existing push PipelineRun to test build changes on an RHOAI release branch

2026-05-193

deploying-to-konflux

ckhordiasma/konflux-cookbook

Deploy locally-working hermetic build configuration into Konflux pipelines for RHOAI components

2026-05-193

dockerfile-productization

ckhordiasma/konflux-cookbook

Productize an upstream Dockerfile for Konflux builds — base image swaps, digest pinning, FIPS compliance, label metadata, and build-arg simplification

2026-05-193

Run check-payload for FIPS Compliance

Steps

Check prerequisites: Ask the user what platform they're on (macOS vs Linux) — macOS runs the scan under QEMU emulation, which is slower. Confirm podman is installed and running. Ask whether they've already built the check-payload container image — if not, walk them through the one-time setup from the guide.

Determine what to scan: Ask the user whether they want to scan:

A registry image (they'll need the full image reference with tag or digest)
A locally built image (they'll need the local image name/tag)

If they're unsure which image to scan, help them identify the right one — ask what component they're working on and whether they have a recent build.

Run the scan: Follow the manual podman commands in the guide (skopeo copy, umoci unpack, check-payload scan). Let the user know the scan may take a minute. If the image requires registry authentication, help them mount their pull secret.

Interpret results:

If the scan passes (exit code 0), confirm and move on.
If it fails, walk through each failure using the "Common FIPS Errors and Fixes" section in the guide. For Go binary errors, point to the specific build flags needed. For OpenSSL/OS errors, identify what needs to change in the base image or Dockerfile.

Handle false positives: If any failures look like false positives (e.g., statically linked binaries that don't do crypto), explain the exception process from the guide. Offer to generate the TOML exception syntax with --print-exceptions and help draft the check-payload PR.

Next steps: Based on what was found, point the user to relevant guides and skills — dockerfile-productization for build flag changes, hermeto-prefetch for hermetic build setup, or conforma for broader release policy validation.