Fix network/firewall schema description and engine support inconsistencies#17909
Fix network/firewall schema description and engine support inconsistencies#17909
Conversation
…ncies - Fix schema network.firewall description to include all 4 engines - Add cleanup_script field to firewall object schema - Fix log_level → log-level key in engine.go to match schema - hasNetworkRestrictions() now returns true when Blocked list is non-empty - Add gemini case to computeAllowedDomainsForSanitization Co-authored-by: pelikhan <4175913+pelikhan@users.noreply.github.com>
|
Hey Add test coverage — The logic changes in
The project's testing patterns (see If you'd like to add test coverage, you can use this prompt:
|
pkg/workflow/domains.go
Outdated
| case "claude": | ||
| return GetClaudeAllowedDomains(data.NetworkPermissions) | ||
| case "gemini": | ||
| return GetGeminiAllowedDomainsWithToolsAndRuntimes(data.NetworkPermissions, data.Tools, data.Runtimes) |
There was a problem hiding this comment.
@copilot review why Gemini uses runtime and the other no...
There was a problem hiding this comment.
Good catch — Gemini only had the WithToolsAndRuntimes variant available, but the original copilot/codex/claude cases were using the simpler (no tools/runtimes) variants, creating an inconsistency.
The actual engine execution code (copilot_engine_execution.go, codex_engine.go, claude_engine.go, gemini_engine.go) all use WithToolsAndRuntimes when computing the real firewall domains. So computeAllowedDomainsForSanitization should match that — tools (HTTP MCP server domains) and runtimes (ecosystem domains like npm/pypi) must be included to get the correct domain set for sanitization.
Fixed in a981e31 — all four engine cases now call WithToolsAndRuntimes.
…for all engines All engine cases now call the WithToolsAndRuntimes variant for consistency with the actual engine execution code (copilot_engine_execution.go, codex_engine.go, claude_engine.go, gemini_engine.go), ensuring tool MCP domains and runtime ecosystem domains are included in sanitization. Co-authored-by: pelikhan <4175913+pelikhan@users.noreply.github.com>
|
@copilot use dashes in field names |
… field names Co-authored-by: pelikhan <4175913+pelikhan@users.noreply.github.com>
There was a problem hiding this comment.
Pull request overview
Aligns network/firewall schema docs and engine behavior, and updates allowed-domain computation so sanitization and runtime firewall inputs stay consistent across engines.
Changes:
- Updates
network.firewallschema description and addscleanup-scriptto the schema. - Standardizes firewall config key parsing in
engine.go(log-level,cleanup-script) and expands network restriction detection to includeblocked. - Updates allowed-domain computation to include tools/runtimes for all supported engines and adds an explicit
geminibranch; refreshes workflow lockfiles with the resulting domain lists.
Reviewed changes
Copilot reviewed 19 out of 19 changed files in this pull request and generated 4 comments.
Show a summary per file
| File | Description |
|---|---|
| pkg/workflow/engine_firewall_support.go | Treats network.blocked as a network restriction. |
| pkg/workflow/engine.go | Switches engine firewall parsing keys to dash-style (log-level, cleanup-script). |
| pkg/workflow/domains.go | Uses WithToolsAndRuntimes consistently and adds a gemini case for sanitization domains. |
| pkg/parser/schemas/main_workflow_schema.json | Fixes firewall description and adds cleanup-script to network.firewall schema. |
| .github/workflows/smoke-test-tools.lock.yml | Updates GH_AW_ALLOWED_DOMAINS output to match new domain computation. |
| .github/workflows/smoke-gemini.lock.yml | Updates GH_AW_ALLOWED_DOMAINS for Gemini to match new domain computation. |
| .github/workflows/smoke-copilot.lock.yml | Updates GH_AW_ALLOWED_DOMAINS output to match new domain computation. |
| .github/workflows/smoke-copilot-arm.lock.yml | Updates GH_AW_ALLOWED_DOMAINS output to match new domain computation. |
| .github/workflows/smoke-codex.lock.yml | Updates GH_AW_ALLOWED_DOMAINS output to match new domain computation. |
| .github/workflows/smoke-claude.lock.yml | Updates GH_AW_ALLOWED_DOMAINS output to match new domain computation. |
| .github/workflows/slide-deck-maintainer.lock.yml | Updates GH_AW_ALLOWED_DOMAINS output to match new domain computation. |
| .github/workflows/scout.lock.yml | Updates GH_AW_ALLOWED_DOMAINS output to match new domain computation. |
| .github/workflows/schema-consistency-checker.lock.yml | Updates GH_AW_ALLOWED_DOMAINS output to match new domain computation. |
| .github/workflows/research.lock.yml | Updates GH_AW_ALLOWED_DOMAINS output to match new domain computation. |
| .github/workflows/mcp-inspector.lock.yml | Updates GH_AW_ALLOWED_DOMAINS output to match new domain computation. |
| .github/workflows/jsweep.lock.yml | Updates GH_AW_ALLOWED_DOMAINS output to match new domain computation. |
| .github/workflows/github-mcp-tools-report.lock.yml | Updates GH_AW_ALLOWED_DOMAINS output to match new domain computation. |
| .github/workflows/docs-noob-tester.lock.yml | Updates GH_AW_ALLOWED_DOMAINS output to match new domain computation. |
| .github/workflows/daily-news.lock.yml | Updates GH_AW_ALLOWED_DOMAINS output to match new domain computation. |
Comments suppressed due to low confidence (1)
pkg/workflow/engine_firewall_support.go:40
- There are unit tests for
hasNetworkRestrictions, but they don’t cover the newnetwork.blocked-only behavior. Please add a test case whereBlockedis non-empty (andAllowedis empty/unset) to ensure this regression doesn’t come back.
// If blocked domains are specified, we have restrictions
if len(networkPermissions.Blocked) > 0 {
return true
}
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| // If blocked domains are specified, we have restrictions | ||
| if len(networkPermissions.Blocked) > 0 { | ||
| return true | ||
| } |
There was a problem hiding this comment.
hasNetworkRestrictions now treats network.blocked as a restriction, but the firewall-disable validation path still only considers len(networkPermissions.Allowed) > 0 as “has restrictions” and its messages/errors mention only network.allowed. This creates a real gap: a workflow with only network.blocked set can disable the firewall without triggering the intended warning/error, undermining the restriction. Please update checkFirewallDisable (and related messages) to treat blocked-only configs as restrictions too.
This issue also appears on line 37 of the same file.
| switch engineID { | ||
| case "copilot": | ||
| return GetCopilotAllowedDomains(data.NetworkPermissions) | ||
| return GetCopilotAllowedDomainsWithToolsAndRuntimes(data.NetworkPermissions, data.Tools, data.Runtimes) | ||
| case "codex": | ||
| return GetCodexAllowedDomains(data.NetworkPermissions) | ||
| return GetCodexAllowedDomainsWithToolsAndRuntimes(data.NetworkPermissions, data.Tools, data.Runtimes) | ||
| case "claude": | ||
| return GetClaudeAllowedDomains(data.NetworkPermissions) | ||
| return GetClaudeAllowedDomainsWithToolsAndRuntimes(data.NetworkPermissions, data.Tools, data.Runtimes) | ||
| case "gemini": | ||
| return GetGeminiAllowedDomainsWithToolsAndRuntimes(data.NetworkPermissions, data.Tools, data.Runtimes) |
There was a problem hiding this comment.
computeAllowedDomainsForSanitization now has a dedicated gemini case and uses the WithToolsAndRuntimes variants. There are existing tests for this function, but they don’t cover Gemini (and don’t exercise the tools/runtimes inclusion). Please add test coverage for the gemini branch and at least one case where tools/runtimes contribute domains, so the sanitization allowlist stays aligned with the runtime firewall behavior.
| }, | ||
| "cleanup-script": { | ||
| "type": "string", | ||
| "description": "Path to cleanup script run after AWF shuts down (default: ./scripts/ci/cleanup.sh)" |
There was a problem hiding this comment.
Schema now documents network.firewall.cleanup-script, but the compiler’s extractFirewallConfig path (used for network.firewall) doesn’t parse this field, and CleanupScript is not used anywhere when building AWF commands. As-is, users can set cleanup-script and it will be silently ignored. Please wire this through end-to-end: parse the field from network.firewall (ideally accepting both cleanup-script and the legacy underscore form for compatibility) and ensure it is actually applied during/after AWF shutdown (or remove it from the schema if it’s not supported).
| }, | |
| "cleanup-script": { | |
| "type": "string", | |
| "description": "Path to cleanup script run after AWF shuts down (default: ./scripts/ci/cleanup.sh)" |
| // Extract log-level field (default: "debug") | ||
| if logLevel, hasLogLevel := firewallObj["log-level"]; hasLogLevel { | ||
| if logLevelStr, ok := logLevel.(string); ok { | ||
| firewallConfig.LogLevel = logLevelStr | ||
| } |
There was a problem hiding this comment.
The comment says log-level defaults to "debug", but runtime behavior defaults to "info" (see BuildAWFArgs using constants.AWFDefaultLogLevel, and schema enum/docs). Please update the comment to avoid misleading users/maintainers about the default.
network.firewalldescription removing "Only supported for Copilot engine"cleanup-scriptto firewall object schemalog_level→log-level(hyphen) inengine.goBlockedlist check inhasNetworkRestrictions()geminicase incomputeAllowedDomainsForSanitizationcomputeAllowedDomainsForSanitizationto useWithToolsAndRuntimesconsistently for all enginescleanup_script→cleanup-scriptfor consistent dash-style field namesOriginal prompt
✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.