Shivam MishraandGitHub
94daf26ead
This PR updates two dependencies — `faraday` (2.14.1 → 2.14.2) and `jwt` (2.10.1 → 2.10.3) — to pick up security patches flagged by `bundle-audit`. Both are bumped to the minimal patched release within their existing major lines to keep the blast radius small. ### Faraday `Faraday::Connection#build_exclusive_url` still allowed a protocol-relative host override when the request target was passed as a `URI` object (rather than a `String`), bypassing the earlier fix for the string-based variant (CVE-2026-25765 / GHSA-33mh-2634-fwr2). On a fixed-base connection this could redirect a request to an attacker-controlled host while still forwarding connection-scoped headers such as `Authorization` — i.e. off-host request forgery (CVE-2026-33637 / GHSA-5rv5-xj5j-3484). The fix is a clean patch bump to `2.14.2`, within Faraday's existing version range — no API changes and no other gems affected. ### JWT `jwt` 2.10.1 accepts an empty/`nil` HMAC key during verification: `JWT.decode(token, "", true, algorithm: 'HS256')` (and keyfinder paths returning `""`/`nil`) verify a forged token, because the empty-key HMAC digest is treated as valid and `enforce_hmac_key_length` defaults to `false` (CVE-2026-45363, High). The advisory offers two fixes — `~> 2.10.3` or `>= 3.2.0`. We chose **2.10.3** deliberately: jumping to 3.x cascaded into upgrading `oauth2`, `twilio-ruby`, `googleauth`, `web-push`, and `signet` (all pinned `jwt < 3.0`), and `jwt` is used directly in 8+ places here (token services, OAuth callbacks, integration helpers), so a major bump carries real breakage risk for no extra security benefit. The Gemfile is pinned `'~> 2.10', '>= 2.10.3'` to hold the 2.x line. **Spec changes.** 2.10.3 tightens key handling: HMAC sign/verify now raises on a `nil`, empty, or non-`String` key instead of silently coercing it. A few specs relied on the old lax behaviour and needed updating: - `microsoft` / `google` callback specs built unsigned ID tokens via `JWT.encode(payload, false)`. Replaced with the correct unsigned form, `JWT.encode(payload, nil, 'none')`. - `instagram` / `linear` / `shopify` helper specs have a "client secret not configured" context where `client_secret` is `nil`. Their shared `valid_token` `let` signed with that `nil` secret, which Ruby evaluates before the helper runs — now raising. Since the helper short-circuits on the blank secret and never decodes the token, those contexts now override `valid_token` with a throwaway string. **Production is unaffected.** Every production HMAC path uses a real, non-empty key — `Rails.application.secret_key_base` (`BaseTokenService`, `Widget::TokenService`) or a client secret guarded by `return if client_secret.blank?` (Instagram/TikTok/Shopify/Linear helpers). The one `nil`-key call, `JWT.decode(id_token, nil, false)` in `OauthCallbackController`, runs with verification disabled, so the key is never inspected. Twilio voice tokens use `Twilio::JWT::AccessToken` from `twilio-ruby`, not this gem. The specs failed precisely because they exercised the unsafe empty-key pattern the patch now blocks — production never did.
83 lines
2.4 KiB
Ruby
83 lines
2.4 KiB
Ruby
require 'rails_helper'
|
|
|
|
RSpec.describe Linear::IntegrationHelper do
|
|
include described_class
|
|
|
|
describe '#generate_linear_token' do
|
|
let(:account_id) { 1 }
|
|
let(:client_secret) { 'test_secret' }
|
|
let(:current_time) { Time.current }
|
|
|
|
before do
|
|
allow(ENV).to receive(:fetch).with('LINEAR_CLIENT_SECRET', nil).and_return(client_secret)
|
|
allow(Time).to receive(:current).and_return(current_time)
|
|
end
|
|
|
|
it 'generates a valid JWT token with correct payload' do
|
|
token = generate_linear_token(account_id)
|
|
decoded_token = JWT.decode(token, client_secret, true, algorithm: 'HS256').first
|
|
|
|
expect(decoded_token['sub']).to eq(account_id)
|
|
expect(decoded_token['iat']).to eq(current_time.to_i)
|
|
end
|
|
|
|
context 'when client secret is not configured' do
|
|
let(:client_secret) { nil }
|
|
|
|
it 'returns nil' do
|
|
expect(generate_linear_token(account_id)).to be_nil
|
|
end
|
|
end
|
|
|
|
context 'when an error occurs' do
|
|
before do
|
|
allow(JWT).to receive(:encode).and_raise(StandardError.new('Test error'))
|
|
end
|
|
|
|
it 'logs the error and returns nil' do
|
|
expect(Rails.logger).to receive(:error).with('Failed to generate Linear token: Test error')
|
|
expect(generate_linear_token(account_id)).to be_nil
|
|
end
|
|
end
|
|
end
|
|
|
|
describe '#verify_linear_token' do
|
|
let(:account_id) { 1 }
|
|
let(:client_secret) { 'test_secret' }
|
|
let(:valid_token) do
|
|
JWT.encode({ sub: account_id, iat: Time.current.to_i }, client_secret, 'HS256')
|
|
end
|
|
|
|
before do
|
|
allow(ENV).to receive(:fetch).with('LINEAR_CLIENT_SECRET', nil).and_return(client_secret)
|
|
end
|
|
|
|
it 'successfully verifies and returns account_id from valid token' do
|
|
expect(verify_linear_token(valid_token)).to eq(account_id)
|
|
end
|
|
|
|
context 'when token is blank' do
|
|
it 'returns nil' do
|
|
expect(verify_linear_token('')).to be_nil
|
|
expect(verify_linear_token(nil)).to be_nil
|
|
end
|
|
end
|
|
|
|
context 'when client secret is not configured' do
|
|
let(:client_secret) { nil }
|
|
let(:valid_token) { 'any-token' }
|
|
|
|
it 'returns nil' do
|
|
expect(verify_linear_token(valid_token)).to be_nil
|
|
end
|
|
end
|
|
|
|
context 'when token is invalid' do
|
|
it 'logs the error and returns nil' do
|
|
expect(Rails.logger).to receive(:error).with(/Unexpected error verifying Linear token:/)
|
|
expect(verify_linear_token('invalid_token')).to be_nil
|
|
end
|
|
end
|
|
end
|
|
end
|