chore(secrethub): bump tackle to v0.4.1

[loadez]

No description provided.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: ccac500413

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Do not suppress the h2c advisory while h2c remains enabled

For clients able to reach the pod or its ClusterIP directly, this allowlist hides a reachable unauthenticated DoS: scheme: :http selects a cleartext transport but does not make Cowboy HTTP/1.1-only, because clear listeners accept HTTP/2 prior knowledge/h2c by default. I checked Secrethub.Application.openid_connect_services/0, which supplies only options: [port: port], and the Helm service exposes that listener without configuring protocol_options: [protocols: [:http]]; therefore crafted HTTP/2 :scheme values can still reach the vulnerable plug_cowboy 2.5.2 path. Upgrade plug_cowboy or explicitly disable HTTP/2 before ignoring this advisory.

Useful? React with 👍 / 👎.

[skipi]

Four notes. The service_per_exchange change fixes a real misrouting bug, but two things about it need sorting before this deploys, and the audit-file rationale has a hole.

1. service_per_exchange: true renames live queues, and nothing cleans up the old ones.

Today both routes share one queue, secrethub.secret_destroyer.deleted. After this change they become secrethub.secret_destroyer.project_exchange.deleted and secrethub.secret_destroyer.organization_exchange.deleted, each with new .dead and .delay siblings and a new service exchange. Tackle only ever creates — it never unbinds or deletes. So on deploy: anything sitting in the old queue at cutover is never consumed again (dropped secret-destroy events for orgs and projects), and the old service exchange stays bound to project_exchange and organization_exchange, so the abandoned queue keeps receiving every delete event indefinitely with no consumer attached. On a rolling deploy, old and new pods also consume from different queues for the duration of the overlap.

Could you add the cutover steps to the PR description — drain, then unbind and delete the old exchange/queue trio post-deploy? The code change is right; it just isn't self-sufficient.

2. The justification comment is factually wrong and will mislead the next reader.

The comment says "Without service_per_exchange: true, tackle >= 0.4 derives the same queue name … for both routes". service_per_exchange has existed since tackle v0.2.2 (commit e3decb0) and defaults to false in every version through v0.4.1 — see lib/tackle/multiconsumer.ex:46 and service_name/3. v0.4.1 without the flag derives queue names identically to the tag this PR replaces. The route collision is pre-existing and version-independent: a genuine bug, but not one this bump introduced. As written, the comment tells whoever hits a misrouting incident that rolling tackle back would fix it, which it would not.

3. The new test cannot fail.

owner_deleted_consumer_test.exs calls Tackle.Multiconsumer.service_name/3 with hardcoded string literals and asserts that the true and false variants differ. It never references OwnerDeletedConsumer — remove the service_per_exchange: true line from the consumer and both new tests still pass. Asserting against the consumer's own derived queue names (or its generated consumer module names) would actually guard the behaviour the comment describes.

4. The h2c suppression premise is inverted.

GHSA-q8x4-x7mp-5vg2 is justified on the grounds that the OIDC server runs with scheme: :http and no protocol_options, therefore "Cowboy serves HTTP/1.1 only here, so the HTTP/2-specific :scheme pseudo-header parsing path is never invoked." Reading cowboy source (2.7.0 and 2.12.0, which bracket the locked 2.9.0 — identical in both):

• cowboy_clear.erl:43 — Protocol = case maps:get(protocols, Opts, [http2, http]). The default protocol set already includes HTTP/2; nothing has to be enabled.
• cowboy_http.erl:487-490 — the PRI * HTTP/2.0 connection preface is accepted directly.
• cowboy_http.erl:865-873 — Upgrade: h2c is handled too.
• cowboy_http.erl:884-894 — and this is the part that inverts the argument: prior-knowledge HTTP/2 is accepted only when Transport:secure() is false, and explicitly rejected on TLS with "Clients that support HTTP/2 over TLS MUST use ALPN". scheme: :http is therefore precisely the configuration under which cowboy will speak h2c, not the one that prevents it.

The tainted value does reach the vulnerable code unvalidated: cowboy_http2.erl:498,516 writes the client-supplied :scheme pseudo-header into the Req map, ensure_port/2 at :546-548 has a catch-all clause with no scheme validation, cowboy_req.erl:188 returns it, and the locked plug_cowboy 2.5.2 does scheme: String.to_atom(:cowboy_req.scheme(req)) at lib/plug/cowboy/conn.ex:27 — the unbounded atom creation. The 2.8.1 fix replaces that with a two-clause case over the "http"/"https" literals.

In fairness on blast radius, and this is not in the file either: helm-chart/templates/emissary-ingress/mappings.yaml:766-769 fronts this port publicly (hostname: "*", prefix /.well-known/ → secrethub-openid-connect-http:5000), but that Mapping sets no allow_upgrade and no protocol_version, so Envoy speaks HTTP/1.1 upstream and an internet-borne preface is not forwarded verbatim. Residual exposure is in-cluster (any pod reaching ClusterIP:5000 or the pod IP directly) plus on-prem installs with different fronting. Real, but not internet-facing.

Either way the fix is one line: protocol_options: [protocols: [:http]] on the child spec, which cowboy honours at cowboy_clear.erl:43. That makes the suppression true as written, instead of true by accident.

Also worth noting: this service still locks cowboy 2.9.0, cowlib 2.11.0, plug 1.13.6 and plug_cowboy 2.5.2, and mix.lock is otherwise untouched here — so several of the advisories being suppressed have fixed versions available that sibling PRs in this same batch chose to upgrade to instead. Worth settling which disposition is the intended policy, so the audit trail doesn't record two different verdicts on the same advisory from the same day.