Block packages by name, version, or source

Use plain selectors when the policy is about a package's identity or source, rather than a computed property such as vulnerabilities or malware. A rule can match one package, a group of names, one version, a version range, one upstream, or internal or external packages.

Add a rule

In the dashboard, open the firewall, go to Rules, and select Add Rule. Choose the execution phase, set one or more selector fields, then enable block and log.

This rule blocks one package in the versions phase:

{
  "id": "block-example-package",
  "executionPhase": "versions",
  "selector": { "packageName": "example-package" },
  "ruleEffect": { "block": true, "log": true },
  "description": "Block example-package"
}

Use filter versions (versions in config, API, and CLI) when versions should disappear during dependency resolution. Use download when the client should see an explicit block while fetching an artifact. Use upload for rules that apply when a package is published through the firewall. See Execution phases for the request flow.

Choose selector fields

Package and version wildcards accept one *, at the start or end. Version ranges use each ecosystem's own notation and are not available for Conda. The rules and selectors reference has the exact matching and range syntax.

Combine conditions

All set selector fields must match. This rule blocks versions below 2.0.0 only when the named package comes from an external upstream:

{
  "id": "block-old-external-example",
  "executionPhase": "versions",
  "selector": {
    "packageName": "example-package",
    "versionRange": "<2.0.0",
    "internal": "external"
  },
  "ruleEffect": { "block": true, "log": true },
  "description": "Block external example-package versions below 2.0.0"
}

Leaving a field empty makes it unrestricted. A rule with no selector fields matches every package in its execution phase.

Test with log first

For a broad name wildcard or version range, start with log on and block off. Matching requests continue, while the logs show what the rule would affect. After reviewing the matches, enable block without changing the selector.

Verify

Request a package that matches the selector, then inspect the logs:

bsfw logs --firewall <firewall-id>

Confirm the entry contains the expected rule ID, package, version, and upstream. For a client-side request, use the install or publish example on the relevant ecosystem page.

Related

• Concept: Rule evaluation, Execution phases
• Reference: Rules and selectors
• How-to: Manage exceptions, View logs