fix(http): replace HTTPoison transport with Req

[iautom8things]

The Asgard strategy keeps HTTPoison and Hackney in consumer dependency graphs. Replace its token and JWKS transport with patched Req 0.7.4 while retaining existing authentication flows.

The client preserves Basic and form credentials, callback URI and PKCE verifier, nonce and RS256 verification, refresh-token retention, scopes and explicit legacy callbacks. Requests disable retries, redirects and decompression, retain finite connection/pool/receive timeouts, and return bounded errors without provider bodies or credentials. Request-local Finch options work when a host application configures a global named Finch pool, without changing that host pool or its defaults. Elixir 1.15 remains the minimum.

The initial 0.5.18 constraint excluded the fix for GHSA-655f-mp8p-96gv. The corrected lock changes only Req; Finch stays 0.22.0. Before the transport correction, three real Atlas-default tests reproduced the named-Finch conflict. They now pass.

The full 22-test suite, forced checked compilation and formatting passed. Independent correction review reran all 22 tests with zero failures and checked the running Req/Finch versions and absence of HTTPoison/Hackney. Real local HTTP covers reserved-character credentials, uncached JWKS during complete code callback, legacy callbacks, exact retry/redirect refusal, malformed responses, finite receive timeout, host-pool preservation and safe refusal of small compressed responses. Prior audits apply to the original transport implementation; the correction has its own independent evidence.

Atlas and Argos consumer tests, complete consumer dependency audits, release boot and deployed login verification remain required before consumer release. This PR proposes an immutable Git revision and does not publish a Hex package. The repository has no CI workflow or VERSION/CHANGELOG release convention, so its existing package version is retained.

Tracks Asgard transport remediation.

[greptile-apps]

Confidence Score: 3/5

The PR is not yet safe to merge because its new production transport is constrained to a Req release with a reachable response-decompression denial-of-service vulnerability.

Summary

• Preserves Basic and form-based client authentication, PKCE, callback URI, token fields, scopes, and legacy ID-token callbacks.
• Disables automatic retries and redirects and introduces capped connection and receive timeouts.
• Sanitizes provider errors and validates token and JWKS response shapes.
• Removes HTTPoison and Hackney from the dependency graph, but currently constrains Req to a release with a reachable decompression-denial-of-service vulnerability.

Diagram

sequenceDiagram
  participant App as Ueberauth application
  participant Client as Asgard Client
  participant Req as Req / Finch
  participant Provider as Asgard provider
  App->>Client: Exchange authorization code
  Client->>Req: POST /token (no retry or redirect)
  Req->>Provider: Form-encoded token request
  Provider-->>Req: JSON response
  Req-->>Client: Decompress and return body
  Client-->>App: Tokens or bounded error
  App->>Client: Verify ID token on cache miss
  Client->>Req: GET /certificates
  Req->>Provider: JWKS request
  Provider-->>Req: JSON JWKS response
  Req-->>Client: Decompress and return body
  Client-->>App: Selected signing key or bounded error

Loading

_{Reviews (1) · Last reviewed commit: "fix: replace Asgard HTTPoison transport ..."}

[greptile-apps]

Vulnerable Req Version Pinned

The new ~> 0.5.0 constraint excludes the fixed Req 0.6.1 release, and the lock file resolves Req 0.5.18. Although the client sets decode_body: false, that does not disable this version's content-encoding decompression step. A malicious token or JWKS response with nested compression layers can therefore consume unbounded memory and take down the application. Upgrade to a fixed Req release or explicitly disable response decompression with the supported raw-response option.

How this was verified: Both reachable provider-response paths use Req 0.5.18 without raw mode, leaving its content-encoding decompression step active.

Knowledge Base Used: Asgard API client behavior