Bump golang.org/x/crypto from 0.24.0 to 0.45.0 in /openapi/go#5
Open
dependabot[bot] wants to merge 1 commit into
Open
Bump golang.org/x/crypto from 0.24.0 to 0.45.0 in /openapi/go#5dependabot[bot] wants to merge 1 commit into
dependabot[bot] wants to merge 1 commit into
Conversation
Bumps [golang.org/x/crypto](https://github.com/golang/crypto) from 0.24.0 to 0.45.0. - [Commits](golang/crypto@v0.24.0...v0.45.0) --- updated-dependencies: - dependency-name: golang.org/x/crypto dependency-version: 0.45.0 dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
added
dependencies
ehsan6sha
added a commit
that referenced
this pull request
May 19, 2026
Three security/correctness fixes for the issuer endpoints, closing the open audit items on functionland/fula-api#14. ## Finding #1 (CRITICAL) — Registration replay `POST /auth/register-mode-b` and `/auth/register-mode-c` previously accepted a CLIENT-generated challenge and verified only the Ed25519 signature over it. The challenge was never tracked as single-use, so anyone who captured a valid registration request body could replay it to mint fresh JWTs forever. Severity is amplified by the design choice that JWTs have no `exp` claim (DT-1): each replay produced a perpetually-valid token, killable only by rotating `JWT_SECRET`. Fix: extended the existing `POST /auth/challenge` endpoint to accept a `purpose` parameter (`'sign-in'` | `'register-mode-b'` | `'register-mode-c'`) defaulting to `'sign-in'` for back-compat. The two register endpoints now consume the challenge from the in-memory store the same way `/auth/sign-in` already does: `challengeStore.takeIfValid(uid, 'register-mode-{b,c}')` then `crypto.timingSafeEqual` against the submitted bytes. Replay of a captured body fails at the first step (challenge already consumed) and returns HTTP 401 `CHALLENGE_INVALID`. Sign-in callers still trigger USER_NOT_FOUND when the target uid is unknown; register callers skip that check because they're creating the user. ## Finding #4 (IMPORTANT) — `has_mode_a` was wrong The `register-mode-b` response had a `has_mode_a: boolean` field intended to surface "this OAuth identity already has a Mode A vault that the new Mode B sign-up is SEPARATE from". The previous logic counted `seed_users` rows with the same `oauth_sub` — which detects "another seed-based vault", NOT "a Mode A account". Mode A users live in `webui_users` keyed by `SHA-256(lowercase(email))`, never in `seed_users`. Fix: replaced `checkModeAExistsForOauthSub(oauthSub)` with `checkModeAExistsForEmail(email)` that does a direct PK lookup on `webui_users` using `emailToUserId(verifiedOauthEmail)`. Captures the OAuth-verified email alongside the sub in the existing Google / Apple verification block. Apple's relay-email behavior on subsequent sign-ins (no email returned after first sign-in) is an acceptable false-negative — `has_mode_a = false` is the safe default. The FxFiles client wires the result into a "Existing vault detected" warning dialog on the Mode B sign-up success path so the user knows their new Maximum-security vault is independent of their existing Standard-security one (Gemini advisor 2026-05-18). ## Finding #5 (IMPORTANT) — `encrypted_email = NULL` audit Mode B / Mode C `webui_users` rows used to be inserted with `encrypted_email = NULL`. Codex flagged this as a downstream risk: any future code that reads the column without null-guards could misattribute or crash for these users. A grep across the codebase found only INSERT sites for the column today, but the surface area is non-trivial (admin tools, future SELECT joins, possible backup / audit scripts). Fix per maintainer's direction: store the AES-256-GCM-encrypted `effective_user_id_hex` in the column instead of NULL. "Email is essentially user-id all over the system" — treating the canonical seed-user-id as the email gives downstream code a non-null opaque value to work with. The actual OAuth email of a Mode B user is NOT persisted (the OAuth binding still lives only in `seed_users.oauth_sub`), so this change does NOT introduce new PII exposure. ## Tests `tests/seedAuth.test.ts`: - AUDIT-1 replay: register a uid via the new server-issued-challenge flow, replay the captured body, expect 401 CHALLENGE_INVALID. - AUDIT-5 encrypted_email non-null: register Mode C, query `webui_users.encrypted_email`, assert non-null and non-empty. Existing 15 tests updated to use the new `obtainRegisterChallenge` helper (call `/auth/challenge` with the appropriate purpose before registering) — they previously passed client-generated nonces and would now fail with `CHALLENGE_INVALID`. Total: 17 vitest cases. Tests skip on machines without PostgreSQL — same pattern as the existing `api.test.ts`. Run via `npm test` against a populated DB. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Bumps golang.org/x/crypto from 0.24.0 to 0.45.0.
Commits
4e0068cgo.mod: update golang.org/x dependenciese79546essh: curb GSSAPI DoS risk by limiting number of specified OIDsf91f7a7ssh/agent: prevent panic on malformed constraint2df4153acme/autocert: let automatic renewal work with short lifetime certsbcf6a84acme: pass context to requestb4f2b62ssh: fix error message on unsupported cipher79ec3a5ssh: allow to bind to a hostname in remote forwarding122a78fgo.mod: update golang.org/x dependenciesc0531f9all: eliminate vet diagnostics0997000all: fix some commentsYou can trigger a rebase of this PR by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot mergewill merge this PR after your CI passes on it@dependabot squash and mergewill squash and merge this PR after your CI passes on it@dependabot cancel mergewill cancel a previously requested merge and block automerging@dependabot reopenwill reopen this PR if it is closed@dependabot closewill close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)You can disable automated security fix PRs for this repo from the Security Alerts page.