From 325263e025d4797d9789f36fa3abf732ec395d89 Mon Sep 17 00:00:00 2001 From: Nipuna Perera Date: Sun, 31 Aug 2025 20:34:20 +0100 Subject: [PATCH 1/2] fix: Resolve release workflow git tag issues - Handle case when no existing tags are present - Fix git log commands that fail with nonexistent tag ranges - Add proper fallback for changelog generation - Bootstrap versioning with initial v0.1.0 tag This resolves the 'fatal: ambiguous argument v0.0.0..HEAD' error in GitHub Actions. --- .github/workflows/release.yml | 42 +++++++++++++++++++++++++---------- 1 file changed, 30 insertions(+), 12 deletions(-) diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml index 3f3e7d1..3e1ef1d 100644 --- a/.github/workflows/release.yml +++ b/.github/workflows/release.yml @@ -56,16 +56,22 @@ jobs: exit 0 fi - # Get commits since last tag - COMMITS=$(git log ${LAST_TAG}..HEAD --oneline) - - if [ -z "$COMMITS" ]; then - echo "No new commits since last tag" - echo "should_release=false" >> $GITHUB_OUTPUT - exit 0 + # Get commits since last tag or all commits if no tags exist + if git describe --tags --abbrev=0 >/dev/null 2>&1; then + # There are existing tags + COMMITS=$(git log ${LAST_TAG}..HEAD --oneline) + if [ -z "$COMMITS" ]; then + echo "No new commits since last tag" + echo "should_release=false" >> $GITHUB_OUTPUT + exit 0 + fi + echo "New commits since $LAST_TAG:" + else + # No existing tags, get all commits + COMMITS=$(git log --oneline) + echo "No existing tags found. All commits:" fi - - echo "New commits since $LAST_TAG:" + echo "$COMMITS" # Determine version bump based on commit messages @@ -172,12 +178,24 @@ jobs: EOF - # Get commits since last tag - git log ${LAST_TAG}..HEAD --pretty=format:"- %s (%h)" >> $CHANGELOG_FILE + # Get commits since last tag or all commits if no tags exist + if git describe --tags --abbrev=0 >/dev/null 2>&1; then + # There are existing tags + git log ${LAST_TAG}..HEAD --pretty=format:"- %s (%h)" >> $CHANGELOG_FILE + else + # No existing tags, get all commits + git log --pretty=format:"- %s (%h)" >> $CHANGELOG_FILE + fi echo "" >> $CHANGELOG_FILE echo "" >> $CHANGELOG_FILE - echo "**Full Changelog**: https://github.com/${{ github.repository }}/compare/${LAST_TAG}...${NEW_VERSION}" >> $CHANGELOG_FILE + + # Generate appropriate changelog link + if git describe --tags --abbrev=0 >/dev/null 2>&1; then + echo "**Full Changelog**: https://github.com/${{ github.repository }}/compare/${LAST_TAG}...${NEW_VERSION}" >> $CHANGELOG_FILE + else + echo "**Full Changelog**: https://github.com/${{ github.repository }}/commits/${NEW_VERSION}" >> $CHANGELOG_FILE + fi # Read changelog content for the release CHANGELOG_CONTENT=$(cat $CHANGELOG_FILE) From 8a0426b6b8d32c7367aae12cd946356b3f5b4a7a Mon Sep 17 00:00:00 2001 From: Nipuna Perera Date: Sun, 31 Aug 2025 20:42:27 +0100 Subject: [PATCH 2/2] fix: release and security policy fixed --- .github/workflows/release.yml | 4 +- SECURITY.md | 114 ++++++++++++++++++++++++++++++++++ 2 files changed, 116 insertions(+), 2 deletions(-) create mode 100644 SECURITY.md diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml index 3e1ef1d..8a77b23 100644 --- a/.github/workflows/release.yml +++ b/.github/workflows/release.yml @@ -71,7 +71,7 @@ jobs: COMMITS=$(git log --oneline) echo "No existing tags found. All commits:" fi - + echo "$COMMITS" # Determine version bump based on commit messages @@ -189,7 +189,7 @@ jobs: echo "" >> $CHANGELOG_FILE echo "" >> $CHANGELOG_FILE - + # Generate appropriate changelog link if git describe --tags --abbrev=0 >/dev/null 2>&1; then echo "**Full Changelog**: https://github.com/${{ github.repository }}/compare/${LAST_TAG}...${NEW_VERSION}" >> $CHANGELOG_FILE diff --git a/SECURITY.md b/SECURITY.md new file mode 100644 index 0000000..0eeb298 --- /dev/null +++ b/SECURITY.md @@ -0,0 +1,114 @@ +# Security Policy + +## Supported Versions + +The following versions of SQLite MCP Server are currently supported with security updates: + +| Version | Supported | +| ------- | ------------------ | +| 0.1.x | :white_check_mark: | +| < 0.1 | :x: | + +**Note**: As this is an early-stage project, we currently only support the latest minor version. Once we reach version 1.0, we will maintain security support for multiple versions. + +## Reporting a Vulnerability + +We take security vulnerabilities seriously. If you discover a security issue in SQLite MCP Server, please report it responsibly. + +### How to Report + +**For security vulnerabilities, please do NOT create a public GitHub issue.** + +Instead, please report security vulnerabilities through one of the following methods: + +1. **GitHub Security Advisories** (Recommended) + - Go to the [Security tab](https://github.com/nipunap/sqlite-mcp-server/security) of this repository + - Click "Report a vulnerability" + - Fill out the security advisory form + +2. **Email** (Alternative) + - Send an email with details to the repository maintainer + - Include "SECURITY" in the subject line + - Provide as much detail as possible about the vulnerability + +### What to Include + +When reporting a vulnerability, please include: + +- **Description**: A clear description of the vulnerability +- **Steps to Reproduce**: Detailed steps to reproduce the issue +- **Impact**: What could an attacker accomplish with this vulnerability? +- **Affected Versions**: Which versions of the software are affected +- **Suggested Fix**: If you have ideas for how to fix the issue (optional) +- **Proof of Concept**: Code or screenshots demonstrating the vulnerability (if applicable) + +### Response Timeline + +We are committed to responding to security reports promptly: + +- **Initial Response**: Within 48 hours of receiving the report +- **Status Updates**: Weekly updates on investigation progress +- **Resolution Timeline**: We aim to resolve critical vulnerabilities within 7 days, and other vulnerabilities within 30 days + +### What to Expect + +**If the vulnerability is accepted:** +- We will work with you to understand and reproduce the issue +- We will develop and test a fix +- We will coordinate the disclosure timeline with you +- We will credit you in the security advisory (unless you prefer to remain anonymous) +- We will release a security update and publish a security advisory + +**If the vulnerability is declined:** +- We will provide a clear explanation of why we don't consider it a security issue +- We may suggest alternative ways to address your concerns +- You are welcome to discuss our decision if you disagree + +## Security Best Practices + +When using SQLite MCP Server, please follow these security best practices: + +### Database Security +- **File Permissions**: Ensure database files have appropriate file system permissions +- **Access Control**: Limit access to database files to authorized users only +- **Backup Security**: Secure your database backups appropriately + +### Network Security +- **Local Use**: SQLite MCP Server is designed for local use; avoid exposing it over networks +- **Input Validation**: Always validate and sanitize inputs when building applications on top of the server + +### Configuration Security +- **Minimal Permissions**: Run the server with minimal required permissions +- **Regular Updates**: Keep the server updated to the latest supported version +- **Monitoring**: Monitor server logs for suspicious activity + +## Scope + +This security policy covers: +- The SQLite MCP Server core application +- Official Docker images (if any) +- Official documentation and examples + +This policy does not cover: +- Third-party integrations or plugins +- User-created configurations or customizations +- Issues in dependencies (report these to the respective projects) + +## Security Features + +SQLite MCP Server includes the following security features: + +- **Input Validation**: SQL injection protection through prepared statements +- **Error Handling**: Secure error messages that don't leak sensitive information +- **Resource Limits**: Protection against resource exhaustion attacks +- **Safe Defaults**: Secure default configuration settings + +## Acknowledgments + +We appreciate the security research community and will acknowledge researchers who report valid security vulnerabilities (unless they prefer to remain anonymous). + +--- + +**Last Updated**: December 2024 + +For general questions about this security policy, please create a public GitHub issue with the "security" label.