sealr 0.1.0-alpha.8: portable Unicode and supported wheel evaluation

sealr 0.1.0-alpha.8

This eighth development preview ships the first supported portable Unicode ZIP interpretation and promotes the bounded Python wheel evaluator through the public library. It preserves the Alpha.7 research artifacts and the Alpha.6 reduced-authority Linux boundary.

It remains a preview. The default APIs still run in process, structural ZIP planning is not confined, successful supervised execution is limited to x86_64 Linux with Landlock ABI 3, and this release does not claim wheel installation, general ecosystem compatibility, process containment, or production readiness.

Portable UTF-8 ZIP profile

• sealr.profile.zip.portable-utf8.v1 supports ZIP32 Store and Deflate, optional exact data descriptors, and strict UTF-8 NFC member names.
• The complete accepted flag language is 0x0000, 0x0008, 0x0800, and 0x0808; non-ASCII names require bit 11. Every extra field is denied.
• Dot components, invalid UTF-8, unflagged non-ASCII, non-NFC, Unicode 16.0 unassigned or private-use scalars, controls, Unicode 16 whitespace and bidi controls, reserved names, trailing dots or spaces, duplicate and full-default-case-fold-plus-NFC collisions, and components above 255 UTF-8 bytes or 255 UTF-16 code units fail closed. Exact dependency versions bind the Unicode data and algorithms into the profile identity.
• CP437 is not guessed. A future legacy compatibility profile requires its own identifier, mapping, corpus evidence, and vectors.
• The canonical profile digest is acee86158d481adff96da0277a470ba753d6208ede74bc48586bb0134db5152e. Required CI tests the complete 16-bit flag and extra-field-ID domains and reproduces the fourth profile vector independently.

Supported wheel evaluation

• sealr::wheel::evaluate_wheel accepts an exact outer filename, an opaque VerifiedArchive, and explicit WheelLimits. It requires the portable profile and returns admitted, denied, unsupported, or infrastructure failure without receiving a source path.
• The evaluator validates bounded case-insensitive headers, the filename and complete PEP 440 version class, exact .dist-info and optional .data topology, WHEEL, Core Metadata 2.1 through 2.4, strict selected-distribution RECORD binding and signature exemptions, dotted entry points, relocation, generated command names, script transforms, portable target collisions, and checked semantic byte ceilings.
• Public non-exhaustive records expose the artifact, evaluator-owned read-only scheme-relative install plan, findings, container facts, typed infrastructure failures, and distinct source, archive-tree, artifact, install-plan, and optional realization identities. Realization validates complete target coverage, topology, paths, hashes, and sizes before producing an identity.
• An exact downstream golden evaluates an NFC Unicode wheel after deleting the original source and pins the profile, consumer-profile, source, tree, artifact, and plan identities. A streaming fixture proves data-descriptor and UTF-8 flag composition, and a cross-platform test materializes and reads an NFC path.
• The extracted-package consumer exercises the same public evaluator through the authenticated Linux supervisor and exact packaged helper, including supervised readback of demo/café.py.

Compatibility evidence

• The predecessor-bound v3 inventory replays all 20 pinned artifacts and 90,417,280 exact source bytes through the portable profile and public evaluator. It preserves the v2 outcome: sixteen admitted, two denied, and two unsupported.
• The cffi duplicate Generator, Hatchling and wheel Core Metadata 2.5, and SciPy expansion-ratio clusters remain explicitly investigated. The profile and budget are not weakened to increase acceptance.
• The supported plan reports 60 source-executable regular files instead of 61. One orjson member was created under ZIP creator system 0 and is no longer treated as Unix executable authority merely because its external attributes resemble a Unix mode.
• The cohort still contains no benign Unicode or .data artifact and no descriptor-bearing member. Dedicated adversarial and generated fixtures cover those rules, while targeted benign corpus expansion remains next.

Distribution and verification

• Only the sealr library crate is allowlisted for crates.io publication. Required CI verifies its exact 53-file package, package-root README and Apache-2.0 license, Rust 1.98 metadata, and separately locked extracted-package consumer.
• The tag workflow produces exactly the Linux x86_64, macOS arm64, and Windows x64 native archives plus SHA256SUMS and GitHub build-provenance attestations. It does not publish the crate to crates.io.
• Promotion requires exact-main Required CI, exact-commit on-demand fuzz evidence, target-specific third-party license closure, release-candidate classification, draft-asset readback, and immutable-release verification.

Important limitations

• apply() continues to select strict ASCII v1 for compatibility. Portable UTF-8 v1 is explicit.
• No wheel install effect or CLI wheel mode exists. The evaluator produces a pure scheme-relative plan and does not resolve dependencies, execute metadata, generate platform launchers, compile bytecode, or write an environment.
• The 20-wheel pilot is judgmental and cannot establish PyPI prevalence or broad compatibility.
• NFKC, host-specific case tables, CP437, ZIP64, additional codecs, TAR, gzip, zstd, 7z, semantic locks, signed receipts, authenticated recovery, and complete durability remain outside this release.
• Stable API and identity review, targeted feature-rich wheel evidence, accumulated assurance history, an external adopter, and independent security review remain roadmap gates.

See the portable profile, wheel consumer profile, API contract, roadmap, and release verification commands for the exact boundary.

sealr 0.1.0-alpha.7: wheel research and distribution contracts

sealr 0.1.0-alpha.7

This seventh development preview completes the non-shipping Python wheel laboratory and turns source-crate and native-archive assumptions into executable distribution contracts. It preserves the Alpha.6 supervised Linux boundary and keeps wheel-specific behavior out of the supported API and CLI.

It remains a preview. The default APIs still run in process, structural ZIP planning is not confined, successful supervised execution is limited to x86_64 Linux with Landlock ABI 3, and this release does not claim supported wheel admission, general process containment, or production readiness.

Wheel research

• sealr.profile.zip.wheel-utf8.v1 is a separately identified repository-only interpretation. It permits ZIP32 Store and Deflate, only general-purpose bit 11, no data descriptors or extra fields, strict UTF-8, NFC names, no dot-component normalization, and lowercase-plus-NFC collision rejection.
• Exhaustive tests cover every 16-bit general-purpose flag value and every 16-bit extra-field identifier. The new profile does not widen the compatibility default or strict ASCII v2 profile.
• A pure bounded evaluator produces one of four outcomes: admitted, denied, unsupported, or infrastructure failure. It validates the outer wheel filename, one matching .dist-info root, WHEEL, Core Metadata, RECORD, .data relocation, generated targets, entry points, executable disposition, and fixed resource ceilings.
• Source, archive-tree, wheel-artifact, scheme-relative install-plan, and target-realization identities use distinct domains. ZIP creator-system and external-attribute facts remain outside sealrTreeV1 and are bound where consumer semantics use them.
• Thirteen minimized hostile wheels cover container, filename, metadata, RECORD, relocation, generated-target, unknown-scheme, and script-rewrite disagreements. Fixture generation and committed bytes are deterministic.
• The predecessor-bound v2 inventory evaluates the same exact 20-wheel pilot through the wheel profile and consumer model. Sixteen artifacts are admitted, two denied, and two unsupported. The report investigates each cluster and does not present the sample as an ecosystem acceptance rate.
• A pinned PyPA installer 0.7.0 bridge consumes only bounded member blobs staged through VerifiedArchive. The regression deletes the original wheel before Python starts, installs an audit hook before importing the installer, rejects every .whl open, validates repeatable member reads and RECORD, and compares the external actions with Sealr's install plan.

Distribution contracts

• Only the sealr library crate is allowlisted for crates.io publication. Every other workspace crate remains non-publishable.
• Required CI pins the exact 47-file cargo package result, extracts the package, checks that package-root README.md and LICENSE bytes match the repository, verifies Apache-2.0 and Rust 1.98 metadata, and builds a separately locked downstream consumer.
• The crate is publication-ready, but the GitHub tag workflow does not publish it to crates.io. The 0.1.0-alpha.* public API remains prerelease and subject to documented breaking changes.
• Native archives have separate exact evidence floors: Ubuntu 24.04 x86_64 with glibc 2.39, macOS 15 arm64 with Darwin 24 and deployment target 15.0, and Windows Server 2022 x64 build 20348.
• Required and release workflows use explicit runner labels and assert the actual host, architecture, ABI, and deployment contract before testing and packaging. Release artifacts remain the same three target archives plus SHA256SUMS and GitHub provenance.
• Target-specific third-party license closures now include the Unicode normalization dependency and continue to exclude first-party workspace packages.

Semantic and identity evidence

• MemberContainerFacts exposes immutable creator-system and external-attribute facts from verified central-directory bytes. It provides the exact PyPA installer 0.7.0 executable predicate without placing consumer-specific mode semantics in the generic tree identity.
• Private SEALRSEM planning and completion records advance to wire version 2 so supervised consumers retain those facts. The public worker protocol remains version 1.
• The immutable Alpha.6 semantic-shadow v1 and v2 files retain their original byte lengths and SHA-256 values. Live tests compare all stable semantic fields while excluding only the historical private-wire plan and frame identifiers, and a separate regression pins the exact current wire-v2 frame and source-bound fact validation.
• The independent identity bundle now carries three profile vectors. Its standalone verifier reproduces the compatibility, strict ASCII v2, and wheel UTF-8 v1 profile digests without linking Sealr.

Verification

Protected main retains one Required CI authority after the exact quality, macOS, Windows, ZipDiff, supply-chain, and real-kernel jobs pass. The quality job also verifies both wheel inventories, hostile fixtures, the real external installer bridge, exact crate packaging, documentation contracts, lockfiles, and optimized package consumers.

Release promotion still requires exact-main required CI, both exact-commit on-demand fuzz jobs, the release-candidate contract, a clean semantic walkthrough, target license closure, immutable-release protection, and staged-release readback before publication.

Important limitations

• No supported wheel API or CLI mode exists. The wheel profile, evaluator, identities, inventory, fixtures, and installer bridge are repository research evidence.
• The 20-wheel pilot is judgmental and too small to establish PyPI prevalence or compatibility. It contains no benign .data or Unicode-path artifact, so those consequences rely on hostile boundary fixtures.
• The external bridge proves one pinned consumer shape. It does not freeze the public API, create a general installer sandbox, or authorize bytecode generation and target-specific post-install hooks.
• apply, apply_with_options, and ordinary CLI execution remain in process. The reduced-authority Linux path is explicit and fail closed.
• Structural parsing and policy planning remain supervisor-side. The worker boundary confines payload verification, stage writes, and later non-retained reads, not interpretation.
• Successful supervised execution requires x86_64 Linux, Landlock ABI 3, and the packaged helper contract. macOS, Windows, other architectures, and lower Landlock ABIs return typed unavailability.
• ZIP64, TAR, compressed TAR, gzip, zstd, and 7z remain unsupported. Receipts and preview tree identities remain unsigned.
• Stable profile locks, portable general-purpose Unicode naming, accumulated assurance history, authenticated recovery, durability evidence, an external security audit, and production support remain roadmap gates.

See the README, wheel profile, wheel inventory, distribution contract, roadmap, and release verification commands for the exact boundary and reproducible checks.

sealr 0.1.0-alpha.6: reduced-authority Linux preview

sealr 0.1.0-alpha.6

This sixth development preview adds an explicit reduced-authority Linux execution path, activates it across the library, CLI, wheel laboratory, and extracted-package consumer, and establishes a machine-checked assurance-promotion contract. It keeps structural planning, destination publication, and final evidence authority in the supervisor while moving payload verification, stage writes, and later non-retained member reads into an authenticated restricted worker.

It remains a preview. The default APIs still run in process, structural ZIP planning is not confined, successful supervised execution is limited to x86_64 Linux with Landlock ABI 3, and this release does not claim general process containment or production readiness.

Highlights

• LinuxWorker::load_from_manifest authenticates one fixed sibling helper from a bounded release manifest. The manifest binds release version, target, bootstrap ABI, byte length, and lowercase SHA-256. The implementation never searches PATH, reopens the supplied helper pathname after authentication, or falls back to in-process execution.
• inspect_supervised and apply_supervised preserve archive rejection as an ordinary Outcome while reporting helper, restriction, protocol, timeout, exit, reap, cleanup, source, and integrity-boundary failures as typed SupervisionError values.
• The worker reaches single-threaded, no-descendant, inherited-descriptor-closed, no_new_privs, Landlock, and seccomp readiness before receiving the source descriptor. The supervisor applies absolute monotonic deadlines and ensures termination plus reap before authorizing cleanup.
• Structural planning remains supervisor-side. The worker receives the exact immutable source, a kernel-sealed bounded plan, and, for materialization, only the supervisor-created stage root. It does not receive the destination parent or publication authority.
• After clean worker exit and reap, the supervisor treats completion and retained-content records as untrusted proposals. It independently replays the accepted plan against its retained exact source and requires canonical byte-for-byte agreement before constructing public evidence.
• Supervised materialization keeps stage setup, exact post-reap tree audit, cleanup, and native no-replace publication in the supervisor. The worker cannot publish the destination.
• A supervised VerifiedArchive returns selected retained bytes captured during the original verification pass. Every non-retained read uses a fresh restricted worker and returns no bytes until exact EOF, correlated size, CRC32, SHA-256, clean exit, and reap have all been observed.
• The Linux release archive now includes a static musl worker at libexec/sealr/sealr-worker and its fixed manifest. The macOS and Windows archives remain helper-free, and attempts to activate the Linux worker surface there fail closed.
• The CLI selects the boundary only when --worker-manifest ABSOLUTE_PATH is provided. The wheel laboratory and extracted-package consumer use the same authenticated manifest without fallback.

Security and lifecycle evidence

• A required real-kernel gate boots a SHA-256-pinned Debian 6.1 kernel under QEMU TCG, independently observes Landlock ABI 2, and proves both public supervised operations fail with RestrictionUnavailable before source transfer because the production floor is ABI 3. The gate also requires no fallback, destination creation, leaked stage, outside-sentinel mutation, or surviving child.
• A 500-iteration native bootstrap campaign covers the complete 44-case non-stall matrix. Deterministic barriers and stalls cover descriptor rejection, protocol rejection, restriction failures, transport faults, abrupt exits, and timeouts while checking child, descriptor, source, stage, sentinel, and cleanup invariants.
• A separate 500-case public materialization lifecycle oracle runs on Linux, macOS, and Windows. It models successful publication, setup collision, CRC abort, and a deterministic destination race against independently computed expected outcomes.
• The private semantic-record boundary has bounded hostile decode, exact invocation and source binding, fallible input-sized allocation, plan-native Store and Deflate execution without structural reparse, immutable original-pass retention, and a required near-limit completion-memory probe.
• Twenty-four manifest-pinned semantic shadow cases compare production planning and completion behavior. Every additive v2 case records whether its independent oracle is ordinary apply, backend parity, or supervisor reproduction.
• The exact-main on-demand fuzz gate now requires both bounded worker-protocol and semantic-record AddressSanitizer jobs.

Assurance governance

• Kani 0.67.0 checks the exact production interval, quota, and ratio scalar kernels over their stated full-width domains, explicit assumptions, solvers, and unwind bound 1. These proofs do not cover parsing, codecs, filesystem effects, worker containment, or dependencies.
• Weekly bounded mutation and source-coverage jobs retain machine-readable discovery reports. Their results are leads, not correctness percentages or release scores.
• A checked promotion ledger keeps Kani, fuzzing, native resource evidence, mutation, and coverage as five distinct categories. An eligible check needs ten distinct consecutive successful scheduled main runs plus bounded local reproduction and explicit review. Manual runs do not count, a failure resets the sequence, and mutation and coverage cannot be promoted into required CI.
• Protected main retains one stable Required CI authority. It succeeds only after the six underlying platform, quality, ZipDiff, supply-chain, and real-kernel jobs succeed on the exact commit.

Packaging and verification

The tag workflow builds and tests native archives for x86_64 Linux, Apple silicon macOS, and x86_64 Windows. The Linux archive includes the authenticated helper contract; macOS and Windows explicitly reject helper entries. Each archive contains the CLI, README, changelog, Apache-2.0 license, and a target-specific locked dependency license bundle. SHA256SUMS and GitHub build provenance accompany the archives.

Release promotion requires protected exact-main CI, both exact-commit on-demand fuzz jobs, the release-candidate contract, a clean semantic walkthrough, license closure, immutable-release protection, and readback of the staged release before publication.

Important limitations

• apply, apply_with_options, and ordinary CLI execution remain in process. The reduced-authority path is explicit and fail closed.
• Structural parsing and policy planning still run in the supervisor before the worker receives the source. The worker boundary confines payload verification, stage writes, and later non-retained reads, not interpretation.
• Successful supervised execution requires x86_64 Linux, Landlock ABI 3, and the packaged helper contract. macOS, Windows, other architectures, and lower Landlock ABIs return typed unavailability.
• The seccomp filter is a measured deny set, not a complete syscall allowlist. Sealr makes no general network, IPC, CPU, memory, same-user, kernel-compromise, or production-containment claim.
• Unicode normalization and CP437 decoding remain absent. Non-ASCII member paths fail closed.
• ZIP64, TAR, compressed TAR, gzip, zstd, and 7z are unsupported. The wheel laboratory is compatibility evidence, not a supported wheel consumer profile.
• Receipts and preview tree identities remain unsigned. There is no stable semantic lock, authenticated archive-decision attestation, external security audit, or production-supported release.

See the README, supervised boundary evidence, helper packaging contract, assurance promotion contract, and release verification commands for the exact boundary and reproducible checks.

sealr 0.1.0-alpha.5: bounded immutable input preview

sealr 0.1.0-alpha.5

This fifth development preview closes the bounded immutable input increment planned for Alpha.5. It replaces whole-archive path buffering with a private file-backed snapshot, routes archive work through checked random access, strengthens source-change detection, adds native resource evidence, and defines a bounded capability-oriented worker protocol with pinned fuzzing.

It remains a preview. Sealr still runs parsing and materialization in the caller process, has no enforced worker or process sandbox, does not recognize Python wheels as a consumer type, does not provide stable signed locks, and does not claim production qualification against arbitrary hostile archives.

Highlights

• Successful path ingest opens the caller path once, copies and hashes it under the source cap through a fixed 64 KiB buffer, and retains a Sealr-owned private file. The spool is reopened read-only, its filename is removed, and every later parse, verification, materialization, and VerifiedArchive read uses the retained handle.
• Magic detection, EOCD discovery, central and local metadata, descriptors, covering audit, Store and Deflate verification, and later verified-member reads use checked u64 exact reads or range-limited streams. Central-directory allocation follows the metadata cap, and member payloads are not exposed as whole slices.
• Private-file and borrowed-memory snapshots produce byte-identical IR, findings, preview semantic roots, and verified-member bytes for the same source.
• Required CI applies physically sparse valid 1 MiB and 128 MiB ZIP32 inputs in isolated child processes. It bounds tracked heap allocation, peak resident memory, and both size-related deltas independently of the accepted source size.
• The monthly and manual native matrix applies an exact 3 GiB sparse valid fixture on Ubuntu, macOS, and Windows. The implementation run passed on all three systems.
• The non-published sealr-worker-protocol crate has no dependencies or unsafe. Version 1 uses a fixed 212-byte start frame, a 4 MiB whole-frame cap, out-of-band source and stage capability slots, nonzero operation correlation, canonical result manifests, bounded findings, typed errors, and fallible allocation.
• Protocol regressions cover valid inspect and materialize round trips, complete and rejected results, every truncation point, malformed headers and state, capability and correlation confusion, inconsistent counts, invalid strict-ASCII paths, canonical ordering, and three mutations at every byte position.
• A separately locked libFuzzer target pins nightly-2026-08-01, cargo-fuzz 0.13.2, and libfuzzer-sys 0.4.13. The source-controlled digest manifest binds every seed and dictionary by path, size, and SHA-256. The bounded AddressSanitizer campaign caps input, time, per-input timeout, RSS, jobs, and retained reproducer output.

Security and correctness fixes

• Hostile snapshot ranges are checked in u64 before allocation or platform-size conversion.
• Short positional reads are retried exactly; truncation, growth, interrupted copy, incomplete source, and payload I/O failures remain distinguishable.
• A partial capped copy never receives the digest of a prefix as though it covered the complete source.
• Windows excludes concurrent write sharing while copying the caller source. An existing writer causes admission to fail closed.
• Unix compares device, inode, mode, length, modification time, and change time before and after the copy. Deterministic same-length mutation is rejected as source I/O failure.
• Caller path deletion or replacement cannot redirect later parsing or verified-member reads.
• Snapshot I/O failures during interpretation remain indeterminate rather than being mislabeled as malformed archive syntax. Deflate and later member reads preserve source-I/O identity instead of reporting an integrity disagreement.
• Protocol v1 rejects oversized, truncated, trailing, count-inconsistent, noncanonical, uncorrelated, and semantically incoherent frames before archive or filesystem effect.
• Fuzz dependencies now receive the same cargo-deny and Dependabot review as the shipping workspace. Corpus byte attributes prevent cross-platform line-ending conversion from invalidating seed digests.
• A failed or closed stdout stream no longer prevents the CLI from attempting the independent receipt on stderr. Completed inspection or materialization semantics are preserved, and the process returns an operational failure if either output stream cannot be written.

Resource and fuzz evidence

The required 1 MiB versus 128 MiB resource regression caps tracked heap allocation at 8 MiB and its size-related delta at 1 MiB. It caps absolute peak resident memory at 256 MiB and the size-related delta at 64 MiB. The recorded Windows run used 210,367 tracked heap bytes for both inputs and approximately 7.3 MiB peak resident memory for each.

The exact 3 GiB local Windows probe used 131,072 allocated source bytes and 210,427 tracked heap bytes. The three-platform scheduled matrix passed the same ignored regression on Ubuntu, macOS, and Windows.

The first manually dispatched exact-main protocol campaign executed 18,277,565 units in 601 seconds, averaged 30,411 executions per second, reached 503 MiB peak RSS under the 1,024 MiB limit, and produced no reproducer. Coverage-guided fuzzing is heuristic evidence, not an exhaustive proof of decoder safety.

Verification

The required CI workflow verifies format and workflow syntax, Clippy with warnings denied, debug and release tests, optimized builds, warning-free Rustdoc, documentation and fuzz-manifest contracts, identity conformance, the wheel-report verifier, the extracted-package consumer, native macOS and Windows tests, the i686 Windows ABI, 5,927 ZipDiff constructions, cargo-deny policy for both Cargo graphs, and deterministic third-party license bundles.

Release promotion now requires successful protected-main CI and a successful on-demand protocol-fuzz job on the exact release commit. Release archives contain the native CLI, README, changelog, Apache-2.0 license, and target-specific third-party notices. SHA256SUMS and GitHub build provenance accompany all three native archives.

Protocol v1 is deliberately not the final worker semantic contract. It carries a reduced staged-member manifest, not a complete ArchiveIR, and its single operation status does not preserve every public semantic and effect axis independently. Alpha.6 must resolve IR ownership and revise the protocol or split the operation into explicit phases before process isolation freezes.

Next

Alpha.6 first resolves semantic ownership and outcome-axis transport beyond protocol v1. It then creates the same-binary Linux worker, transfers only immutable source and stage capabilities, validates and closes inherited descriptors, installs a measured no_new_privs and Landlock boundary before the first archive read, treats the worker result as hostile, and keeps staged-tree audit and no-replace publication in the supervisor.

sealr 0.1.0-alpha.4: measured semantic contract preview

sealr 0.1.0-alpha.4

This fourth development preview closes the measured semantic contract planned for Alpha.4. It adds a reusable verified-archive capability, bounded one-pass semantic-member retention, a closed strict ASCII ZIP profile, independently checked identity vectors, finite-domain property gates, and a reproducible wheel compatibility pilot.

It remains a preview. Sealr does not yet use a private file-backed snapshot or reduced-authority worker, recognize Python wheels as a consumer type, validate wheel metadata or RECORD, provide stable signed locks, or claim production qualification against arbitrary hostile archives.

Highlights

• VerifiedArchive is an opaque capability available only after complete verification and admission. It supports caller-bounded exact-member reads without reopening or reparsing the source.
• RetentionPlan selects at most 64 exact canonical paths under independent path, per-member, and aggregate limits. Selected bytes are retained during the original verification stream and can be borrowed without another parse, inflation, allocation, or hash.
• sealr.profile.zip.strict-ascii.v2 is explicitly selectable through ApplyOptions. It preserves Store and Deflate, treats data-descriptor bit 3 as semantic, denies every other general-purpose flag bit, denies every extra-field ID, and accepts ASCII member names only. Finite tests cover all 65,536 flag words and all 65,536 extra-field identifiers.
• sealr.profile.zip.strict-ascii.v1 remains byte-for-byte immutable and is still selected by the compatibility apply() facade.
• The identity-conformance bundle contains exact canonical bytes for both profiles. A standalone workspace verifier with no Sealr dependency checks their digests and independently reproduces the committed ZIP32 covering plus layout and content roots.
• Six named finite-domain property families cover compression ratios, verified-member limits, checked intervals, exact partitions, atomic quota transitions, and deterministic retention selection.
• The packaged-crate gate runs an isolated exact-version consumer against Cargo's extracted package and exercises strict-v2 selection, retained reads, fallback reads, error categories, and capability ownership.
• A reproducible 20-wheel pilot binds 90,417,280 exact source bytes, analyzer revision, strict-v2 profile digest, and default-policy digest. It admits 19 wheels and denies SciPy for three exact quota.ratio findings. Required CI verifies the committed report offline.

Security and correctness fixes

• Matching strong-encryption and masked-header flags can no longer bypass the encryption policy.
• ZIP64 count sentinels, understated central-header counts, and local-header offset overflow are classified without truncation or unchecked arithmetic.
• ZIP discovery and the codec-free covering audit share one checked interval and exact-partition kernel.
• Declared totals, actual totals, remaining capacity, and member byte counts share one atomic quota transition. Failed updates leave state unchanged.
• Path and byte inputs retain honest source-digest and snapshot-kind evidence across cap and I/O failures.
• A selected v2 interpretation identity is preserved on policy, source, format, and structure failures rather than falling back to v1 evidence.
• Wheel acquisition and cached-file verification use bounded fixed-buffer reads, exact sizes, SHA-256 pins, redirect refusal, and safe partial-file promotion.

Compatibility evidence

The strict-v2 pilot observed 4,504 interpreted members, all using Store or Deflate with flags 0x0000 and no extra fields. The initial sample therefore supports the closed ASCII contract but does not estimate PyPI-wide compatibility or justify a wheel-oriented UTF-8 profile.

Setuptools contained twelve nested vendored .dist-info trees in addition to its own top-level directory. Future wheel evaluation must bind the normalized outer filename to exactly one matching top-level .dist-info directory instead of treating every suffix match as artifact metadata.

Verification

The required CI workflow runs format and workflow validation, Clippy with warnings denied, debug and release tests, optimized builds, rustdoc, documentation contracts, identity conformance, the wheel-report verifier, the extracted-package consumer, native macOS and Windows tests, the i686 Windows ABI check, 5,927 ZipDiff constructions, cargo-deny policy, and deterministic third-party license verification.

Release archives contain the native CLI, README, changelog, Apache-2.0 license, and target-specific third-party notices. SHA256SUMS and GitHub build provenance are published with the three native archives.

Next

Alpha.5 replaces whole-archive in-memory ownership for path inputs with a private file-backed snapshot. Copy, hash, retain, checked random access, mutation resistance, and bounded-memory evidence precede the supervised Linux worker planned for Alpha.6.

sealr 0.1.0-alpha.3: semantic identity preview

sealr 0.1.0-alpha.3

This third development preview gives the ZIP boundary an effect-independent interpretation object and separate semantic identities. It also makes outcome reporting more precise and adds a same-process audit of the staged tree before publication. It is intended for evaluation, development, and adversarial testing. It is not ready to protect a production host from arbitrary hostile archives.

Included

• Everything in the alpha.2 ZIP32 Store and Deflate boundary, including native no-replace materialization and the deterministic 5,927-case ZipDiff gate.
• One versioned sealr.archive-ir.v1 built from a named immutable SourceSnapshot. Inspect and materialize consume that IR without reparsing the archive.
• A codec-free covering audit over the local-record prefix, central directory, EOCD, comment, member headers, payloads, and optional data descriptors.
• Receipt v2 outcome axes for interpretation, admission, verification, effect, and view completeness. The compatibility verdict remains present, while CLI exit 3 distinguishes an admitted archive whose requested destination effect failed.
• Typed policy compilation before source ingestion, integer ratio enforcement, checked security counters, and fail-closed reserved fields.
• Separate source, interpretation-profile, layout, content-tree, and invocation identities. The preview sealrTreeV1 roots have cross-platform golden vectors.
• A staged-tree audit that streams file hashing through a fixed 64 KiB buffer and verifies exact paths, implicit directories, member sizes, and content digests before publication.
• Deterministic tests for destination appearance, directory-component substitution, staged-content mutation, malformed directory entries, invalid identity input, and partial-view reporting.
• A parallel ZipDiff classifier using bounded standard-library threads and optional SEALR_JOBS, with no new runtime dependency.

Compatibility notes

• Policy.max_ratio is now Option<u64>. Some(100) means 100:1, None disables the ratio check, and Some(0) does not.
• Receipts use sealr.receipt.v2. The inspectable view retains sealr.view.v1 and now includes the same outcome axes.
• The CLI exits 0 for admitted inspect or committed materialization, 2 when admission did not succeed, and 3 when admission succeeded but a requested effect failed.
• Layout and content roots are preview encodings. Consumers must not treat them as stable locks or authenticated claims.

Platform boundary

• Linux creates mode-0700 stages through retained directory capabilities and publishes with RENAME_NOREPLACE.
• macOS adds retained-descriptor ACL rejection and publishes with RENAME_EXCL.
• Windows supports only a non-remote, writable NTFS parent with persistent ACLs, creates a protected effective-TokenUser stage, and publishes through retained handles with no replacement.
• Other operating systems fail closed for materialization.

Important limitations

• Only classic ZIP32 with Store and Deflate members is supported. ZIP64, TAR, compressed TAR, gzip, zstd, and 7z are rejected or unsupported.
• Non-ASCII legacy names fail closed while CP437 decoding and portable Unicode normalization remain unfinished.
• The compressed archive is buffered in memory within the configured input cap. Expanded members and the staged-tree audit stream through bounded buffers.
• Reduced-authority process isolation is not implemented. Other processes running as the same user remain outside the containment claim.
• Crash recovery, directory syncing, and power-loss durability are not implemented. The default policy is flush-only.
• Receipts and tree roots are unsigned. Receipt JSON is not yet canonicalized with RFC 8785 JCS.
• There is no external security audit or stable compatibility promise.

Read README.md, SECURITY.md, and ROADMAP.md from this tagged revision for the complete boundary and release status.

Verify an archive

Download the native archive for your platform and SHA256SUMS from this release, then verify its SHA-256 digest. Runnable platform-specific commands are in docs/release-verification.md at this tag.

GitHub also records build provenance for every native archive. With a current GitHub CLI:

gh attestation verify sealr-0.1.0-alpha.3-NATIVE-TARGET.ARCHIVE-EXTENSION --repo blisspixel/sealr

Provenance links an archive to its source commit and release workflow. It is not a claim that the program is free of vulnerabilities.

The published prerelease is immutable and carries GitHub's release attestation. Verify it with:

gh release verify v0.1.0-alpha.3 --repo blisspixel/sealr

sealr 0.1.0-alpha.2: hardened materialization preview

sealr 0.1.0-alpha.2

This second development preview strengthens staged materialization and its evidence on Windows while preserving the native Linux and macOS boundaries. It is intended for evaluation, development, and adversarial testing. It is not ready to protect a production host from arbitrary hostile archives.

Included

• Everything in the first ZIP32 Store and Deflate preview, including the deterministic 5,927-case ZipDiff gate.
• Exact single-stream DEFLATE consumption. Trailing bytes, concatenated streams, and invalid stream syntax fail with dedicated codec findings.
• Windows parent admission limited to non-remote, writable NTFS volumes that report persistent ACL support.
• Atomic Windows stage creation with the effective token user as object owner and one protected inheritable allow ACE for that SID.
• Handle-based verification of the stage owner and exact DACL before member writes, plus native tests of descendant DACL inheritance.
• Retained-handle cleanup on setup failure and native no-replace publication on Linux, macOS, and Windows.
• Materialization receipt v2 with explicit, non-sensitive Windows storage and stage-ACL evidence.
• Dedicated findings for unsupported Windows filesystems and unverified stage security.
• Documentation contract checks for local links, finding codes, materialization primitives, version metadata, and licensing.
• Apache-2.0 licensing for this release and later contributions.
• Target-specific third-party license bundles generated from the locked Linux, macOS, and Windows release dependency graphs and verified before packaging.

Platform boundary

• Linux creates mode-0700 stages through retained directory capabilities and publishes with RENAME_NOREPLACE.
• macOS adds retained-descriptor ACL rejection and publishes with RENAME_EXCL.
• Windows supports only a non-remote, writable NTFS parent with persistent ACLs. ReFS, FAT-family filesystems, remote shares, read-only volumes, and ambiguous volume queries fail closed before staging.
• Other operating systems fail closed for materialization.

Important limitations

• Only classic ZIP32 with Store and Deflate members is supported. ZIP64, TAR, compressed TAR, gzip, zstd, and 7z are rejected or unsupported.
• Non-ASCII legacy names fail closed while CP437 decoding and portable Unicode normalization remain unfinished.
• The compressed archive is buffered in memory within the configured input cap. Expanded members stream.
• Reduced-authority process isolation is not implemented. Other processes running as the same user remain outside the containment claim.
• Crash recovery, directory syncing, and power-loss durability are not implemented. The default policy is flush-only.
• Receipts are unsigned and are not yet canonicalized with RFC 8785 JCS.
• There is no external security audit or stable compatibility promise.

Read README.md, SECURITY.md, and ROADMAP.md from this tagged revision for the complete boundary and release status.

Verify an archive

Download the native archive for your platform and SHA256SUMS from this release, then verify its SHA-256 digest.

On Linux:

sha256sum --check --ignore-missing SHA256SUMS

On macOS:

shasum --algorithm 256 --check SHA256SUMS

On Windows PowerShell:

$expected = (Select-String -Path SHA256SUMS -Pattern 'sealr-.*-windows-.*\.zip$').Line.Split(' ')[0]
$archive = Get-ChildItem -File 'sealr-*-windows-*.zip' | Select-Object -First 1
$actual = (Get-FileHash -Algorithm SHA256 -LiteralPath $archive.FullName).Hash.ToLowerInvariant()
if ($actual -ne $expected) { throw 'SHA-256 verification failed' }

GitHub also records build provenance for every native archive. With a current GitHub CLI:

gh attestation verify sealr-0.1.0-alpha.2-NATIVE-TARGET.ARCHIVE-EXTENSION --repo blisspixel/sealr

Provenance links an archive to its source commit and release workflow. It is not a claim that the program is free of vulnerabilities.

The published prerelease is immutable and carries GitHub's release attestation. Verify it with:

gh release verify v0.1.0-alpha.2 --repo blisspixel/sealr

sealr 0.1.0-alpha.1: ZIP boundary preview

sealr 0.1.0-alpha.1

This is the first public development preview of sealr's ZIP boundary. It is intended for evaluation, development, and adversarial testing. It is not ready to protect a production host from arbitrary hostile archives.

Included

• Classic ZIP32 inspection for Store and Deflate members.
• Exact agreement checks across central-directory, local-header, end-of-central-directory, and data-descriptor structures.
• Fail-closed path, topology, quota, encryption, layout, overlap, and ambiguity handling.
• Per-component no-follow staged materialization with native no-replace publication, atomic Windows stage acquisition, and fail-closed Unix parent checks.
• Structured allow and reject views plus unsigned receipts that bind source, policy, view, tool, environment, and materialization evidence.
• A deterministic public CI gate over all 5,927 pinned ZipDiff constructions and 14 ambiguity classes.
• Native preview archives built and tested on standard GitHub-hosted Ubuntu, Windows, and macOS runners.

Important limitations

• Only classic ZIP32 with Store and Deflate members is supported. ZIP64, TAR, compressed TAR, gzip, zstd, and 7z are rejected or unsupported.
• Non-ASCII legacy names fail closed while CP437 decoding and portable Unicode normalization remain unfinished.
• The compressed archive is buffered in memory within the configured input cap. Expanded members stream.
• Reduced-authority process isolation is not implemented.
• The materialization destination parent must already exist. Unix support requires trusted owner, mode, sticky semantics, and on Apple platforms no extended ACL. Richer filesystem ACL semantics are not yet supported.
• Windows stage creation and publication retain the relevant directory handles, but the stage inherits its parent's ACL. Any principal granted child-mutation rights by that DACL can alter staged content. Callers need a restrictive parent until a private ACL and reduced-authority worker are implemented.
• Receipts are unsigned and are not yet canonicalized with RFC 8785 JCS.
• There is no external security audit or stable compatibility promise.

Read README.md, SECURITY.md, and ROADMAP.md from this tagged revision for the complete boundary and release status.

Verify an archive

Download the native archive for your platform and SHA256SUMS from this release, then verify its SHA-256 digest.

On Linux:

sha256sum --check --ignore-missing SHA256SUMS

On macOS:

shasum --algorithm 256 --check SHA256SUMS

On Windows PowerShell:

$expected = (Select-String -Path SHA256SUMS -Pattern 'sealr-.*-windows-.*\.zip$').Line.Split(' ')[0]
$archive = Get-ChildItem -File 'sealr-*-windows-*.zip' | Select-Object -First 1
$actual = (Get-FileHash -Algorithm SHA256 -LiteralPath $archive.FullName).Hash.ToLowerInvariant()
if ($actual -ne $expected) { throw 'SHA-256 verification failed' }

GitHub also records build provenance for every native archive. With a current GitHub CLI:

gh attestation verify sealr-0.1.0-alpha.1-NATIVE-TARGET.ARCHIVE-EXTENSION --repo blisspixel/sealr

Provenance links an archive to its source commit and release workflow. It is not a claim that the program is free of vulnerabilities.

The published prerelease is immutable and carries GitHub's release attestation. Verify it with:

gh release verify v0.1.0-alpha.1 --repo blisspixel/sealr