redhat-et / redhat-et/skillimage

feat: sign and verify skill images with Sigstore/Cosign

Open
#28 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
HTML
Stars
9
Forks
3
Avg merge
18m
Merged PRs (30d)
1

Description

Summary

Implement cryptographic signing and verification of skill images using Sigstore/Cosign, enabling supply chain security for distributed skills.

Motivation

Unsigned skill registries are a supply chain risk. The ClawHavoc incident (Feb 2026) saw 341 malicious skills on ClawHub — signing is essential for trust in distributed skill ecosystems.

Users need to:

  • Sign skill images when publishing to registries
  • Verify signatures when pulling/installing skills
  • Trust that a skill hasn't been tampered with after publication

Current state

The design docs (docs/design/2026-04-15-oci-skill-registry-design.md, lines 757–961) have extensive specifications for RHTAS integration, but nothing is implemented:

Component Status
pkg/verify/ package Planned in CLAUDE.md, directory doesn't exist
skillctl sign command Not implemented
skillctl verify command Not implemented
sigstore-go dependency Not in go.mod
Cosign integration Not started

Proposed CLI

# Sign a skill image (keyless, OIDC-based)
skillctl sign quay.io/skillimage/summarize:v1.2.0

# Sign with a key pair
skillctl sign --key cosign.key quay.io/skillimage/summarize:v1.2.0

# Verify a skill image
skillctl verify quay.io/skillimage/summarize:v1.2.0

# Verify with a specific public key
skillctl verify --key cosign.pub quay.io/skillimage/summarize:v1.2.0

# Pull with mandatory verification
skillctl pull --verify quay.io/skillimage/summarize:v1.2.0

Design (from existing specs)

Signing flow
  1. User publishes a skill image with skillctl push
  2. User signs with skillctl sign (or signing happens automatically during promote to published state)
  3. Signature is stored as a Cosign-compatible OCI artifact alongside the image
Verification flow
  1. During skillctl pull or skillctl install, optionally verify signature
  2. Check signature against Rekor transparency log (keyless) or provided public key
  3. Reject or warn on unsigned/invalid skills
Integration with Red Hat Trusted Artifact Signer (RHTAS)
  • Fulcio for short-lived certificates (keyless signing)
  • Rekor for transparency log
  • TUF for root of trust distribution
  • Compatible with enterprise Sigstore deployments

Implementation plan

Phase 1: Core signing and verification
  • Add sigstore-go / cosign dependencies
  • Implement pkg/verify/ — verify signatures on skill images
  • Add skillctl verify command
  • Add skillctl sign command (key-pair mode)
Phase 2: Keyless and policy
  • Keyless signing via Fulcio/OIDC
  • --verify flag on skillctl pull and skillctl install
  • Configurable verification policy (require, warn, skip)
  • Rekor transparency log integration
Phase 3: Enterprise (RHTAS)
  • RHTAS endpoint configuration
  • Custom TUF root support
  • Integration with promote lifecycle (auto-sign on publish)

References

  • Existing design: docs/design/2026-04-15-oci-skill-registry-design.md (lines 757–961)
  • Implementation spec: docs/design/2026-04-16-implementation-spec.md (deferred to phase 2+)
  • Sigstore
  • Red Hat Trusted Artifact Signer

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading docs/design/2026-04-15-oci-skill-registry-design.md at lines 757–961 and the deferred implementation spec, then inspect go.mod and the existing skillctl command entry points. The issue spans core signing, verification, keyless policy, and enterprise RHTAS phases; done requires the selected phase's commands, dependencies, and verification behavior to match the stated design.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
cli, security
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.