Repository navigation
AWS signing is a shared crate and core signs through an origin signer - #1391
Draft
jwrosewell wants to merge 36 commits into
Draft
jwrosewell wants to merge 36 commits into
jwrosewell wants to merge 36 commits into
Conversation
Core signed reads from the publisher's origin and from each asset route's origin with one cloud vendor's signing scheme, and its settings knew that scheme's region and credential key names, so a signed read with another scheme was a change to core. Core now keeps an origin authentication interface. OriginSigner, in the new origin_auth module, signs the headers of a request for a method on a final address and removes every header in the scheme's own namespace. A source's auth table keeps its shape: type names the signer, origin_query is read by core, and the rest of the table belongs to the signer named. A crate offers a signer on its builder with with_origin_signer, which also declares the settings of the signer's table that hold the name of a secret and the key name each takes when left out. The registry builds the signer where a source names it, so a type nothing offers is refused at startup naming the signers on offer, and a table the signer cannot use is refused naming the setting. The declared secrets are looked up as the settings load at both auth paths, a left out setting with a default is written in before the lookup, a written one naming no key fails deploy validation naming its path, and the configuration page masks them. The s3_sigv4 signer moves to crates/shared/aws, the package trusted-server-shared-aws, with the same settings, defaults, secret key references and signing. The stock build offers it through crates/trusted-server-modules, so a deployment's settings read as before. The deprecated spelling s3_sig_v4 is no longer read. Core's tests sign through a fixture signer the origin_auth module keeps for them. The vendor crate's tests cover the published signature example, the registry and deploy refusals, and the lookup and masking of its credentials. Design: docs/superpowers/specs/2026-10-14-origin-signing-design.md
A registry carries no Debug, so a test that expects a refusal from building one matches on the result rather than calling expect_err, which the check of the signer crate's tests refused.
The modules crate is gone, so the AWS signer is listed by each adapter and the ts command after the loading cache, where the removed crate listed it. The registry builds the sources with the signers on offer and keeps the identifier modules, and the lib loses both the Flight rewriter and the signing module to their crates.
Each series removed its own vendor from the same settings tests, so both removals stand: the Tinybird and S3 canaries, helpers and the legacy store test that only covered those two go. The registry keeps the origin signers and the analytics modules, and the guide lists both builder methods.
# Conflicts: # CHANGELOG.md
Deploy validation builds every auth table that names an offered signer, as the settings load does, so a table the signer cannot use fails validation for any signer. The AWS builder then needs no validator of its own and offers the signer as an implementation, with no page module, which the shipped-modules test expects of a builder without a section. The S3 secret paths leave core's static list, because the signers the builders offer declare them, and the shared README and the AWS builder's comment name the adapters' module lists in place of the deleted modules crate.
# Conflicts: # crates/trusted-server-core/src/publisher.rs
…t changes for a deployment Review round 1 found that the design named a modules crate that no longer exists and deploy rules the AWS builder does not carry, and that a type nothing offers passes ts config validate and ts config push and only stops the adapter at startup. The design now says so, calls the removal of s3_sig_v4 breaking, and leaves closing the gap as an open question. It also gives the refusals by stage, the answers when signing fails, the rollout, the adapters that run each path, the settings that change and the tests that are missing or cannot fail, and records the review round. The changelog entry, the integration guide and the configuration guide drop the same stale sentences: the modules crate, the builder's validate function, and a blank session token read as no token.
Review round 2 found that the specs pull request is now #1342, because #1084 was closed, and three statements to tighten. The design now names #1342, says that the preflight signs without calling remove_namespace_headers, which makes no difference for s3_sigv4, says that GET /health on Fastly and Spin and the Fastly debug probes are still answered when an adapter cannot build its state, and limits the missing test for an empty session_token to deploy validation. The Tinybird entry in the changelog no longer names the deleted modules crate.
The analytics entry keeps the last names series' wording, which names the ts tool and says only the Fastly adapter hands the sink to the auction.
jwrosewell
added this pull request to stack #1401
October 15, 2026 17:56
jwrosewell
removed this pull request from stack #1401
October 15, 2026 20:51
This was referenced Oct 17, 2026
jwrosewell
added this pull request to stack #1408
October 17, 2026 09:05
This branch has not been deployed
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
1 participant
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.
Summary
Changes
crates/trusted-server-core/srccrates/shared/awsdocs/superpowersdocs/guideCargo.lockcrates/shared/README.mdtrusted-server.example.toml.cargo/config.tomlcrates/trusted-server-adapter-axum/srccrates/trusted-server-adapter-cloudflare/srccrates/trusted-server-adapter-fastly/srccrates/trusted-server-adapter-spin/srccrates/trusted-server-cli/srcCargo.tomlCHANGELOG.mdcrates/trusted-server-adapter-axum/Cargo.tomlcrates/trusted-server-adapter-cloudflare/Cargo.tomlcrates/trusted-server-adapter-fastly/Cargo.tomlcrates/trusted-server-adapter-spin/Cargo.tomlcrates/trusted-server-cli/Cargo.tomlCloses
Closes #1338
Test plan
CI on this pull request at 8a69cb9 passed all 19 checks.
cargo test-fastly && cargo test-axumcargo clippy-fastly && cargo clippy-axumcargo fmt --all -- --checkcd crates/trusted-server-js/lib && npx vitest runcd crates/trusted-server-js/lib && npm run formatcd docs && npm run formatcargo build --package trusted-server-adapter-fastly --release --target wasm32-wasip1fastly compute serveChecklist
unwrap()in production code (clippy deniesunwrap_usedin CI)logmacros as AGENTS.md asks (notprintln!)On top of the backend naming series (#1390). Issue: #1338.
What this adds
What changes.
AWS request signing is a shared crate and core signs through an origin signer. Core's
s3_sigv4.rsand theS3SigV4AuthConfigsettings leave forcrates/shared/aws, and core keeps an origin authentication interface that the source series'authtables name a signer through.How it works.
crates/trusted-server-core/src/origin_auth.rsdeclares theOriginSignera module offers under a name, theOriginAuthtable everyauthsetting reads (itstype, the vendor neutralorigin_queryrule, and the signer's own settings), and the secret fields a signer declares so the settings load resolves and masks them as before.IntegrationBuilder::with_origin_signeroffers one, because a signer's secret settings must be known before the settings load, as a loading cache's are. The registry hands the signers on offer to the origin source when it builds the sources, and atypenothing supplies is refused at startup with the names on offer.ts config validatebuilds everyauthtable that names an offered signer, as the settings load does, so a table the signer cannot use fails validation and not the first start, whichever crate offers the signer. A table naming a signer the build does not offer is left alone, as its key references already were.crates/shared/awsholds the Signature Version 4 code with its tests and thes3_sigv4signer, and each adapter and thetscommand list its builder, so the stock build signs as today. Its builder offers the signer as an implementation, with no page module and no validator of its own.Why
A signing scheme is a vendor's, and core offers the neutral interface a signer implements. The object storage origin came into the stack signing through core's one scheme because that was where the scheme lived, and this moves it to where it belongs.
What breaks
Nothing for a deployment whose build links the AWS crate, which the stock adapters do, except that the deprecated spelling
s3_sig_v4is no longer read, because atypeis matched as written. A pushed settings document already carriess3_sigv4.The commits
tscommand list the AWS builder after the loading cache, where the removed modules crate listed it.authtable with its signer at deploy validation, so the AWS builder needs no validator and offers the signer as an implementation. The S3 secret paths leave core's static list, because the signers the builders offer declare them.What is not in this pull request
A vendor's own source module cannot reach the signers on offer and holds its own signer, because the source factory's interface is unchanged. The design page records it.