selective profile inheritance

[kiyoon]

Summary

I want a way to shrink the command

fnox -P openai,database-local,no-log-upload exec -- api

into a short form like

fnox -P api-local exec -- api

either with profile inheritance or an alias.

Problem

1. Top-level secrets are inherited by every profile

We can define shared secrets once under [secrets]:

[secrets]
# Intended for AI-enabled programs, but inherited by every profile.
OPENAI_API_KEY = { provider = "openai", value = "<encrypted-openai-key>" }

[profiles.api.secrets]
HUGGINGFACEHUB_API_KEY = { provider = "huggingface", value = "<encrypted-huggingface-key>" }

[profiles.ask-llm-one-off-script.secrets]
CLAUDE_API_KEY = { provider = "claude", value = "<encrypted-claude-key>" }
GEMINI_API_KEY = { provider = "gemini", value = "<encrypted-gemini-key>" }

[profiles.visualiser.secrets]
# It doesn't need OPENAI_API_KEY, but it inherits it anyway.
DATABASE_URL = { provider = "database-readonly", value = "<encrypted-database-url>" }

This avoids copying OPENAI_API_KEY, but api, ask-llm-one-off-script, visualiser, and every other profile inherit it. Many applications and one-off scripts use OPENAI_API_KEY, but not every program should receive its value. --no-defaults removes the complete top-level set; it does not let a profile select individual top-level secrets.

2. Complete application profiles duplicate shared secrets

Instead, each application profile can contain its complete secret set:

[profiles.api.secrets]
# First copy of the same OPENAI_API_KEY declaration and ciphertext.
OPENAI_API_KEY = { provider = "openai", value = "<encrypted-openai-key>" }
HUGGINGFACEHUB_API_KEY = { provider = "huggingface", value = "<encrypted-huggingface-key>" }

[profiles.ask-llm-one-off-script.secrets]
# Second copy of the same OPENAI_API_KEY declaration and ciphertext.
OPENAI_API_KEY = { provider = "openai", value = "<encrypted-openai-key>" }
CLAUDE_API_KEY = { provider = "claude", value = "<encrypted-claude-key>" }
GEMINI_API_KEY = { provider = "gemini", value = "<encrypted-gemini-key>" }

This gives each program only the secrets it needs and keeps runtime commands simple, but every overlapping program copies OPENAI_API_KEY and any associated metadata or inline Age ciphertext. Rotation or policy changes must update every copy without allowing them to drift.

3. Minimal profiles require every caller to compose the full set

We can deliberately make each profile small and reusable:

[profiles.openai.secrets]
OPENAI_API_KEY = { provider = "openai", value = "<encrypted-openai-key>" }

[profiles.huggingface.secrets]
HUGGINGFACEHUB_API_KEY = { provider = "huggingface", value = "<encrypted-huggingface-key>" }

[profiles.claude.secrets]
CLAUDE_API_KEY = { provider = "claude", value = "<encrypted-claude-key>" }

[profiles.gemini.secrets]
GEMINI_API_KEY = { provider = "gemini", value = "<encrypted-gemini-key>" }

Each caller must then select every required capability profile:

fnox -P openai -P huggingface exec -- api
fnox -P openai -P claude -P gemini exec -- ./ask-llm-one-off-script

This avoids secret duplication and prevents unrelated programs from receiving OPENAI_API_KEY, but every launcher, service definition, CI job, and developer command must repeat the complete ordered -P list. As applications gain more overlapping capabilities, it becomes easy to omit a profile, use the wrong order, or let different callers drift apart.

The desired model is:

• Minimal profiles represent reusable capabilities or overrides.
• Named application profiles select only the capabilities they need.
• Provider authentication and recipient permissions remain unchanged.
• Runtime commands select one stable name.

Example use case

The source profiles are deliberately small:

[profiles.openai.secrets]
OPENAI_API_KEY = { provider = "openai", value = "<encrypted>" }

# Same environment-variable name, but a developer-specific provider/value.
[profiles.openai-john.secrets]
OPENAI_API_KEY = { provider = "openai-john", value = "<encrypted>" }

[profiles.openai-jane.secrets]
OPENAI_API_KEY = { provider = "openai-jane", value = "<encrypted>" }

[profiles.log-upload.secrets]
ELASTICSEARCH_URL = { default = "https://elasticsearch.example.com:9200" }
ELASTICSEARCH_API_KEY = { provider = "log-upload", value = "<encrypted-api-key>" }

[profiles.no-log-upload.secrets]
ELASTICSEARCH_URL = { env = false, if_missing = "ignore" }
ELASTICSEARCH_API_KEY = { env = false, if_missing = "ignore" }

[profiles.database-local.secrets]
DATABASE_PASSWORD = { provider = "database-local", value = "<encrypted>" }

[profiles.database-azure.secrets]
DATABASE_PASSWORD = { provider = "azure", value = "database-password" }

[profiles.database-readonly.secrets]
DATABASE_PASSWORD = { provider = "database-readonly", value = "<encrypted>" }

[profiles.dvc-readwrite.secrets]
AZURE_STORAGE_SAS_TOKEN = { provider = "dvc-readwrite", value = "<encrypted>" }

[profiles.release-signing.secrets]
RELEASE_SIGNING_KEY = { provider = "release-signing", value = "<encrypted>" }

The openai, openai-john, and openai-jane providers may have different recipients and different API-key values. They all deliberately resolve to the same final environment-variable name. A later developer-specific profile can override the shared/default key without copying any of the application's other secret declarations.

Applications and roles need overlapping, but non-identical, subsets:

api-local       = openai + database-local + no-log-upload
api-azure       = openai + database-azure + log-upload
api-local-john  = api-local + openai-john
api-local-jane  = api-local + openai-jane
visualiser      = database-readonly + log-upload
ci-release      = dvc-readwrite + release-signing

Here, visualiser and ci-release never select an OpenAI profile, so they should not see OPENAI_API_KEY even if the caller happens to possess an identity that could decrypt it. Other AI-enabled scripts can selectively reuse openai, openai-john, or openai-jane without making AI access a global default.

Today, each row must become either a repeated CLI profile list or a profile that copies all of the underlying secret entries.

Proposed API: selective profile inheritance

One possible syntax is an ordered inherits list:

[profiles.api-local]
inherits = ["openai", "database-local", "no-log-upload"]

[profiles.api-azure]
inherits = ["openai", "database-azure", "log-upload"]

[profiles.api-local-john]
inherits = ["api-local", "openai-john"]

[profiles.api-local-jane]
inherits = ["api-local", "openai-jane"]

[profiles.visualiser]
inherits = ["database-readonly", "log-upload"]

[profiles.ci-release]
inherits = ["dvc-readwrite", "release-signing"]

Alternative API: named aliases

If inheritance inside a profile is undesirable, a separate alias table would provide the same runtime ergonomics:

[profile_aliases]
api-local = ["openai", "database-local", "no-log-upload"]
api-azure = ["openai", "database-azure", "log-upload"]
api-local-john = ["api-local", "openai-john"]
api-local-jane = ["api-local", "openai-jane"]
visualiser = ["database-readonly", "log-upload"]
ci-release = ["dvc-readwrite", "release-signing"]

Either way, runtime usage becomes:

fnox -P api-local exec -- api
fnox -P api-local-john exec -- api
fnox -P visualiser exec -- visualiser
fnox -P ci-release exec -- release

[jdx]

Implemented this in PR #770.

The proposed [profiles.<name>] inherits = [...] syntax now expands profiles in order, supports nested inheritance, and applies declarations on the aggregate profile last. It composes secrets, providers, lease backends, and default_provider; inherited fnox.<profile>.toml files are loaded as well. Unknown inherited profiles and cycles produce explicit errors.

One detail from the example: rrn is not defined in the profiles shown, so fnox will report it as an unknown inherited profile unless that definition exists elsewhere.

AI-assisted — Tool: Codex; model: openai/gpt-5; version: unavailable.

[kiyoon]

Thanks for the fast implementation! Yes, the rrn was an error I shouldn't have used.