chore: merge from main to rc (resolve conflicts, prefer main) - #194
Merged
Conversation
* deps: resolve non-breaking Dependabot alerts (category 1) Apply safe, in-major security fixes across all three lockfiles via npm overrides pinned to GHSA-patched versions plus range-respecting updates (no major-version bumps). Resolves 125 of 160 open Dependabot alerts. Root package.json overrides: @xmldom/xmldom, cipher-base, fast-uri, flatted, follow-redirects, form-data, koa, launch-editor, lodash, morgan, node-forge, on-headers, pbkdf2, postcss, protobufjs, qs, serialize-javascript, sha.js, shell-quote, tmp, undici, ws. Also bump webpack devDependency to ^5.104.1 and range-update ajv, bn.js, glob, tar-fs, picomatch, minimatch, brace-expansion, nanoid, playwright. src.gen streaming clients: npm audit fix (lodash, minimatch, @smithy/config-resolver) and override fast-xml-parser to 4.5.7. Remaining alerts require major-version bumps or coordinated @aws-sdk upgrades and are handled separately. * deps: revert webpack bump to keep web build passing Problem: The webpack ^5.95.0 -> ^5.104.1 bump (added to fix SSRF alerts #68/#69) pulls webpack 5.108.4 and enhanced-resolve 5.24.2. The newer resolver applies stricter exports-field resolution and can no longer resolve the aws-core-vscode/shared subpath from compiled packages/core/dist in the web bundle, breaking the webBase build. Only the web jobs (package VSIX, test Web) fail; all Node-based jobs pass. Solution: Revert webpack to ^5.95.0, restoring enhanced-resolve 5.17.1 to match main. Dependabot #68/#69 are build-time SSRF in webpack's HttpUriPlugin/buildHttp experimental feature, which this repo does not use, so real-world risk is negligible. They are intentionally left open and will be fixed thoroughly in a follow-up PR together with the core exports / webpack resolve compatibility work.
Resolve the security alerts that require major-version bumps or coordinated transitive upgrades, on top of the safe (category 1) fixes. Brings total resolved to 152 of 160 open Dependabot alerts. Direct bumps: - markdown-it 13 -> ^14.2.0 (+ @types/markdown-it ^14.1.2) [core] - esbuild-loader 2.20.0 -> 4.5.0 [core] (ESBuildMinifyPlugin -> EsbuildPlugin in webpack.base.config.js; pulls esbuild 0.25+) - webpack-dev-server ^4.15.2 -> ^5.2.5 (devServer config uses only options still valid in v5) Overrides / range updates (root): - fast-xml-parser -> 5.7.0 (GHSA-gh4j has no 4.x backport; forces the AWS SDK's XML parser to 5.x - see risk note) - markdown-it 14.2.0, linkify-it 5.0.1, jsonata 2.2.1 - js-yaml@4 -> 4.2.0 (scoped so js-yaml 3.x consumers are untouched) - @smithy/config-resolver, @opentelemetry/core updated to patched lines src.gen streaming clients: - fast-xml-parser override 4.5.7 -> 5.7.0 Note: keeps webpack at ^5.95.0 (see PR #136) so the web build stays green; webpack #68/#69 remain deferred and are addressed separately in this PR. Risk to validate in CI: forcing fast-xml-parser 5.x onto the AWS SDK may affect XML-based SDK responses (S3/EC2/CloudFormation).
* fix: resolve CodeQL code-scanning security alerts
Problem:
17 open CodeQL code-scanning alerts across source, tests, dev scripts,
and a workflow (ReDoS, incomplete sanitization, shell-command injection
from environment, and a missing workflow permissions block).
Solution:
- ReDoS (js/polynomial-redos): rewrite vulnerable regexes as linear
equivalents - indent()/block-comment/base64url padding in
textUtilities.ts; use-strict/require detection in importAdderUtil.ts;
trailing '/' and '#' stripping in auth.ts and authUtil.ts (behavior
verified against existing unit tests).
- Shell injection (js/shell-command-injection-from-environment): replace
execSync(string) with execFileSync('git', [...args]) (no shell) in
scripts/createRelease.ts and scripts/newChange.ts.
- Incomplete sanitization (js/incomplete-sanitization): replace all
quotes, not just the first, in ssh.test.ts.
- URL substring checks (js/incomplete-url-substring-sanitization): use
assert.match instead of includes() on URLs in
referenceLogViewProvider.test.ts.
- Workflow permissions (actions/missing-workflow-permissions): add a
least-privilege top-level 'contents: read' to release.yml (the publish
job keeps its explicit 'contents: write').
- Certificate validation (js/disabling-certificate-validation): this is
an explicit user opt-in mirroring VS Code's 'http.proxyStrictSSL';
kept the behavior, upgraded the log to a warning, and documented it.
None of these overlap with the dependency PRs (#136-138).
* fix: match quoted use-strict directive after ReDoS hardening
The anchored /^\s*use\s+strict/ regex missed quoted directives like
'use strict'; (line starts with a quote), breaking
importAdderUtil 'first line after comments and use strict'. Allow an
optional leading quote: /^\s*['"]?use\s+strict/ (still anchored/linear).
* fix: strip all block comments in stripNewLinesAndComments
Add the global flag to the ReDoS-hardened block-comment regex so lines
with multiple block comments are fully stripped (and code between them is
preserved), matching the function's documented intent. Addresses review
feedback on #140; the g flag keeps the regex linear (no ReDoS).
Problem: Bumping webpack to the patched ^5.104.1 (fixes GHSA build-time SSRF alerts #68/#69) pulls enhanced-resolve 5.24.x, whose stricter exports resolution breaks the web bundle (aws-core-vscode/shared no longer resolves from packages/core/dist), failing package VSIX and test Web. Solution: Bump webpack to ^5.104.1 and override enhanced-resolve to 5.17.1 (the version main uses and known to resolve core's exports). npm overrides bypass webpack's declared enhanced-resolve range, so the SSRF fix lands while the lenient, working resolver is retained. Brings total resolved to 154 of 160 Dependabot alerts. Remaining 6 alerts are unpatched upstream (aws-sdk v2, elliptic), require major upstream package upgrades (@opentelemetry/core via @aws/language-server-runtimes, @smithy/config-resolver via old @aws-sdk clients), or are stale/false-positive (@protobufjs/utf8).
Resolve 10 Dependabot alerts that re-surfaced after their advisories were expanded to new version lines (or newly published) since the prior security PRs merged. All verified against the current advisory ranges. - koa 2.16.2 -> 2.16.4 (#99, #246) - @tootallnate/once -> 2.0.1 (#214) - brace-expansion (1.x) -> 1.1.13 (#170, #20) - yaml -> 1.10.3 (#157) - immutable -> 4.3.8 (#131) - minimatch (5.x) -> 5.1.8 (#106) - diff (4.x -> 4.0.4, 5.x -> 5.2.2) (#55) - glob (10.x) -> 10.5.0 (#36) Uses version-scoped overrides (pkg@major) so other coexisting major lines are untouched. Root lockfile only; verified idempotent. Deferred: uuid #217/#219/#220 require a major 9->11 bump. uuid is a direct dependency of the generated src.gen clients, so npm ignores an override, and npm won't dedupe the hoisted 9.0.1 shared across older @aws-sdk clients. That needs a dedicated effort (generated client + @types/uuid updates) and is left for a follow-up.
Override websocket-driver to 0.7.5 (GHSA-xv26-6w52-cph6: message corruption via abuse of protocol length headers, vulnerable < 0.7.5). Transitive dev-only dependency via sockjs/faye-websocket. Single version override; root lockfile only; verified idempotent.
Problem: adm-zip ^0.5.10 (in packages/core) has an open high-severity Dependabot advisory (alerts #249, #250). The root build scripts (scripts/lspArtifact.ts) import adm-zip but only relied on it being hoisted from packages/core. Solution: - Bump adm-zip to ^0.6.0 in packages/core. - Declare adm-zip ^0.6.0 (+ @types/adm-zip) in the root package.json, since the root build scripts import it directly — this keeps it resolvable at the root regardless of workspace hoisting (fixes "Cannot find module 'adm-zip'" during packaging). - Regenerate the lockfile. Other open alerts (uuid, @opentelemetry/core, @smithy/config-resolver — multiple coexisting versions; aws-sdk, elliptic — no patch) are deferred for scoped human review.
…153) * test: bump @vscode/test-electron to ^2.5.2 to fix macOS insiders CI The 'test macOS (18.x, insiders)' job fails repo-wide (incl. on main) with 'spawn .../Contents/MacOS/Electron ENOENT': the pinned @vscode/test-electron 2.3.8 (2023) can't locate the executable in the current VS Code Insiders macOS build. Bump to the latest Node-18-safe line (2.5.2). Note: the newest @vscode/test-electron (3.0.0) would be the most complete fix but requires Node >=22 (CI runs Node 18) and restructures the internal out/runTest import, so it is out of scope here. If 2.5.2 does not fully resolve the insiders job, the follow-up is a coordinated Node 22 + test-electron 3.0.0 upgrade. * test: bump @vscode/test-electron to ^3.1.0 to fix macOS insiders CI The 'test macOS (18.x, insiders)' job fails repo-wide with 'spawn .../Visual Studio Code - Insiders.app/Contents/MacOS/Electron ENOENT': @vscode/test-electron 2.x resolves an executable path that current VS Code Insiders macOS builds no longer use. Fixed in test-electron 3.x. - Bump ^2.5.2 -> ^3.1.0 (matches upstream aws-toolkit-vscode) - Import TestOptions/runTests from the package root; drop the internal '@vscode/test-electron/out/runTest' path No CI Node bump needed: .npmrc sets engine-strict=false, so 3.x (engines: node>=22) installs on the Node 18 runners, matching upstream.
…stomers When RTS rejects an identity with AccessDeniedException and reason=FEATURE_NOT_SUPPORTED, Amazon Q Developer is no longer accepting that customer. Previously this surfaced as the generic "Failed to list Q Developer profiles for regions: ..." error, which offers Retry and Sign out actions -- both useless for a permanent, deliberate rejection, and misleading because it reads as a transient outage. RegionProfileManager now classifies this case and throws a ToolkitError with code QDeveloperNotAcceptingNewCustomers carrying the real service message. The login webview renders a dedicated state showing that message with a single "Go back" action instead of Retry/Sign out. Classification requires all three of: isAwsError (a real AWS service error carrying code and time, not merely an object with a `reason` field), name === 'AccessDeniedException', and reason exactly equal to 'FEATURE_NOT_SUPPORTED'. This deliberately avoids capturing the other modeled AccessDeniedExceptionReason values -- UNAUTHORIZED_CUSTOMIZATION_RESOURCE_ACCESS, UNAUTHORIZED_WORKSPACE_CONTEXT_FEATURE_ACCESS and TEMPORARILY_SUSPENDED -- the last of which is transient and must keep its retry affordance. Since the rejection is per-identity rather than per-region, the first matching region wins and is preferred over the generic failure regardless of which region's call settles first. listRegionProfiles returns RegionProfile[] | string, so the specific case is tagged for the frontend by prefixing the message with the notAcceptingNewCustomersPrefix sentinel, which the Vue component strips before display. That constant lives in types.ts rather than backend.ts because backend.ts imports vscode and Auth; importing a runtime value (not just a type) from it into a webview file bundles Node-only dependencies into the webview bundle and blanks the view at load. Adds signOutIfConnected() to CommonAuthWebview, backing the "Go back" action. Unlike signout() it must never throw, because by the time the user dismisses the error the connection may already have been cleared by a connection-modified listener reacting to the auth failure; the action's job is to return to a neutral login screen, not to assert a connection existed. Tests cover the positive case plus three negative cases that pin the fallback to ListQDeveloperProfilesFailed: an unrelated AccessDeniedException reason (TEMPORARILY_SUSPENDED), a non-AccessDeniedException error coincidentally carrying reason=FEATURE_NOT_SUPPORTED, and a generic transient failure.
* deps: fix protobufjs DoS advisory (#251) Bump the protobufjs override 7.6.3 -> 7.6.5 (GHSA-j3f2-48v5-ccww: DoS via infinite loop in .proto option parsing; vulnerable 7.5.0-7.6.4). Transitive runtime dependency; single version in the tree; root lockfile only; verified idempotent. * deps: fix newly-expanded advisories (#252-258) Bump existing overrides to the versions required by advisories that were expanded/updated on 2026-07-21, re-flagging our pinned versions: - brace-expansion (1.x) 1.1.13 -> 1.1.16 (#252) - js-yaml (4.x) 4.2.0 -> 4.3.0 (#253) - shell-quote 1.8.4 -> 1.9.0 (#254) - immutable 4.3.8 -> 4.3.9 (#255, #256) - fast-uri 3.1.2 -> 3.1.3 (#257) - linkify-it 5.0.1 -> 5.0.2 (#258) All verified resolved against the current advisory ranges; root lockfile only; verified idempotent. * deps: bump fast-uri to 3.1.4
Replaces the detection half of this change. The UI is unchanged.
The original approach classified the block from ListAvailableProfiles, which cannot
work for the population being blocked:
- RTS gates on the User-Agent of the shared language server
(AWS-Language-Servers-AWS-CodeWhisperer). The extension's own SDK calls carry a
different UA and are allowed unconditionally, so the extension is never told "no".
Verified against prod: with a blocked Builder ID the extension's own
ListFeatureEvaluations succeeds while the language server's identical call is denied.
- Profiles are an IdC concept. restoreProfileSelection() only runs behind
isValidEnterpriseSsoInUse(), so a Builder ID user never reaches that path -- and IdC
identities are exempt from the gate, so the one type that does reach it is never
denied.
- For Builder ID, ListAvailableProfiles returns a different error ("AWS Builder ID is
not supported for this operation", reason undefined) which is identical for healthy
and blocked identities, so it cannot be used as a signal either.
The language server is therefore the only component that observes the rejection. It now
reports it over the existing Notification feature, and this change reacts to that:
- qDevAccessBlockedHandler listens for aws/window/showNotification, persists the
service's message, and signs the user out.
- The blocked state is persisted so the message survives the sign-out that follows.
- showLoginView and refreshAuthState route a blocked identity to the existing blocked
screen; listRegionProfiles short-circuits to the stored message rather than calling an
API that cannot succeed.
- Go back clears the state and fires onActiveConnectionModified so the webview returns
to sign-in. Firing is required, not incidental: reacting to the block already signed
the user out, so signout() -- which would normally trigger the re-render -- is
skipped, and without this the screen never changes.
- URLs in the message render as links. The message is the service's copy and contains
the action the user must take, which is useless as inert text. Split into segments
rather than v-html so a service response can never inject markup.
Requires a language server carrying the server-side reporting (aws/language-servers
#2794, #2796, #2797). Older servers send nothing and this code stays dormant.
Tested end to end in VS Code against prod RTS with a blocked Builder ID: sign-in
succeeds, the block is reported seconds later, the user is signed out, the message
renders with a working kiro.dev link, and Go back returns to sign-in. Also verified a
healthy identity is unaffected.
Review follow-up. The id check could never match and the title check was doing all the
work, which meant any future error notification titled "Amazon Q Developer" would have
signed a working user out.
The runtime does not forward the server's id verbatim: RouterByServerName replaces it
with base64 of {"serverName":...,"id":...} so followups can be routed back to the
originating server. So `params.id === 'qDevPluginAccessBlocked'` never matched, and the
title fallback was the only live path.
Decode the envelope and match on the inner id, falling back to the raw value so a server
sending a plain id still works. Title matching is removed entirely rather than kept as a
fallback: every server able to deliver a notification at all sends the id, so there is
nothing to fall back for, and the cost of a false positive here is signing out a user
who is not blocked.
Adds the tests this file should have had. One asserts an unrelated error notification
sharing the title is ignored, which is the regression that motivated the change; the
others cover the routed id, a plain id, a missing id, an empty message, idempotency on
repeated reports, and that the handler never throws when sign-out fails. 7 passing.
Routing a blocked identity to PENDING_PROFILE_SELECTION returned early without setting
loadMetadata, which the existing pendingProfileSelection branch does. When the webview
then reported readiness it broke:
webviewId="aws.amazonq.AmazonCommonAuth": Error: Webview error
-> Error: Webview backend command failed: "setUiReady()"
-> TypeError: Cannot read properties of undefined (reading 'start')
setDidLoad dereferences loadMetadata!.start non-optionally, so entering that stage
without it throws inside the webview. The failure lands on exactly the users this feature
exists to help: they would see a broken login view instead of the explanation.
Both callers now go through enterProfileSelection() rather than duplicating the setup, so
a future third caller cannot miss it. The comment records why the metadata is required
rather than leaving it as unexplained bookkeeping.
Added a regression test asserting setUiReady does not throw after routing to the blocked
screen. Verified it bites: reintroducing the early return fails it (8 passing/1 failing
vs 9 passing).
Replaces the single-message screen with the layout Saurabh proposed, which explains why access is blocked and what to do about it instead of only relaying the service's sentence. - Heading and subheading stating that sign-ups have stopped, with the date - Three cards: why this is happening (with a link to the announcement), what to use instead (Kiro), and that pre-cutoff Builder IDs can still sign in - Primary action opens kiro.dev, secondary returns to sign-in, footer links to the announcement The service message is no longer displayed. It is still stored, because its presence is what marks the identity as blocked, but the screen now carries its own copy. Worth knowing for review: that copy hardcodes two dates, so if the service changes its cutoff the screen will not follow. The dates are Saurabh's, taken from the public announcement. The container widens for this screen only, rather than changing the 260px cap the profile picker relies on. Colours come from VS Code theme variables so the screen follows light and dark themes; only the accent hues and the primary button gradient are fixed, since those carry meaning rather than chrome. Icons are inline SVG rather than an icon font, to avoid adding a webview dependency. Removes the URL-splitting computed, which existed only to linkify the service message.
…ainer The container is capped at 260px and absolutely positioned for the profile picker. The blocked screen is wider, and a wider child cannot centre inside it: with negative available space the auto margins resolve to 0, so the content started at the container's left edge and overflowed to the right while the Q icon above stayed centred in the 260px box. The whole screen read as misaligned. The container itself now widens for this state rather than the child overflowing it, so the icon, heading, cards and buttons share one centre axis. Static positioning also drops the fixed top offset, which only made sense for the short picker and left a large gap above this taller screen.
The repo moved from the aws org to Amazon-Q-Developer (https://t.corp.amazon.com/P484890134). - CODEOWNERS: the @aws/* teams do not exist in the new org, so every entry was an "Unknown owner" and code-owner review could not be satisfied. Collapse to @Amazon-Q-Developer/sync-team-dae-production-eng-team (the synced eng team), matching what was done for language-servers. Granular per-directory teams have no equivalent in the new org yet. - node.js.yml / notification.yml: `github.repository == 'aws/amazon-q-vscode'` guards now evaluate false, silently skipping the Codecov upload and PR notification jobs. Repoint to Amazon-Q-Developer/amazon-q-vscode.
…rs-workflows fix: repoint CODEOWNERS and workflow org guards to Amazon-Q-Developer
…-customers feat: distinct sign-in error when Amazon Q Developer access is blocked
* Update third-party license attribution for release/rc-20260819 * Release 2.5.0 * Update version to snapshot version: 2.6.0-SNAPSHOT --------- Co-authored-by: aws-toolkit-automation <>
Two defects compound into the black login view with "Error: Webview error" that customers hit on IdC sign-in in 2.5.0. Diagnosed from the extension log of a live repro: the logged failure is `Webview backend command failed: "setUiReady()" -> TypeError: Cannot read properties of undefined (reading 'start')`. 1. The login Vue bundle ships wrapped in a CommonJS helper. esbuild-loader 4.5.0 (from the 2.5.0 dependency remediation) infers `format: 'iife'` when the compile target is 'web' and the minifier target is not 'esnext', wrapping the whole bundle in a lazy CJS factory and rewriting top-level `this`, which also breaks `output.libraryTarget: 'this'`. Of the four Vue bundles in the shipped 2.5.0 VSIX, login/webview/vue/amazonq/index.js is the ONLY one wrapped -- feedback, codewhisperer and securityIssue shipped clean. Pinning the minimizer to target 'esnext' keeps esbuild as a pure minifier; the loader has already transpiled to es2021 and these bundles only run in the IDE's Chromium webview. This exact upgrade was reverted once before for the same breakage (91a54b0, "broke loading mynah-ui"). 2. setDidLoad dereferences `loadMetadata!.start`. The webview's 10-second load timeout clears loadMetadata on the assumption the load failed, so a page that reports readiness late -- 44 seconds after activation in the captured log -- crashes the setUiReady command instead of recording a slow-but-successful load, and VS Code surfaces that as the webview error banner. Emit without a duration and return instead. The rebuilt login bundle is verified free of the CJS wrapper.
Conflicts in package.json, package-lock.json, and CHANGELOG.md resolved by keeping main's version (2.6.0-SNAPSHOT) and changelog state, since main's changes take precedence over the release branch in this merge.
hezelin-work
approved these changes
Aug 27, 2026
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
4 participants
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.
Problem
PR #193 (merge
mainintorelease/rc-20260821) has merge conflicts in:package-lock.jsonpackages/amazonq/CHANGELOG.mdpackages/amazonq/package.jsonSolution
Resolved all conflicts by preferring
main's changes over thercbranch:main's version (2.6.0-SNAPSHOT) inpackage.jsonandpackage-lock.jsoninstead of the RC branch's2.7.0-SNAPSHOTbump.main'sCHANGELOG.mdstate, dropping the RC-only2.6.0 2026-08-21entry.packages/amazonq/.changes/2.6.0.jsonadded by the RC branch's own release tooling, to stay consistent withmain's state.No conflict markers remain and both JSON files were validated to parse correctly.
feature/xbranches will not be squash-merged at release time.