Status. This exists on upstream/main, where EC_RESPONSE_HEADERS is defined in
crates/trusted-server-core/src/ec/finalize.rs and duplicates the first entries of
INTERNAL_HEADERS. It is fixed in this stack. The list now lives once and the internal
header list is assembled from it at compile time, with a test that fails if the two drift.
Found while reviewing the Edge Cookie provider work in
PR #1043. The
duplication predates that pull request.
The problem
Two constants list the same four Trusted Server response header names. One is
used to strip Edge Cookie output headers from a response, the other is used to
stop internal headers reaching third parties. Adding a fifth managed header
means remembering both lists, and nothing fails if only one is updated.
What was checked and found
Read on main at commit d516a9e94 and again on the
PR #1043 branch.
crates/trusted-server-core/src/ec/finalize.rs:22-28 declares
EC_RESPONSE_HEADERS as x-ts-ec, x-ts-eids, x-ts-ec-consent and
x-ts-eids-truncated. It is used at finalize.rs:155 to strip Edge Cookie
headers from a response when the identity is not permitted.crates/trusted-server-core/src/constants.rs:53-77 declares
INTERNAL_HEADERS, whose first four entries are the same four names in the
same order, followed by 16 more.- The two lists have no relationship in code. Neither refers to the other and no
test compares them.
Why it matters
The lists mean different things, so merging them outright would be wrong. One
is "headers this deployment must never leak outward", the other is "headers Edge
Cookie finalization emits and therefore must be able to withdraw". They overlap
today by accident of history rather than by construction, and the overlap is
what makes a silent drift possible. A new managed Edge Cookie header added to
one list and not the other either leaks to a third party or survives on a
response where identity is not permitted.
How it is fixed in this stack
The two lists mean different things, so merging them outright would be wrong.
The fix expresses one in terms of the other rather than repeating the names.
PR #1043, commit
9f4061a6a ("Build the internal header list from the Edge Cookie response
headers"), defines the Edge Cookie output headers once and assembles
INTERNAL_HEADERS from that definition plus the rest, so a new Edge Cookie
header reaches both uses from a single edit. A test fails if the two ever drift.
The finalization code is also edited by
PR #1046, so this
issue is traceable through the stack rather than buried in a large diff, and it
should be closed when PR #1043
merges.
Note on authorship
This issue was drafted with AI assistance. Every file and line reference above
was read at the commits named. A human should review it before acting on it.
Found while reviewing the Edge Cookie provider work in
PR #1043. The
duplication predates that pull request.
The problem
Two constants list the same four Trusted Server response header names. One is
used to strip Edge Cookie output headers from a response, the other is used to
stop internal headers reaching third parties. Adding a fifth managed header
means remembering both lists, and nothing fails if only one is updated.
What was checked and found
Read on
mainat commitd516a9e94and again on thePR #1043 branch.
crates/trusted-server-core/src/ec/finalize.rs:22-28declaresEC_RESPONSE_HEADERSasx-ts-ec,x-ts-eids,x-ts-ec-consentandx-ts-eids-truncated. It is used atfinalize.rs:155to strip Edge Cookieheaders from a response when the identity is not permitted.
crates/trusted-server-core/src/constants.rs:53-77declaresINTERNAL_HEADERS, whose first four entries are the same four names in thesame order, followed by 16 more.
test compares them.
Why it matters
The lists mean different things, so merging them outright would be wrong. One
is "headers this deployment must never leak outward", the other is "headers Edge
Cookie finalization emits and therefore must be able to withdraw". They overlap
today by accident of history rather than by construction, and the overlap is
what makes a silent drift possible. A new managed Edge Cookie header added to
one list and not the other either leaks to a third party or survives on a
response where identity is not permitted.
How it is fixed in this stack
The two lists mean different things, so merging them outright would be wrong.
The fix expresses one in terms of the other rather than repeating the names.
PR #1043, commit
9f4061a6a("Build the internal header list from the Edge Cookie responseheaders"), defines the Edge Cookie output headers once and assembles
INTERNAL_HEADERSfrom that definition plus the rest, so a new Edge Cookieheader reaches both uses from a single edit. A test fails if the two ever drift.
The finalization code is also edited by
PR #1046, so this
issue is traceable through the stack rather than buried in a large diff, and it
should be closed when PR #1043
merges.
Note on authorship
This issue was drafted with AI assistance. Every file and line reference above
was read at the commits named. A human should review it before acting on it.