Repository navigation
fix(a2a-server): never derive workspace trust from request agentSettings in createTask - #29525
venkatchalla06 wants to merge 1 commit into
Conversation
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request hardens the security model of the a2a-server by ensuring that workspace trust cannot be derived from user-provided request settings. By normalizing input in the createTask method, it aligns the trust-checking logic with other entry points, preventing potential unauthorized command execution via workspace-declared tools or environment variables. Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize the Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. Footnotes
|
|
📊 PR Size: size/S
|
|
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
There was a problem hiding this comment.
Code Review
This pull request hardens the task creation process in CoderAgentExecutor.createTask by validating the workspace path and forcing isTrusted to false, preventing tasks from bypassing trust checks. The review feedback points out that any error thrown during workspace path validation is not caught, which could lead to unhandled rejections; it suggests wrapping the validation in a try-catch block to properly report the failure to the event bus.
| const agentSettings: AgentSettings = { | ||
| ...rawAgentSettings, | ||
| workspacePath: validateWorkspacePath(rawAgentSettings.workspacePath), | ||
| isTrusted: false, | ||
| }; |
There was a problem hiding this comment.
When validating the workspace path in createTask, any error thrown by validateWorkspacePath (such as ENOENT from resolveToRealPath) is not caught. This can lead to unhandled rejections and prevents the failure from being reported to the eventBus. Wrapping this in a try-catch block and calling pushTaskStateFailed ensures consistent error handling and reporting, matching the behavior in reconstruct() and execute().
let agentSettings: AgentSettings;
try {
agentSettings = {
...rawAgentSettings,
workspacePath: validateWorkspacePath(rawAgentSettings.workspacePath),
isTrusted: false,
};
} catch (error) {
logger.error(
"[CoderAgentExecutor] Invalid workspace path during task creation for task " + taskId + ":",
error,
);
if (eventBus) {
void pushTaskStateFailed(error, eventBus, taskId, contextId);
}
throw error;
}References
- Ensure consistent path resolution by using a single, robust function (e.g.,
resolveToRealPath) for all related path validations, including internal validations in components likeWorkspaceContext.
929c9fc to
15d455e
Compare
…ngs in createTask createTask() forwarded the caller-supplied agentSettings straight into runInIsolatedEnv(), where setIsTrusted() honors agentSettings.isTrusted. Every other entry point that builds a task from external input — execute() and reconstruct() — already normalizes agentSettings to isTrusted:false and runs the workspacePath through validateWorkspacePath(). createTask() was the one that did not, so a task created via the POST /tasks handler (which passes req.body .agentSettings unchanged) could set isTrusted:true and mark its workspace trusted. That re-enables workspace-declared mcpServers/tools and workspace .env loading (GEMINI_YOLO_MODE), i.e. command execution — the exact class google-gemini#28470 closed for the other paths. Normalize createTask's input the same way (force isTrusted:false, validate the workspace path). The workspace-path validation is wrapped in try/catch that logs and reports the failure via pushTaskStateFailed before re-throwing, matching the error handling in reconstruct() and execute() so a bad path cannot become an unhandled rejection. The only internal caller (execute()) already passes normalized settings, so this is a no-op there and simply removes request-controlled trust from the createTask path.
15d455e to
e92bba9
Compare
|
Hi there! Thank you for your interest in contributing to Gemini CLI. To ensure we maintain high code quality and focus on our prioritized roadmap, we only guarantee review and consideration of pull requests for issues that are explicitly labeled as 'help wanted'. This PR will be closed in 7 days if it remains without that designation. We encourage you to find and contribute to existing 'help wanted' issues in our backlog! Thank you for your understanding. |
What
CoderAgentExecutor.createTask()forwarded the caller-suppliedagentSettingsdirectly intorunInIsolatedEnv(), wheresetIsTrusted(agentSettings, …)honorsagentSettings.isTrusted. The other two entry points that build a task from external input already normalize their settings first:execute()→{ ...raw, workspacePath: validateWorkspacePath(...), isTrusted: false }reconstruct()→ same shape,isTrusted: falsecreateTask()did neither, so a task created through thePOST /taskshandler (http/app.ts, which passesreq.body.agentSettingsunchanged) could setisTrusted: trueand mark its workspace trusted. A trusted workspace re-enables workspace-declaredmcpServers/toolsand workspace.envloading (GEMINI_YOLO_MODE), which is command execution during task init — the same class theb-519269096/ #28470 hardening closed forexecute()/reconstruct().Fix
Normalize
createTask()'s input the same way as the sibling methods: forceisTrusted: falseand routeworkspacePaththroughvalidateWorkspacePath(). The only internal caller (execute()) already passes normalized settings, so this is a no-op there; it just removes request-controlled trust from thecreateTaskpath.Scope / severity note
The a2a-server binds to
localhost(http/app.ts:expressApp.listen(port, 'localhost', …)), so this is not a remote-network issue. It is a defense-in-depth / trust-model consistency fix: request-supplied settings should never be able to elevate workspace trust, matching the invariantexecute()/reconstruct()already enforce.Suggested regression test
Assert that a
createTaskcall carryingisTrusted: truestill yields an untrusted config (mirror the mocking used in the existing executor tests):Refs
Hardens the trust check from #28470 (b-519269096) at the one entry point it missed. No behavior change for trusted local CLI flows.
🤖 Generated with Claude Code