Repository navigation
Whitelists via environment variables + CI trigger fix - #4
Merged
Merged
Conversation
Comma-separated hex pubkeys in WRITE_WHITELIST_PUBKEYS / READ_WHITELIST_PUBKEYS take precedence over the JSON whitelist files, for hosted platforms where per-environment config lives in env vars. A set-but-blank variable falls back to the files rather than becoming an empty (allow-everyone) whitelist, so an accidentally empty variable fails closed. Covered by unit tests and a new e2e -env mode, wired into CI alongside the existing three modes. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Pushes to PR branches were triggering both the push and pull_request workflows, running CI twice per change. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Hi Barry, thanks for merging #3 I appreciate it — this is the second of the two PRs mentioned there. It adds one small feature for your consideration: supplying the whitelists via environment variables. It builds on the merged migration and follows the same conventions (tests, e2e mode, README section).
This is a very useful feature for people who deploy to hosting services like Railway (e.g. me) as it allows edit read/write lists as env vars in the hosting service rather than in the json/code. I believe this is consistent with the approach taken by you for all your other Khatru relays.
What is this PR
WRITE_WHITELIST_PUBKEYS/READ_WHITELIST_PUBKEYSenv vars — comma-separated hex pubkeys that take precedence over the corresponding JSON whitelist files. Useful on hosted platforms (Railway, Fly, etc.) where per-environment config lives in env vars rather than files.master/main, so PR branches don't run the workflow twice (push + pull_request).Behaviour
No breaking changes
No database, dependency, or file-format changes; file-based configuration is untouched.
Testing
TestWhitelistsFromEnv— env wins over files for both lists, blank var falls back, commas/whitespace-only var falls back, env works with no file present-envmode for the existing harness — env-listed keys can read/write while file-listed keys are rejected (priority), and blank vars fall back to the files. The existing-matrix/-open/-legacymodes now scrub these vars from the environment first, so ambient shell state can't contaminate the file-based checks.-envmode runs as a fourth e2e step alongside the existing three (this PR's pull_request checks run it)Thank you for your consideration
Best regards
Rod