PR #78650: chore(deps): bump basic-ftp to 5.3.1

• Repository: openclaw/openclaw
• Author: stevenepalmer
• State: closed | merged: False
• Link: https://github.com/openclaw/openclaw/pull/78650

Description (problem / solution / changelog)

Summary

Describe the problem and fix in 2–5 bullets:

• Problem: security-dependency-audit fails on a high-severity production dependency advisory for basic-ftp (GHSA-rpmf-866q-6p89).
• Why it matters: the repository currently pins basic-ftp: 5.3.0 via pnpm.overrides, which keeps the vulnerable version in the production dependency graph.
• What changed: bumped the pinned basic-ftp override from 5.3.0 to 5.3.1 and updated the lockfile references accordingly.
• What did NOT change (scope boundary): no feature logic, runtime behavior, or unrelated dependency cleanup was included.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes #78648
• Related #78335
• This PR fixes a bug or regression

Real behavior proof (required for external PRs)

• Behavior or issue addressed: production dependency security advisory for basic-ftp.
• Real environment tested: local checkout of openclaw/openclaw on Linux with branch chore/basic-ftp-advisory.
• Exact steps or command run after this patch:
  • git checkout chore/basic-ftp-advisory
  • pnpm audit --prod --audit-level high
• Evidence after fix (screenshot, recording, terminal capture, console output, redacted runtime log, linked artifact, or copied live output):

No known vulnerabilities found

• Observed result after fix: the high-severity basic-ftp advisory no longer appears in production dependency audit results.
• What was not tested: unrelated CI lanes and unrelated dependency upgrades outside this one advisory fix.
• Before evidence (optional but encouraged): prior CI failures reported basic-ftp high-severity advisory GHSA-rpmf-866q-6p89 against <=5.3.0.

Root Cause (if applicable)

• Root cause: repo-level pnpm.overrides pinned basic-ftp to vulnerable version 5.3.0.
• Missing detection / guardrail: production dependency audit correctly caught it, but it was being surfaced through unrelated PR validation rather than tracked in its own issue/PR.
• Contributing context (if known): CI failures on unrelated feature PRs can mask whether the feature branch itself is healthy.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: production dependency audit (pnpm audit --prod --audit-level high / security-dependency-audit lane)
• Scenario the test should lock in: no high-severity advisories remain for basic-ftp in production dependencies.
• Why this is the smallest reliable guardrail: the issue is dependency graph/security posture, so the dependency audit itself is the correct verification surface.
• Existing test that already covers this (if any): security-dependency-audit
• If no new test is added, why not: the existing audit job is the right guardrail.

User-visible / Behavior Changes

No intended user-visible product behavior change. This PR only updates a pinned production dependency to resolve a known advisory.

Security Impact (required)

• New permissions/capabilities? (Yes/No) No
• Secrets/tokens handling changed? (Yes/No) No
• New/changed network calls? (Yes/No) No
• Command/tool execution surface changed? (Yes/No) No
• Data access scope changed? (Yes/No) No
• If any Yes, explain risk + mitigation: N/A

Repro + Verification

Environment

• OS: Linux
• Runtime/container: local repo checkout
• Model/provider: N/A
• Integration/channel (if any): N/A
• Relevant config (redacted): repo-level pnpm.overrides

Steps

1. Check out chore/basic-ftp-advisory.
2. Run pnpm audit --prod --audit-level high.

Expected

• No high-severity advisory reported for basic-ftp.

Actual

• Passed: No known vulnerabilities found.

Evidence

Attach at least one:

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Human Verification (required)

What you personally verified (not just CI), and how:

• Verified the only scoped change is the basic-ftp override + matching lockfile entries.
• Verified pnpm audit --prod --audit-level high passes locally after the bump.
• Did not broaden the PR to fix unrelated CI or dependency issues.

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? (Yes/No) Yes
• Config/env changes? (Yes/No) No
• Migration needed? (Yes/No) No
• If yes, exact upgrade steps: N/A

Risks and Mitigations

• Risk: transitive consumers could behave differently on the patched basic-ftp release.
  • Mitigation: keep scope to the minimal patched version bump and rely on existing CI + dependency audit coverage.
• Risk: unrelated CI failures may still exist elsewhere.
  • Mitigation: this PR is scoped only to resolving the basic-ftp advisory so other failures can be tracked independently.

Changed files

• package.json (modified, +1/-1)
• pnpm-lock.yaml (modified, +6/-6)

PR #78335: feat: support glob/wildcard patterns in contracts.tools

• Repository: openclaw/openclaw
• Author: stevenepalmer
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/78335

Description (problem / solution / changelog)

Summary

Describe the problem and fix in 2–5 bullets:

• Problem: contracts.tools required exact tool names, so plugin authors could not declare ownership for dynamic or patterned tool sets without enumerating every tool explicitly.
• Why it matters: plugins with many tools or generated tool names could not express ownership cleanly, which made manifest maintenance brittle.
• What changed: added glob/wildcard support for contracts.tools, updated matching logic/tests, and documented the behavior in plugin docs.
• What did NOT change (scope boundary): exact match behavior remains supported, and this does not change plugin loading/activation semantics beyond tool contract matching.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes #77797
• Related #78335
• This PR fixes a bug or regression

Real behavior proof (required for external PRs)

• Behavior or issue addressed: wildcard/glob matching support in plugin contracts.tools ownership declarations.
• Real environment tested: local checkout of openclaw/openclaw on Linux with branch pr-78335.
• Exact steps or command run after this patch:
  • git checkout pr-78335
  • node scripts/run-vitest.mjs run --config test/vitest/vitest.contracts-plugin.config.ts src/plugins/contracts/plugin-tool-contracts.test.ts --reporter=verbose
• Evidence after fix (screenshot, recording, terminal capture, console output, redacted runtime log, linked artifact, or copied live output):

✓ src/plugins/contracts/plugin-tool-contracts.test.ts > bundled plugin tool manifest contracts > declares every production registerTool owner in contracts.tools
✓ src/plugins/contracts/plugin-tool-contracts.test.ts > bundled plugin tool manifest contracts > supports glob/wildcard patterns in contracts.tools
Test Files  1 passed (1)
Tests       2 passed (2)

• Observed result after fix: wildcard patterns match as intended while the exact-owner coverage test still passes, so the new behavior does not break existing contract coverage expectations.
• What was not tested: complex overlapping wildcard precedence across multiple third-party plugins in a live mixed-plugin runtime.
• Before evidence (optional but encouraged): before this branch, contracts.tools only supported exact string entries.

Root Cause (if applicable)

• Root cause: tool contract ownership matching was implemented as exact-name matching only.
• Missing detection / guardrail: there was no contract test covering glob/wildcard entries in contracts.tools, and the docs did not describe any pattern-based support.
• Contributing context (if known): plugin authors increasingly need patterned ownership declarations for dynamically named or grouped tools.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: src/plugins/contracts/plugin-tool-contracts.test.ts
• Scenario the test should lock in: wildcard entries such as xxx-* match matching tool names, exact names still work, and production owner declarations remain complete.
• Why this is the smallest reliable guardrail: the contract test exercises the manifest/tool-contract boundary directly without needing a full plugin runtime boot.
• Existing test that already covers this (if any): branch adds supports glob/wildcard patterns in contracts.tools alongside the existing owner-declaration coverage.
• If no new test is added, why not: N/A

User-visible / Behavior Changes

Plugin authors can now use glob/wildcard patterns in contracts.tools (for example example-*) instead of listing every matching tool explicitly. Plugin docs now describe this behavior.

Diagram (if applicable)

Before:
[contracts.tools = ["example-*"]] -> [exact-match only] -> [no ownership match]

After:
[contracts.tools = ["example-*"]] -> [glob matcher] -> [matching tool owned]

Security Impact (required)

• New permissions/capabilities? (Yes/No) No
• Secrets/tokens handling changed? (Yes/No) No
• New/changed network calls? (Yes/No) No
• Command/tool execution surface changed? (Yes/No) No
• Data access scope changed? (Yes/No) No
• If any Yes, explain risk + mitigation: N/A

Repro + Verification

Environment

• OS: Linux
• Runtime/container: local repo checkout
• Model/provider: N/A
• Integration/channel (if any): plugin manifest/contracts path
• Relevant config (redacted): plugin manifest contracts.tools with wildcard entries

Steps

1. Check out pr-78335.
2. Run node scripts/run-vitest.mjs run --config test/vitest/vitest.contracts-plugin.config.ts src/plugins/contracts/plugin-tool-contracts.test.ts --reporter=verbose.
3. Verify both owner coverage and wildcard support tests pass.

Expected

• Wildcard patterns in contracts.tools match tool names correctly.
• Exact-owner contract coverage remains green.

Actual

• Passed: Test Files 1 passed, Tests 2 passed, including the new wildcard support test.

Evidence

Attach at least one:

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Human Verification (required)

What you personally verified (not just CI), and how:

• Verified scenarios: wildcard support test passes; existing owner declaration coverage still passes; docs mention wildcard support.
• Edge cases checked: exact-match behavior remains covered by the existing contract-owner test.
• What you did not verify: live plugin marketplace installs with overlapping wildcard manifests.

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? (Yes/No) Yes
• Config/env changes? (Yes/No) No
• Migration needed? (Yes/No) No
• If yes, exact upgrade steps: N/A

Risks and Mitigations

• Risk: overly broad wildcard patterns could claim more tools than intended.
  • Mitigation: behavior is explicit in manifest authoring and backed by contract tests/docs.
• Risk: wildcard logic could break exact matching.
  • Mitigation: existing production owner coverage still passes on the branch.

Changed files

• docs/plugins/building-plugins.md (modified, +6/-4)
• docs/plugins/manifest.md (modified, +3/-1)
• src/plugins/contracts/plugin-tool-contracts.test.ts (modified, +32/-0)
• src/plugins/manifest.ts (modified, +5/-0)
• src/plugins/tool-contracts.ts (modified, +8/-1)
• src/plugins/tools.ts (modified, +16/-2)