Dan Guido cc938e105f refactor: standardize packaging across all components (#266)
* refactor: standardize packaging across all components

- Standardize Python version to >=3.12,<3.13 for all components
- Migrate from [project.optional-dependencies] to modern [dependency-groups] (PEP 735)
- Standardize ruff line-length to 120 characters across all components
- Add consistent project metadata:
  - AGPL-3.0 license field
  - Repository and Issues URLs
  - Improved, descriptive description fields
  - Fix email addresses to include .com domain

This improves consistency, maintainability, and follows modern Python
packaging best practices with uv/pip standards.

* fix: address PR review comments

- Move requires-python field to standard position (after license) in seed-gen
- Update all components to use latest ruff version (>=0.12.8)
- Ensure consistent dependency ordering across all components

* refactor: standardize dependency pinning strategy

Apply consistent dependency versioning across all components:

- Use ~= (compatible release) for core dependencies:
  - Infrastructure: redis, pydantic, fastapi, uvicorn, sqlalchemy
  - AI/LLM: openai, langchain-community, langgraph-checkpoint
  - Parsing: tree-sitter, tree-sitter-language-pack
  - Web: requests, urllib3, pyyaml
  - Utils: python-dotenv, unidiff, argon2-cffi, pymongo, six

- Keep >= for stable dev tools:
  - pytest, mypy, ruff, flake8 (want latest versions)
  - types-* packages (want latest type definitions)
  - rich, beautifulsoup4 (stable, backwards compatible)

- Keep exact pins for known issues:
  - protobuf (narrow range for compatibility)
  - openlit==1.32.12 (documented issue with 1.33)
  - clusterfuzz==2.6.0 (complex, version-sensitive)

This provides predictable builds with automatic patch updates while
preventing unexpected breaking changes from major/minor version bumps.

* feat: add project metadata for discoverability

Add comprehensive metadata to all components:

Keywords:
- common: cybersecurity, crs, utilities, protobuf, redis, telemetry
- fuzzer: fuzzing, oss-fuzz, libfuzzer, vulnerability-discovery, coverage
- orchestrator: orchestration, task-management, scheduler, api, fastapi
- patcher: patching, vulnerability-repair, llm, ai, code-generation
- program-model: static-analysis, codequery, tree-sitter, semantic-analysis
- seed-gen: test-generation, input-generation, fuzzing, seed-corpus, llm

Classifiers:
- Development Status :: 4 - Beta (all components)
- License :: OSI Approved :: GNU Affero General Public License v3
- Programming Language :: Python :: 3.12
- Topic :: Security (all components)
- Component-specific topics (Testing, AI, Distributed Computing, etc.)
- Operating System :: POSIX :: Linux

URLs:
- Added Documentation URL pointing to README for all components

This improves package discoverability, provides clear metadata for tools,
and gives the project a more professional appearance.

* Standardize tool configurations across all components

- Add pytest.ini_options configuration to all components
- Add coverage configuration with consistent exclude patterns
- Standardize ruff configuration with target-version and lint rules
- Fix missing readme field in fuzzer/pyproject.toml
- Fix python-dotenv spacing inconsistency in seed-gen
- Standardize all dev dependencies to use ~= operator for consistency

* Fix trailing whitespace and line length issues

- Remove trailing whitespace from tree-sitter query strings
- Remove trailing whitespace from test output strings
- Fix line length issues in logger.info() calls by splitting format strings
- Fix line length in datetime formatting by extracting variables
- Split long Pydantic Field descriptions and docstrings
- Leave test data strings unchanged to avoid breaking tests

* Fix dependency resolution issues

- Update argon2-cffi from ~=21.0.0 to ~=21.3.0 (21.0.x doesn't exist on PyPI)
- Update langgraph-checkpoint from ~=2.0.25 to ~=2.1.0 to match langgraph requirements
- Standardize spacing around ~= operators in all dependency specifications
- All components now successfully resolve dependencies with uv

* Apply ruff auto-fixes across project

- Fix import sorting (I001) in fuzzer, orchestrator, and patcher
- Update to PEP 585 type annotations (List->list, Dict->dict, etc.)
- Update to PEP 604 union syntax (Optional[X] -> X | None)
- Remove unnecessary UTF-8 encoding declarations
- Remove redundant file open modes
- Modernize type annotations throughout the codebase

Remaining issues are primarily line length (E501) which require manual review

* Fix line length issues in program-model component

- Break up long Java code strings in test assertions using implicit concatenation
- Split long constructor and method definitions across multiple lines
- Add noqa: E501 comment for 10,977 character struct definition test data
- All program-model line length issues resolved

* fix: revert protobuf enum type annotations to Optional

Protobuf enums (EnumTypeWrapper) don't support the | operator for type unions.
The ruff UP035 rule converted Optional[ProtobufEnum] to ProtobufEnum | None,
but this causes TypeError at runtime. Reverted these specific changes while
keeping the modern type union syntax for regular Python types.

* chore: add ruff protection for protobuf enum type annotations

- Configure ruff to ignore UP045 rule in test_submissions.py
- Add inline noqa comments to document why Optional is needed
- Protobuf enums (EnumTypeWrapper) don't support the | operator
- This prevents future automated fixes from breaking the code

* fix: modernize Python syntax and fix formatting issues

- Convert printf-style formatting to f-strings (UP031)
- Remove trailing whitespace from blank lines (W293)
- Use PEP 695 generic class syntax for Python 3.12+ (UP046)
- Use PEP 695 type alias syntax with 'type' keyword (UP040)

These changes modernize the codebase to use Python 3.12+ features
and fix formatting inconsistencies detected by ruff.

* fix: resolve undefined MsgType reference after PEP 695 conversion

When converting to PEP 695 generic class syntax, the MsgType TypeVar
was removed but was still referenced in overloaded method signatures.
Changed the generic fallback overload to use Message directly.

* fix: resolve line length violations across entire codebase

Applied Black formatter and manual fixes to resolve E501 line length violations:
- Fixed 178 line length issues across common, fuzzer, orchestrator, patcher, and program-model components
- Used Black formatter for automatic reformatting where possible
- Manually split long strings, function calls, and complex expressions
- All files now comply with 120-character line limit

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>

* fix: revert PEP 695 type alias syntax in node_local.py

The PEP 695 syntax (type X = Y) creates TypeAliasType objects that cannot
be used as constructors at runtime. Since node_local.py uses NodeLocalPath
and RemotePath as constructors (e.g., NodeLocalPath(path)), we must use
the old TypeAlias syntax to maintain runtime functionality.

Added noqa comments to prevent ruff from attempting to modernize these
aliases in the future.

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>

* chore: configure ruff to ignore UP040 for node_local.py

Added per-file configuration to prevent ruff from attempting to convert
TypeAlias annotations to PEP 695 syntax in node_local.py. This protects
the runtime functionality that relies on these type aliases being usable
as constructors.

Also removed redundant inline noqa comments since the ignore is now
configured at the project level.

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>

* fix: correct MsgType reference in static method decorator

The _ensure_group_name static method decorator was incorrectly
referencing MsgType in the wrapper function signature. Since MsgType
is a class-level type parameter and not accessible in static method
scope, changed it to Message which is the appropriate bound type.

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>

* docs: add explanatory comment for Message type in decorator

Added a comment explaining why we must use Message instead of MsgType
in the _ensure_group_name decorator's wrapper function. This prevents
future confusion and protects against accidental "fixes" that would
break the code.

The MsgType parameter is a class-level type variable that's not in
scope within the static method decorator context.

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>

---------

Co-authored-by: Claude <noreply@anthropic.com>
2025-08-08 19:59:56 -07:00
2025-06-20 17:03:33 -04:00
2025-01-17 14:57:33 +01:00
2025-02-18 11:59:16 -05:00
2025-01-13 13:48:03 +01:00
2025-01-23 09:32:18 +01:00

Buttercup Cyber Reasoning System (CRS)

Tests Integration Tests System Integration

Buttercup is a Cyber Reasoning System (CRS) developed by Trail of Bits for the DARPA AIxCC (AI Cyber Challenge). Buttercup finds and patches software vulnerabilities in open-source code repositories like example-libpng. It starts by running an AI/ML-assisted fuzzing campaign (built on oss-fuzz) for the program. When vulnerabilities are found, Buttercup analyzes them and uses a multi-agent AI-driven patcher to repair the vulnerability. Buttercup system consists of several components:

  • Orchestrator: Coordinates the overall task process and manages the workflow
  • Seed Generator: Creates inputs for vulnerability discovery
  • Fuzzer: Discovers vulnerabilities through intelligent fuzzing techniques
  • Program Model: Analyzes code structure and semantics for better understanding
  • Patcher: Generates and applies security patches to fix vulnerabilities

System Requirements

Minimum Requirements

  • CPU: 8 cores
  • Memory: 16 GB RAM
  • Storage: 100 GB available disk space
  • Network: Stable internet connection for downloading dependencies

Note: Buttercup uses third-party AI providers (LLMs from companies like OpenAI, Anthropic and Google), which cost money. Please ensure that you manage per-deployment costs by using the built-in LLM budget setting.

Note: Buttercup works best with access to models from OpenAI and Anthropic, but can be run with at least one API key from one third-party provider (support for Gemini coming soon).

Supported Systems

  • Linux x86_64 (fully supported)
  • ARM64 (partial support for upstream Google OSS-Fuzz projects)

Required System Packages

Before setup, ensure you have these packages installed:

# Ubuntu/Debian
sudo apt-get update
sudo apt-get install -y make curl git

# RHEL/CentOS/Fedora
sudo yum install -y make curl git
# or
sudo dnf install -y make curl git

# MacOS
brew install make curl git

Supported Targets

Buttercup works with:

  • C source code repositories that are OSS-Fuzz compatible
  • Java source code repositories that are OSS-Fuzz compatible
  • Projects that build successfully and have existing fuzzing harnesses

Quick Start

  1. Clone the repository with submodules:
git clone --recurse-submodules https://github.com/trailofbits/buttercup.git
cd buttercup
  1. Run automated setup (Recommended)
make setup-local

This script will install all dependencies, configure the environment, and guide you through the setup process.

Note: If you prefer manual setup, see the Manual Setup Guide.

  1. Start Buttercup locally
make deploy-local
  1. Verify local deployment:
make status

When a deployment is successful, you should see all pods in "Running" or "Completed" status.

  1. Send Buttercup a simple task

Note: When tasked, Buttercup will start consuming third-party AI resources.

This command will make Buttercup pull down an example repo example-libpng with a known vulnerability. Buttercup will start fuzzing it to find and patch vulnerabilities.

make send-libpng-task
  1. Access Buttercup's web-based GUI

Run:

make web-ui

Then navigate to http://localhost:31323 in your web browser.

In the GUI you can monitor active tasks and see when Buttercup finds bugs and generates patches for them.

  1. Stop Buttercup

Note: This is an important step to ensure Buttercup shuts down and stops consuming third-party AI resources.

make undeploy

Accessing Logs

Buttercup includes local SigNoz deployment by default for comprehensive system observability. You can access logs, traces, and metrics through the SigNoz UI:

make signoz-ui

Then navigate to http://localhost:33301 in your web browser to view:

  • Distributed traces
  • Application metrics
  • Error monitoring
  • Performance insights

If you configured LangFuse during setup, you can also monitor LLM usage and costs there.

For additional log access methods, see the Quick Reference Guide.

Additional Resources

S
Description
Automated archival mirror of github.com/trailofbits/buttercup
Readme AGPL-3.0 28 MiB
Languages
Python 93.4%
Shell 3%
JavaScript 1.4%
CSS 0.6%
Dockerfile 0.4%
Other 1.2%