Rehaul PoC to be tools focused to save on tokens/turns

[QuinnDACollins]

No description provided.

[github-actions]

🤖 Hi @QuinnDACollins, I've received your request, and I'm working on it now! You can track my progress in the logs for more details.

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! 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 significantly refactors the Proof-of-Concept (PoC) generation system to be more efficient and robust by shifting environment setup responsibilities from the LLM to a dedicated tool. This change streamlines the LLM's task, allowing it to concentrate on the core logic of PoC script generation while the system handles the complexities of language-specific environment initialization and temporary file management, ultimately saving computational resources and improving reliability.

Highlights

• PoC Generation Workflow Refactor: The Proof-of-Concept (PoC) generation process has been re-architected from a single LLM prompt into a two-step, tool-focused workflow. The previous security:poc prompt is now replaced by a security:setup_poc tool, which handles environment setup, allowing the LLM to focus solely on generating the PoC script.
• Automated PoC Environment Setup: A new security:setup_poc tool has been introduced to automatically detect the project's primary programming language (Node.js, Python, Go) and set up the necessary PoC directory, including language-specific dependency files (e.g., package.json, requirements.txt, go.mod) and virtual environments (for Python).
• Path Traversal Vulnerability Testing Support: Enhanced support for testing path traversal vulnerabilities has been added. The security:setup_poc tool now creates a temporary file in the workspace root, providing a clear target for PoC scripts to attempt to read, and the runPoc function ensures this temporary file is cleaned up after execution.
• Project Language Detection Utility: A new utility function, detectProjectLanguage, has been implemented to reliably identify the primary programming language of the current project based on common project files and file extensions, enabling language-specific PoC setup.
• Robust PoC Execution Cleanup: The runPoc function now includes a finally block to guarantee the cleanup of the temporary path traversal test file, ensuring a clean state after PoC execution, even if the PoC fails.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Changelog

• mcp-server/src/constants.ts
  • Added PATH_TRAVERSAL_TEMP_FILE constant for path traversal vulnerability testing.
• mcp-server/src/filesystem.ts
  • Added imports for fs promises and path module.
  • Implemented detectProjectLanguage function to identify the project's primary programming language.
• mcp-server/src/index.ts
  • Added imports for exec, promisify, PATH_TRAVERSAL_TEMP_FILE, and detectProjectLanguage.
  • Refactored security:poc prompt into a security:setup_poc tool with updated description and input schema.
  • Implemented logic within security:setup_poc to detect project language, create PoC directory, and initialize language-specific dependency files and environments.
  • Added specific instructions and temporary file creation for path traversal vulnerability testing within the security:setup_poc tool.
  • Adjusted formatting in the security:scan_deps prompt.
• mcp-server/src/poc.test.ts
  • Added imports for fs promises and PATH_TRAVERSAL_TEMP_FILE.
  • Updated error message format for failed PoC execution to include stdout and stderr.
  • Added a new test case to verify cleanup of the path traversal temporary file after runPoc execution.
• mcp-server/src/poc.ts
  • Added import for PATH_TRAVERSAL_TEMP_FILE.
  • Implemented a finally block in runPoc to ensure cleanup of the path traversal temporary file.

Using Gemini Code Assist

The 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 /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize 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 .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. 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.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[github-actions]

📋 Review Summary

This pull request refactors the Proof-of-Concept generation to be more tool-focused, which is a great improvement for efficiency and maintainability. The new security:setup_poc tool provides a more robust and structured way to set up the environment for generating PoCs.

🔍 General Feedback

• The changes are well-structured and the logic is sound.
• The addition of the detectProjectLanguage function is a nice enhancement.
• The cleanup of the temporary file for path traversal tests in a finally block is a good practice.

[github-actions]

🟢 While the current implementation is fine, it's a good practice to log the error in the catch block for future debugging purposes, even if you are returning a default value. This can help identify unexpected issues in the future.

Suggested change

	return 'Unknown';
	} catch {
	return 'Unknown';
	} catch (error) {
	console.error('Failed to detect project language:', error);
	return 'Unknown';
	}
	}

[gemini-code-assist]

Code Review

This pull request refactors the Proof-of-Concept (PoC) generation to be more tool-focused. The main change is replacing the security:poc prompt with a security:setup_poc tool that prepares the environment for PoC generation. While this is a good architectural change, I've identified a high-severity prompt injection vulnerability in the new security:setup_poc tool. User-provided input is directly embedded into a prompt for an LLM, which could allow a malicious user to manipulate the LLM's behavior. My review includes a specific suggestion to mitigate this risk by properly demarcating user input.