Allow the hosting credential to come from a named config path #164

New issue

Closed

opened 2026-09-06 23:05:26 +01:00 by vnprc-agent · 0 comments

vnprc-agent commented

2026-09-06 23:05:26 +01:00

Contributor

Let a deployment supply the hosting credential declaratively, so the one secret allod site deploy needs stops being imperative state that a rebuilt machine loses.

Primary goals:

An explicit config location — deploy and config accept the path to use, instead of resolving rclone's default and nothing else.
A credential that survives recreating the machine — a deployment can hold the ciphertext in its own secrets repository and have activation materialise it, the way every other credential on the host already works.
No secret in a site repository — the credential is per machine and per hosting account, not per site; one account serves every domain, so a site repository is the wrong home for it and would duplicate it besides.
The imperative path keeps working — allod site config writing rclone's default file stays the answer for anyone who does not want a secrets pipeline.

Current state and specifics

rcloneConfigPath (cmd/allod/site_config.go:198-218) asks rclone config file, falling back to $XDG_CONFIG_HOME then $HOME/.config/rclone/rclone.conf, and writes at mode 0600 (cmd/allod/site_config.go:41). Deploy shells out to rclone with no --config, so both ends use whatever rclone resolves.

That makes the credential ordinary state in a home directory. It is the only thing in the deploy path that is not reproducible from source: a machine rebuilt from its configuration comes back without it, and the absence is discovered at the next publish rather than at rebuild time. rclone's obscure is not encryption — it defeats shoulder-surfing and nothing else — so the file is plaintext-equivalent, protected by its mode.

The mechanism this unblocks is age-encrypted delivery: the deployment keeps the ciphertext in its secrets repository, encrypted to the host, and activation writes the plaintext to a runtime path. That needs only one thing from this repository — the ability to name the config file — and the rest is the deployment's own composition, which is why this issue stops at the flag and the contract.

Reading a config from a runtime path implies the file may be root-owned or on a tmpfs, so the resolution order and the failure message when the file is absent both matter more than they do today.

Scope

In: naming the config location, the precedence between an explicit value and rclone's own resolution, and the errors when the named file is missing or unreadable.

Out: any particular secrets tool, and the deployment-side composition that produces the file — those live in the consuming deployment. The credential's lifecycle commands are allod/tools#163; the deploy preflight is allod/tools#162.

Let a deployment supply the hosting credential declaratively, so the one secret `allod site deploy` needs stops being imperative state that a rebuilt machine loses. Primary goals: - **An explicit config location** — deploy and config accept the path to use, instead of resolving rclone's default and nothing else. - **A credential that survives recreating the machine** — a deployment can hold the ciphertext in its own secrets repository and have activation materialise it, the way every other credential on the host already works. - **No secret in a site repository** — the credential is per machine and per hosting account, not per site; one account serves every domain, so a site repository is the wrong home for it and would duplicate it besides. - **The imperative path keeps working** — `allod site config` writing rclone's default file stays the answer for anyone who does not want a secrets pipeline. ### Current state and specifics `rcloneConfigPath` (`cmd/allod/site_config.go:198-218`) asks `rclone config file`, falling back to `$XDG_CONFIG_HOME` then `$HOME/.config/rclone/rclone.conf`, and writes at mode 0600 (`cmd/allod/site_config.go:41`). Deploy shells out to rclone with no `--config`, so both ends use whatever rclone resolves. That makes the credential ordinary state in a home directory. It is the only thing in the deploy path that is not reproducible from source: a machine rebuilt from its configuration comes back without it, and the absence is discovered at the next publish rather than at rebuild time. rclone's `obscure` is not encryption — it defeats shoulder-surfing and nothing else — so the file is plaintext-equivalent, protected by its mode. The mechanism this unblocks is age-encrypted delivery: the deployment keeps the ciphertext in its secrets repository, encrypted to the host, and activation writes the plaintext to a runtime path. That needs only one thing from this repository — the ability to name the config file — and the rest is the deployment's own composition, which is why this issue stops at the flag and the contract. Reading a config from a runtime path implies the file may be root-owned or on a tmpfs, so the resolution order and the failure message when the file is absent both matter more than they do today. ### Scope In: naming the config location, the precedence between an explicit value and rclone's own resolution, and the errors when the named file is missing or unreadable. Out: any particular secrets tool, and the deployment-side composition that produces the file — those live in the consuming deployment. The credential's lifecycle commands are `allod/tools`#163; the deploy preflight is `allod/tools`#162.

vnprc-agent referenced this issue

2026-09-06 23:05:55 +01:00

Authenticate the hosting remote in the deploy preflight #162

vnprc-agent referenced this issue

2026-09-06 23:05:56 +01:00

Let allod site check, update and rotate the hosting credential #163