build: merge release candidate version rc-20260819 - #174
Merged
Conversation
chungjac
changed the title
laileni-aws
changed the title
Collaborator
|
Reopening to re-trigger CI after fixing PR title format. |
chungjac
approved these changes
Aug 21, 2026
laileni-aws
approved these changes
Aug 21, 2026
laileni-aws
pushed a commit
to laileni-aws/amazon-q-vscode
that referenced
this pull request
Aug 21, 2026
…r#174) * 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 <>
laileni-aws
pushed a commit
to laileni-aws/amazon-q-vscode
that referenced
this pull request
Aug 21, 2026
…r#174) * 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 <>
laileni-aws
pushed a commit
that referenced
this pull request
Aug 21, 2026
* 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 <>
ashishrp-aws
added a commit
that referenced
this pull request
Aug 27, 2026
* deps: resolve 123 Dependabot security alerts (safe, non-breaking) (#136) * 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. * deps: resolve major-version Dependabot alerts (category 2) (#137) 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 (#140) * 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). * deps: fix webpack SSRF alerts (#68, #69) via resolver pin (#138) 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). * deps: resolve newly-expanded Dependabot advisories (#143) 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. * deps: fix critical websocket-driver advisory (#247) (#145) 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. * deps: bump adm-zip to 0.6.0 to patch high-severity advisory (#147) 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. * test: bump @vscode/test-electron to ^3.1.0 to fix macOS insiders CI (#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. * feat: distinct sign-in error when Q Developer is not accepting new customers 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 + newly-expanded advisories (#251-259) (#150) * 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 * feat: detect Q Developer access blocks via the language server 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. * fix: identify the access-blocked notification by id, not by title 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. * fix: initialise load metadata when routing to the blocked screen 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). * feat: redesign the access-blocked screen 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. * fix: centre the access-blocked screen instead of overflowing its container 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. * fix: repoint CODEOWNERS and workflow org guards to Amazon-Q-Developer 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. * build: merge release candidate version rc-20260819 (#174) * 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 <> * fix: unbreak the login webview shipped in 2.5.0 (#179) 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. --------- Co-authored-by: Laxman Reddy <141967714+laileni-aws@users.noreply.github.com> Co-authored-by: Jacob Chung <chungjac@amazon.com>
ashishrp-aws
added a commit
that referenced
this pull request
Aug 27, 2026
* deps: resolve 123 Dependabot security alerts (safe, non-breaking) (#136) * 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. * deps: resolve major-version Dependabot alerts (category 2) (#137) 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 (#140) * 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). * deps: fix webpack SSRF alerts (#68, #69) via resolver pin (#138) 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). * deps: resolve newly-expanded Dependabot advisories (#143) 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. * deps: fix critical websocket-driver advisory (#247) (#145) 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. * deps: bump adm-zip to 0.6.0 to patch high-severity advisory (#147) 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. * test: bump @vscode/test-electron to ^3.1.0 to fix macOS insiders CI (#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. * feat: distinct sign-in error when Q Developer is not accepting new customers 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 + newly-expanded advisories (#251-259) (#150) * 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 * feat: detect Q Developer access blocks via the language server 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. * fix: identify the access-blocked notification by id, not by title 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. * fix: initialise load metadata when routing to the blocked screen 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). * feat: redesign the access-blocked screen 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. * fix: centre the access-blocked screen instead of overflowing its container 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. * fix: repoint CODEOWNERS and workflow org guards to Amazon-Q-Developer 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. * build: merge release candidate version rc-20260819 (#174) * 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 <> * fix: unbreak the login webview shipped in 2.5.0 (#179) 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. --------- Co-authored-by: Laxman Reddy <141967714+laileni-aws@users.noreply.github.com> Co-authored-by: Jacob Chung <chungjac@amazon.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
3 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
Solution
feature/xbranches will not be squash-merged at release time.