Skip to content

0.1.2

Choose a tag to compare

View all tags
@dbowm91 dbowm91 released this 28 Sep 21:54
· 143 commits to main since this release
v0.1.2
e8e07eb

crates.io publication of the workspace 0.1.2 source version, in three steps.

Step 1 — 2026-09-28 (Verified Update Core M009), published in that order from
release-prep commit e8e07eb, tagged v0.1.2:

Step 2 — 2026-10-02 (Eggpack Manifest Interoperability M004), published in that
order from publication source 02a1d32:

Step 3 — 2026-10-04 (Acquisition Transport M009), published from release-prep
commit b485228:

Complete crates.io 0.1.2 publication set: eggup-core, eggup-archive,
eggup-acquisition, eggup-eggfetch, eggup-eggpack, eggup-curl.

eggup-service and eggup-transport-footprint share the 0.1.2 source version
and are still not published. eggup-transport-footprint is
publish = false by design and has no edge in the published adapter graph.

Step 3: the external-curl adapter promoted to the registry

eggup-curl implements AcquisitionTransport on top of an external curl
process, so a consumer can acquire artifacts without embedding an HTTP/TLS
stack in its binary. It was fully qualified under Acquisition M005–M008 but had
never been published, which left the lightweight path reachable only from a
local checkout. M009 published it as a package promotion; no transport
semantics changed, and no crates/ source, manifest, or version was edited.

What the published version carries:

  • Exact caller-selected URLs only. No discovery and no fallback inside the
    adapter; release/version/mirror policy stays caller-owned.
  • A caller-supplied curl executable invoked with no shell and no internal
    sudo. Transport fallback (curl <-> Eggfetch) lives in
    eggup-acquisition::ComposedTransport and is never release/source fallback.
  • Explicit connect/total ceilings as min(request, adapter) plus an
    independent parent wall deadline, serialized at microsecond precision so
    sub-second ceilings are passed truthfully instead of being widened.
  • Cancellation and timeout kill and reap the owned child before returning.
  • Exact HTTP 404 becomes FetchOutcome::NotFound; TLS/5xx/timeout/cancellation/
    size/staging failures stay hard acquisition failures.
  • Bounded streaming into Eggup-owned staging with a private temp sibling and
    race-safe no-clobber promotion. The temp pathname is never handed back to
    curl for reopening.
  • Redirect, protocol, and proxy policy are explicit. Diagnostics use category
    text plus the redacted URL, so raw curl output, command lines, and proxy
    credentials never appear in an error.

Two defects from the 2026-10-04 workspace bug audit are fixed in this
version, because it was published after that commit: an https request could
previously follow a redirect down to cleartext http with no error and no
diagnostic (--proto-redir is now narrowed per request), and coincident
connect/total ceilings mislabelled a total-deadline timeout as a connect
timeout.

Platform note

Live local HTTP/curl evidence is carried by the Linux and macOS lanes. Hosted
Windows runners refused the historical spawned-curl loopback case, so the
Windows lane carries the portable adapter, process, and error-path fixtures
only. No Windows live HTTP/curl result is claimed for this release.

Known caveat: eggup-acquisition 0.1.2 published content

eggup-acquisition 0.1.2 was published from 02a1d32 on 2026-10-02 and does
not contain the two workspace bug-audit fixes that landed afterwards in
0b8cb98:

  • the owned .part file leaked when the permission-hardening step failed;
  • ComposedTransport handed the secondary adapter the caller's full
    FetchLimits instead of the remaining budget, so one composed fetch could run
    for roughly twice the caller's documented total deadline.

The second is reachable today by any consumer that composes two transports from
the registry. Until eggup-acquisition is republished with the fix, such
consumers should either pin a later version or set a total deadline that
tolerates the doubled composed window. This predates step 3 and is not
introduced by it. eggup-curl keeps a caret-compatible eggup-acquisition
requirement, so it inherits an eggup-acquisition 0.1.3 automatically once one
is published.

M004: producer manifest promoted to the registry

eggup-eggpack previously pinned eggpack-manifest to an immutable Eggpack Git
revision and was publish = false, so the adapter could not be consumed from a
registry at all. Eggpack published eggpack-manifest 0.1.0 on 2026-10-02
(https://crates.io/crates/eggpack-manifest/0.1.0), and M004 promoted the adapter
to the exact registry dependency eggpack-manifest = "=0.1.0".

The published eggpack-manifest 0.1.0 src/lib.rs is byte-identical to the
source at the revision the adapter used to pin, so this is a promotion of the
same bytes rather than a substitution of a source. No adapter requalification
was needed.

The adapter also gains the caller-bound destination seam:

  • ManifestProjection::default_destinations
  • materialize_artifact_set_with_destinations
  • core_plan_for_archive_with_destinations

Manifest install values remain producer default identity only. The adapter
still selects no release, verifies no authenticity, and authorizes no
filesystem destination.

Why the publication order matters

cargo package and cargo publish resolve the packaged manifest's
dependencies from crates.io, so the order is a hard constraint, not a
convention. Before eggup-acquisition 0.1.2 existed, eggup-eggfetch 0.1.2
could not pass its own package verification (two E0308 mismatches: the
published 0.1.1 seam types max_artifact_bytes as Option<u64> while the
0.1.2 finite-bounds seam types it as u64), and eggup-eggpack 0.1.2 could
not produce a package at all because its exact =0.1.2 pin had no registry
candidate. Publishing acquisition first resolved both. Step 3 was likewise
ordered after step 2 so that eggup-curl's packaged manifest had a registry
candidate for its eggup-acquisition requirement.

Verification

Hosted CI green on each publication source (Stable checks, MSRV check,
macOS tests, Windows archive/acquisition/service tests). cargo package and
cargo publish --dry-run clean for all six crates from a clean tree with no
--allow-dirty.

Three temporary external projects outside the repository, with only registry
dependencies and no [patch], path, or Git override, resolved exact =0.1.2
and passed smoke: the adapter-only graph, the Eggsact-shaped four-crate graph,
and the eggup-curl graph. The last one exercises the published package end to
end — public API construction, deadline-ceiling clamping, typed unavailability
for an unspawnable executable, typed cancellation, and live loopback HTTP where
200 is an ordinary success, exact 404 is NotFound, and an artifact stream is
promoted into caller-owned staging — 6/6 passing. All three lockfiles show one
registry source per package with no git+ or path entry, and the lockfile
checksums match the registry.

Source tag caveat

The v0.1.2 tag was not moved and still points at e8e07eb. As of the
2026-10-04 bug-audit commit, none of the six published crates is
reproducible from that tag any more; each has moved since it. Do not treat
v0.1.2 as a source reference for any published artifact. Each crates.io
version instead carries its own exact publication commit in
.cargo_vcs_info.json:

  • eggup-core, eggup-archive — e8e07eb
  • eggup-acquisition, eggup-eggfetch, eggup-eggpack — 02a1d32
  • eggup-curl — b485228

Contract

MSRV 1.89, edition 2021, MIT. Integrity is SHA-256 checksum evidence only; no
authenticity or signature verification is claimed by any crate in this release.
Egress archive/pair adoption (Consumer M006 / Egress Delivery M003) is
unblocked against the published packages. The producer manifest seam is now
registry-consumable; Eggsact's own Git-to-registry migration remains separately
authorized in eggstack/eggsact. The cargo-cleanme Phase 10 self-update path is
unblocked against the published eggup-curl; cargo-cleanme retains
release/version/fallback/install policy.

Assets 2
Loading