Skip to content

Harden the Slurm runtime and validate sealed release artifacts #870

Description

@nabinchha

Priority Level

High

Task Summary

Complete the runtime security review and acceptance evidence required to release the optional Slurm package from one sealed commit, wheel set, dependency lock, and runtime checksum.

Technical Details & Implementation Plan

  • Review provenance and license treatment for adapted behavior and every added runtime resource.
  • Review package dependencies, generated metadata, and release ordering.
  • Threat-model batch rendering, argument construction, environment materialization, secret references, paths, mounts, archives, locks, signals, and atomic publication.
  • Add source, fixture, wheel, example, documentation, script, and log scans for credentials and environment-specific infrastructure values.
  • Verify restrictive permissions, secret redaction, checksum enforcement, bounded command output, and failure cleanup.
  • Build the complete wheel set once and record non-sensitive artifact digests and runtime checksums.
  • Run the required acceptance scenarios against those exact artifacts: image import/inspection, one-node generation, multi-node generation and follower failure, two serving images, managed assets and a custom plugin, sharding/retry/CPU collection, and benchmark analysis.
  • Run a second sanitized profile dry-run without source or wheel changes.
  • Keep environment-specific profiles and raw infrastructure logs out of public repository artifacts and issue comments.

Acceptance criteria

  • Provenance/license, dependency, and shell threat-model reviews have no unresolved release blockers.
  • Automated scans find no credentials or environment-specific infrastructure values in public source or built artifacts.
  • Every accepted scenario records the exact public commit and sealed artifact identities.
  • Failure cases demonstrate redaction, cleanup, manifest integrity, and correct retry classification.
  • Built-wheel tests prove base-only isolation, optional-extra installation, lazy CLI loading, and co-version compatibility.
  • Acceptance evidence contains only sanitized capability outcomes and non-sensitive artifact identities.
  • Any code change after sealing invalidates and reruns affected acceptance evidence.

Out of scope

  • Publishing environment-specific profiles or raw scheduler/allocation logs.
  • Expanding the v1 feature set.
  • Certifying a second Slurm environment.

Investigation / Context

This is the release-hardening and acceptance lane for #850. It verifies the implemented public contracts rather than introducing new runtime features.

Agent Plan / Findings

Start provenance and threat-model review early, then attach final acceptance only to the exact artifacts selected for release.

Dependencies

Final acceptance is blocked by the implementation lanes, built-wheel integration, and complete user documentation tracked by #850.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

taskInternal development task

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions