2026-06-04 21:07:42 +01:00
|
|
|
[package]
|
Stand Idunn up as its own repository
Extracted from Odin with full history via subtree split -- 136 commits, not a
flat copy. Idunn had lived as crates/idunn-daemon inside the repository of a
service it manages, which inverted the authority it exists to hold: doctrine
says Idunn must start, recover, observe and report while any managed target is
absent, and it was a directory inside one.
Manifest made standalone: workspace inheritance replaced with concrete edition,
license and publish; package renamed idunn; and cultmesh-rs moved off the
vendored path onto CultLib at c13b6ba, where the reconciled crate now lives.
All three substrate deps now resolve from CultLib and nothing resolves from
Odin.
The severing was small because most of it had already happened. idunn-daemon
already sourced its contracts from cultnet_rs -- brakes, service identity,
runtime activation, expected incarnation. One residual odin_core import
remained, and four of its six symbols were not odin-core's to begin with; it
merely re-exported them from cultnet_rs. drivers.rs was already importing two
of those directly, so the crate disagreed with itself about where they came
from.
Behaviour preserved exactly: 63 passed / 18 failed here, identical to the
results in the Odin tree. The 18 are Windows path semantics -- Linux
deployment paths against Path::is_absolute -- not regressions.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-05 17:51:56 +02:00
|
|
|
description = "GameCult deployment admission and daemon-survival authority"
|
|
|
|
|
name = "idunn"
|
2026-06-04 21:07:42 +01:00
|
|
|
version = "0.1.0"
|
Stand Idunn up as its own repository
Extracted from Odin with full history via subtree split -- 136 commits, not a
flat copy. Idunn had lived as crates/idunn-daemon inside the repository of a
service it manages, which inverted the authority it exists to hold: doctrine
says Idunn must start, recover, observe and report while any managed target is
absent, and it was a directory inside one.
Manifest made standalone: workspace inheritance replaced with concrete edition,
license and publish; package renamed idunn; and cultmesh-rs moved off the
vendored path onto CultLib at c13b6ba, where the reconciled crate now lives.
All three substrate deps now resolve from CultLib and nothing resolves from
Odin.
The severing was small because most of it had already happened. idunn-daemon
already sourced its contracts from cultnet_rs -- brakes, service identity,
runtime activation, expected incarnation. One residual odin_core import
remained, and four of its six symbols were not odin-core's to begin with; it
merely re-exported them from cultnet_rs. drivers.rs was already importing two
of those directly, so the crate disagreed with itself about where they came
from.
Behaviour preserved exactly: 63 passed / 18 failed here, identical to the
results in the Odin tree. The 18 are Windows path semantics -- Linux
deployment paths against Path::is_absolute -- not regressions.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-05 17:51:56 +02:00
|
|
|
edition = "2024"
|
|
|
|
|
license = "MIT"
|
|
|
|
|
publish = false
|
2026-06-04 21:07:42 +01:00
|
|
|
|
|
|
|
|
[[bin]]
|
|
|
|
|
name = "idunn"
|
|
|
|
|
path = "src/main.rs"
|
|
|
|
|
|
2026-07-19 21:04:21 +01:00
|
|
|
[[bin]]
|
|
|
|
|
name = "idunn-provision"
|
|
|
|
|
path = "src/bin/idunn-provision.rs"
|
|
|
|
|
|
Host actuator: Idunn manages a workload on a Windows host it cannot touch
A managed host runs idunn-host in the user session. It dials Idunn's hub
over CultNet RUDP on the mesh, proves itself with a host actuator service
identity, and executes the runner and workload ports for its host: fetch
the exact frozen revision, build with the host's cargo under the binding's
allowed programs, install the sealed release, start the workload as a
child, report pid, creation time and executable digest, stop on request.
It keeps no transaction state and decides nothing.
On the Idunn side the engine chooses the runner and workload driver per
plan from the binding's driver tag; the yggdrasil daemon is still the
single deployment and continuity authority, and a binding of the old kind
takes the same path it always did. Every request is signed by Idunn's
identity and every report by the host's; both ends refuse the other's
message unless signature, session nonce and sequence hold. The hub admits
its own firewall allow the way the route driver does.
idunn-provision learns to enroll and export the host actuator identity.
The unit gains --host-actuator-bind on the mesh address.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
2026-09-11 13:49:25 +02:00
|
|
|
[[bin]]
|
|
|
|
|
name = "idunn-host"
|
|
|
|
|
path = "src/bin/idunn-host.rs"
|
|
|
|
|
|
2026-10-22 18:53:29 +02:00
|
|
|
[[bin]]
|
|
|
|
|
name = "idunn-launch"
|
|
|
|
|
path = "src/bin/idunn-launch.rs"
|
|
|
|
|
|
2026-07-19 21:04:21 +01:00
|
|
|
[lib]
|
|
|
|
|
name = "idunn_daemon"
|
|
|
|
|
path = "src/lib.rs"
|
|
|
|
|
|
2026-06-04 21:07:42 +01:00
|
|
|
[dependencies]
|
|
|
|
|
anyhow = "1"
|
Bump CultLib pin to 61549aa: anchor-export permission fix
Idunn's cultmesh-rs/cultcache-rs/cultnet-rs pin moves from c13b6ba to
CultLib origin/main 61549aa, picking up e9b91c1 ("Preserve public
trust-anchor parent permissions"). That fix matters here: Idunn calls
export_service_identity_trust_anchor from provisioning.rs:129 and
control_plane.rs:6633 to publish a public anchor into a directory another
service reads from. Before the fix, export routed through the same
prepare_parent helper as private enrollment and chmod'd that directory
0700 on every export, which would lock the legitimate reader out instead
of protecting anything. CultLib now splits ensure_parent (export, no
narrowing) from prepare_private_parent (enrollment only).
Encoding audit (c13b6ba..61549aa in cultcache-rs/cultnet-rs/cultmesh-rs/
contracts, 21 commits): none touch the eight record types Idunn persists
or verifies (GameCultServiceTrustAnchorRecord, IdunnDaemonHealthTrust
BindingRecord, IdunnDeploymentBrakeRecord, IdunnExpectedIncarnationRecord,
IdunnLifecycleBrakeRecord, IdunnProcessWriteLeaseRecord, IdunnRuntime
ActivationRecord, OdinRuntimeTopologyCorrelationRecord).
- 9e6027e adds only a test (byte_slot_migration.rs); no production flip
lands in this range.
- 2ba404c/96138ff/a3e6877/etc. touch MediaStreamContracts and
media_stream_wire record types (Muninn/Ratatoskr's media path) that
Idunn never derives, persists or reads.
- c2a9a6e changes cultcache-rs's Windows-only atomic-replace retry
(cfg(windows) MoveFileExW), not record encoding, and Idunn targets
Linux.
- 47b9fc4/d3bc6e6/66f05e1 are cultnet-rs rudp/transport changes with no
record-shape effect.
No re-encode guard in Idunn (drivers.rs, control_plane.rs, provisioning.rs
canonical-bytes checks) is at risk; this is a pin bump, not a store
migration.
Schema-id audit: fcc49cf ("Consolidate CultNet schema contracts") moves
JSON Schema files and changes their $id to
https://github.com/GameCult/CultLib/contracts/cultnet/... inside
packages/cultnet-ts and the C# reference implementation. Idunn's Rust
source and tests contain no reference to cultnet-ts/contracts,
schema_catalog, content_hash, CultNetSchemaRegistry or
builtin_schema_registry. Not a consumer.
Live-branch audit: origin/claude/windows-host-actuator (the branch the
live yggdrasil binary was built from, last commit 9dc80f8) is fully
contained in origin/main (git merge-base --is-ancestor confirms it) and
still carries the old c13b6ba pin. This bump is based on origin/main only;
the live branch is not touched here and would need its own follow-up.
Cargo.lock: cargo update -p cultmesh-rs -p cultcache-rs -p cultnet-rs
moved exactly four git-sourced packages (cultmesh-rs, cultcache-rs,
cultcache-rs-derive, cultnet-rs) to the new rev; the lockfile diff is only
their `source = git+...?rev=...` lines, no checksums, versions, or
unrelated packages changed.
No Idunn source changes were needed: CultLib made no API-breaking rename
or reshape Idunn depends on. cargo check --locked (Windows, compile gate
only) and cargo check --locked --tests both pass clean.
Verification ran on yggdrasil (Linux, the deploy target), not the
Windows workstation. Built a throwaway unprivileged toolchain (no sudo,
no docker) under ~/idunn-pin-61549aa since /srv/build is root:idunn
0755 and gamecultadmin has no docker-group access; rustc/cargo 1.95.0
matches the recipe's rust:1.95-bookworm image exactly. `cargo test --lib`:
117 passed, 9 failed, 2 ignored. All 9 failures require root privilege or
ufw (frozen-source root ownership, sealed-release root ownership, runner
cache/secret chown, service-credential 0400 root inode, write-lease
actuation, host-actuator-hub ufw allow) -- capabilities this unprivileged
non-containerized session does not have, not CultLib regressions. Proved
by re-running the identical suite at the old c13b6ba pin in the same
unprivileged environment: identical 117 passed / 9 failed, same 9 test
names, same errors. All 16 provisioning:: tests pass at the new pin,
including identity_enrollment_and_export_are_immutable_and_paths_cannot_alias
and provider_and_odin_anchor_exports_are_profile_exact_immutable_and_non_aliasing,
which cover the trust-anchor export path this bump fixes. `cargo build
--release --locked` also succeeds. Both throwaway directories
(~/idunn-pin-61549aa, ~/idunn-baseline-c13b6ba) were removed from
yggdrasil afterward.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-13 19:25:50 +02:00
|
|
|
cultmesh-rs = { git = "https://github.com/GameCult/CultLib.git", rev = "61549aa90bf1937a2bd4fc7d9d190d74d366f69e", package = "cultmesh-rs" }
|
|
|
|
|
cultcache-rs = { git = "https://github.com/GameCult/CultLib.git", rev = "61549aa90bf1937a2bd4fc7d9d190d74d366f69e", package = "cultcache-rs" }
|
|
|
|
|
cultnet-rs = { git = "https://github.com/GameCult/CultLib.git", rev = "61549aa90bf1937a2bd4fc7d9d190d74d366f69e", package = "cultnet-rs" }
|
2026-06-15 22:50:43 +01:00
|
|
|
rmp-serde = "1.3"
|
2026-07-16 18:34:19 +01:00
|
|
|
sha2 = "0.10"
|
|
|
|
|
chrono = "0.4"
|
|
|
|
|
serde = { version = "1", features = ["derive"] }
|
2026-07-17 02:37:42 +01:00
|
|
|
ed25519-dalek = "2.2"
|
2026-09-02 18:31:13 +02:00
|
|
|
toml = "0.8"
|
2026-07-19 20:45:30 +01:00
|
|
|
uuid = { version = "1", features = ["v4"] }
|
2026-11-01 02:33:01 +01:00
|
|
|
serde_json = "1"
|
2026-07-17 02:37:42 +01:00
|
|
|
|
|
|
|
|
[dev-dependencies]
|
|
|
|
|
tempfile = "3"
|
2026-07-18 21:22:36 +01:00
|
|
|
|
|
|
|
|
[target.'cfg(unix)'.dependencies]
|
|
|
|
|
libc = "0.2"
|
Host actuator: Idunn manages a workload on a Windows host it cannot touch
A managed host runs idunn-host in the user session. It dials Idunn's hub
over CultNet RUDP on the mesh, proves itself with a host actuator service
identity, and executes the runner and workload ports for its host: fetch
the exact frozen revision, build with the host's cargo under the binding's
allowed programs, install the sealed release, start the workload as a
child, report pid, creation time and executable digest, stop on request.
It keeps no transaction state and decides nothing.
On the Idunn side the engine chooses the runner and workload driver per
plan from the binding's driver tag; the yggdrasil daemon is still the
single deployment and continuity authority, and a binding of the old kind
takes the same path it always did. Every request is signed by Idunn's
identity and every report by the host's; both ends refuse the other's
message unless signature, session nonce and sequence hold. The hub admits
its own firewall allow the way the route driver does.
idunn-provision learns to enroll and export the host actuator identity.
The unit gains --host-actuator-bind on the mesh address.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
2026-09-11 13:49:25 +02:00
|
|
|
|
|
|
|
|
[target.'cfg(windows)'.dependencies]
|
|
|
|
|
windows-sys = { version = "0.59", features = [
|
|
|
|
|
"Win32_Foundation",
|
|
|
|
|
"Win32_Security",
|
|
|
|
|
"Win32_Security_Authorization",
|
|
|
|
|
"Win32_System_RemoteDesktop",
|
|
|
|
|
"Win32_System_Threading",
|
|
|
|
|
] }
|