Security patch workflow
How to create, apply, and verify security patches for git repositories. Use this skill when creating patches from code changes, applying patches to source code, or validating that patches correctly address vulnerabilities.From its SKILL.md
npx -y skills add cxcscmu/SkillLearnBench --skill security-patch-workflowAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
SKILL.md
4.3 KB, ~1.0k tokens by cl100k_base, as published. Nobody here has run it
Security Patch Workflow
Overview
Security patches are created as unified diff files that can be transported and applied to source code repositories. This workflow covers creating patches from changes and applying them to Druid or other git repositories.
Creating Patches
Method 1: Creating Patch from Uncommitted Changes
If you've edited files directly:
cd /root/druid
git diff > /root/patches/fix-vulnerability.patch
Method 2: Creating Patch from Committed Changes
If changes are already committed:
cd /root/druid
git format-patch -1 HEAD -o /root/patches/
This creates a patch file named like 0001-fix-vulnerability.patch
Method 3: Creating Patch from Multiple Commits
cd /root/druid
git format-patch HEAD~3..HEAD -o /root/patches/
Creates patches for the last 3 commits.
Understanding Patch File Format
A unified diff patch file contains:
- File paths with
a/andb/prefixes - Hunk headers showing line numbers
- Lines prefixed with
-(removed),+(added), or(context)
Example:
--- a/src/main/java/org/apache/druid/query/filter/JavaScriptFilter.java
+++ b/src/main/java/org/apache/druid/query/filter/JavaScriptFilter.java
@@ -45,6 +45,12 @@
public void init() {
// initialization code
+ // Add validation for filter specification
+ if (filterSpec.containsKey("")) {
+ throw new IllegalArgumentException(
+ "Invalid filter specification: contains empty keys");
+ }
}
Applying Patches
Method 1: Using git apply
Non-interactive application, good for automation:
cd /root/druid
git apply /root/patches/fix-vulnerability.patch
Method 2: Using git am (Recommended for Commits)
If the patch was created with git format-patch:
cd /root/druid
git am /root/patches/0001-fix-vulnerability.patch
Method 3: Using patch Command
Direct application with the patch utility:
cd /root/druid
patch -p1 < /root/patches/fix-vulnerability.patch
Verifying Patch Application
After applying a patch, verify:
1. Check Git Status
cd /root/druid
git status
You should see modified files (if using git apply) or new commits (if using git am).
2. Review Changed Files
cd /root/druid
git diff HEAD~1..HEAD # if patch was committed
# or
git diff # if patch was applied but not committed
3. Verify Specific Fixes
Look for:
- Expected files were modified
- Validation logic was added
- Security checks are in place
- No unintended changes
Handling Patch Conflicts
If a patch doesn't apply cleanly:
cd /root/druid
git apply --reject /root/patches/fix-vulnerability.patch
This creates .rej files showing conflicts. Manually merge them:
# View the .rej files
find . -name "*.rej" -exec cat {} \;
# Manually fix the conflicts in the source files
# Then remove the .rej files
find . -name "*.rej" -delete
# Apply remaining patches
git add .
git commit -m "Apply security patch (manual resolution)"
Patch Best Practices
- Minimal changes: Patches should contain only the necessary fixes
- Clear context: Include sufficient context lines for reliable application
- No unrelated changes: Don't mix security fixes with refactoring
- Test before patching: Verify the original code builds and runs
- Test after patching: Verify the patched code builds and runs correctly
- Document the patch: Include a description of the vulnerability and fix
Creating a Patch Series
For multiple related patches:
# Create numbered patches
git format-patch -3 -o /root/patches/
# List them
ls /root/patches/*.patch
# Apply all in order
cd /root/druid
git am /root/patches/*.patch
Validating Patch Content
Before applying, review the patch to ensure it's legitimate:
cat /root/patches/fix-vulnerability.patch | head -50
Check for:
- Appropriate file modifications
- No suspicious code patterns
- Clear change descriptions
- Expected syntax and structure
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.