Hello Sylvain, On 10/3/26 06:46, Sylvain Beucler wrote:
Hello Simon,On 02/10/2026 19:41, Simon Quigley wrote:I claimed ruby-oauth2 in dla-needed.txt. Bookworm has 1.4.4-1, which still sends a bearer token to the host named by a redirect Location. That is CVE-2026-54603 (GHSA-pp92-crg2-gfv9). Unstable is fixed in 2.0.25-1 (upstream 2.0.22, commit 0f0a474). Trixie is a different upstream, 2.0.9, and that fix is a point release rather than this backport. The debdiff against 1.4.4-1 is attached. 1.4.4's Client#request hands the Location string to Faraday 1.1, and that turns a protocol-relative Location (//other-host/...) into a new host while keeping Authorization. The patch resolves that form as a same-origin path, and drops Authorization when the redirect changes scheme, host, or port. A same-origin redirect is unchanged. The spec examples from 0f0a474 are in the patch. One stub is a regexp, because Faraday 1.1 collapses a triple-slash path when the stub is registered and then looks the request up uncollapsed. I ran a local script against the archive package and against this build, on Bookworm's Ruby 3.1 and Faraday 1.1. The archive package sends the token to the host in Location, both for the protocol-relative redirect and for an absolute cross-origin one. This package keeps the protocol- relative request on the original host, removes the token from the absolute redirect, and a normal AccessToken#get and client.request still return the body I expected. The upstream rspec suite is still disabled, same as 1.4.4-1. spec/ helper.rb needs silent-stream, which Bookworm does not ship, so autopkgtest's gem2deb-test-runner skips with no test suite. I ran the redirect examples from the patched spec: 10 examples, 0 failures. The rest of the suite passes aside from the OAUTH_DEBUG example, which calls a helper from that missing gem. Bookworm has two packages that depend on ruby-oauth2: ruby-asana and ruby-omniauth-oauth2. The OmniAuth providers in Bookworm (GitHub, GitLab, WordPress, AliCloud, Azure AD, Authentiq, Atlassian, and DingTalk) depend on ruby-omniauth-oauth2, and they get a token through that strategy. Asana's ordinary API calls follow redirects in Faraday, not in OAuth2::Client. The token exchange does go through Client#request, and so does OmniAuth's auth_code.get_token. DingTalk also subclasses OAuth2::Client and calls request() itself. I tested those reverse dependencies against 1.4.4-1+deb12u1. Asana's authorize URL is still on app.asana.com, a same-origin token redirect still comes back with a token, and a protocol-relative token redirect stays on app.asana.com. A client built the way the GitHub strategy builds one does the same. DingTalk's subclass keeps the request, and its Authorization header, on oapi.dingtalk.com. A basic_auth token request, which none of these packages turn on, still follows an absolute cross- origin redirect and drops Authorization. On 1.4.4-1 the protocol- relative calls left the provider, and that basic_auth header went with them. Same-origin redirects and the authorize URLs behaved the same on both packages. I built this in a Bookworm LXD container. You can find a Debusine work request here: https://debusine.debian.net/debian/developers/work- request/1408442/ Feedback is welcome. If nothing showstopping is raised, I plan on uploading this to bookworm-security and issuing the DLA on Monday afternoon (October 5th, 2026).This looks very good.
Thank you!
In the LTS Team, we'd wait until the trixie SPU is approved (https://bugs.debian.org/1149723 , even if not published yet), but since you maintain the package, you can go ahead if you want.
I will admit, this is my first ever SPU, so I'm unsure what the timeline or process looks like first-hand. Thanks for the advice. If I ever decide to work on a DLA outside of packages I maintain, I'll keep this in mind. (This might happen in the next few weeks, so pointers on that are also appreciated.)
Please also tag debian/1.4.4-1+deb12u1 (gbp tag) at https://salsa.debian.org/ruby-team/ruby-oauth2/ on upload :)
Will do! ruby-oj was also tagged and pushed as well. Best regards, Simon Quigley [email protected]
OpenPGP_signature.asc
Description: OpenPGP digital signature
