Uploaded image for project: 'Container Tools'
  1. Container Tools
  2. RUN-3629

Validate container registry behavior with unrecognized manifest fields

XMLWordPrintable

    • Icon: Story Story
    • Resolution: Unresolved
    • Icon: Undefined Undefined
    • None
    • None
    • None
    • 3
    • False
    • Hide

      None

      Show
      None
    • False
    • Not Selected
    • rhel-container-tools

      As an engineering team member preparing for Post-Quantum Cryptography (PQC) readiness, I want to test how major public container registries handle images pushed with unrecognized/extra fields in their manifest, so that we can determine the viability of adding new fields (e.g., simultaneous SHA512 hashes) for PQC support while maintaining backward compatibility (with SHA256).

      Context: This research is preparatory work for our PQC readiness initiative. The proposed strategy involves modifying the OCI image manifest to include multiple hashes for layers (e.g., existing SHA256 for legacy clients and a new field for SHA512 for PQC-safe verification).

      Before proceeding, we must understand if registries will:

      1. Reject images with these new, unrecognized fields.
      1. Accept the images but strip the new fields, defeating the purpose.
      1. Accept the images and preserve the new fields (the ideal outcome).

      Acceptance Criteria:

      1. A test script (or manual procedure) is created to:
        • Take a standard Linux image (e.g., hello-world or alpine).
        • Modify its local manifest file (e.g., index.json or manifest.json) to include an arbitrary, non-standard test field (e.g., "pqcTestField": "true").
      1. The following public container registries are provisioned for testing:
        • [ ] Docker Hub
        • [ ] AWS ECR (Elastic Container Registry)
        • [ ] Google Artifact Registry (or GCR)
        • [ ] Quay.io
        • [ ] GitHub Container Registry (GHCR)
        • [ ] Microsoft Azure Container Registry (ACR)
      1. For each of the target registries, the following test workflow is executed and documented:
        • [ ] Test 1: Push Image: The modified image (with the extra manifest field) is pushed to the registry.
        • [ ] Test 2: Record Push Result: The result of the push (Success or Failure) is recorded.
        • [ ] Test 3: Pull Image: If the push was successful, the same image tag is pulled to a clean local environment (to ensure it's not using a local cache).
        • [ ] Test 4: Inspect Manifest: The manifest of the pulled image is inspected.
        • [ ] Test 5: Record Preservation: It is recorded whether the custom "pqcTestField" is still present and unmodified in the pulled manifest.
      1. A final summary table is created and attached to this story, detailing the results for each registry

              lmandvek Lokesh Mandvekar
              mheon@redhat.com Matt Heon
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated: