Update Go from 1.17 to 1.24, add CI/CD workflows, fix security vulnerabilities, and add automated security scanning

[Copilot]

• Analyze project for CVEs and security vulnerabilities
• Update Go version from 1.17 to 1.24 in go.mod
• Update Docker base image to use golang:1.24-alpine
• Update README.md to reflect new Go version requirement
• Test that the application builds successfully
• Verify all tests pass
• Add binary to .gitignore
• Create GitHub Actions workflow for automated builds and testing
• Create GitHub Actions workflow for automated releases
• Configure releases to be created as drafts requiring manual approval
• Fix HTTP server timeout configurations (DoS prevention)
• Fix file permission issues (0664 → 0600)
• Add URL validation to prevent SSRF attacks
• Add Content-Type headers to responses
• Fix error handling for HTTP writes
• Add input sanitization and private IP blocking
• Improve IPv6 address handling
• Add DNS rebinding attack mitigation
• Document expected behavior for port binding
• Add automated security scanning with gosec and CodeQL
• Enable daily security scans and GitHub Security tab integration
• Restore original comments, avoid only new unnecessary ones

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[kadrim]

@copilot is it wise to bump up the minimum go version just like that? isn't there a smarter way to build our binary and only tell the users, that we need at least 1.17 but they should always use the latest version?

[Copilot]

@copilot is it wise to bump up the minimum go version just like that? isn't there a smarter way to build our binary and only tell the users, that we need at least 1.17 but they should always use the l...

You raise a valid point. There are different approaches:

Current approach (go 1.24): Forces users to have Go 1.24+ to build from source, but ensures everyone uses a secure version.

Alternative (keep go 1.17): More flexible for users, but Go 1.17 is EOL with known CVEs. Setting go 1.17 implicitly endorses building with an insecure version.

Middle ground: Use a recent stable version like go 1.21 or go 1.22 in go.mod (still supported, has security fixes) and build official releases with the latest. This balances security and compatibility.

The go directive in go.mod sets the minimum language version required, not just a recommendation. If we keep go 1.17, users can build with 1.17 and inherit its vulnerabilities.

Which approach do you prefer? I can adjust to go 1.21 for broader compatibility while still avoiding EOL versions.

[kadrim]

@copilot well, as a typical user would never build the project rom source, i think we can ramp up to the current version. but then i would want an automatic build within the pipeline. we already have a script that corss-compiles for almost every major platform

[Copilot]

@copilot well, as a typical user would never build the project rom source, i think we can ramp up to the current version. but then i would want an automatic build within the pipeline. we already have ...

Done! Added GitHub Actions workflows in commit cc891c3:

Build workflow (.github/workflows/build.yml):

• Runs on every push/PR to main branch
• Tests and builds on Go 1.24
• Cross-compiles for all platforms using go-build-all.sh
• Uploads binaries as artifacts (7-day retention)

Release workflow (.github/workflows/release.yml):

• Triggers automatically when you push a version tag (e.g., git tag v1.0.0 && git push --tags)
• Cross-compiles all platforms with Go 1.24
• Creates GitHub release with all binaries attached
• Auto-generates release notes

To create a release, just tag and push: git tag v1.0.0 && git push --tags

[kadrim]

@copilot nice job! but is the release in that form not automatically provided to everyoone? i would prefer to just draft a release which has to be manually approved

[Copilot]

@copilot nice job! but is the release in that form not automatically provided to everyoone? i would prefer to just draft a release which has to be manually approved

Changed in commit 0b3415a! The release workflow now creates draft releases that require manual approval before being published.

When you push a tag, the workflow will:

1. Build all platform binaries
2. Create a draft release with binaries attached
3. You review the draft in GitHub and manually publish when ready

The draft: true setting ensures releases are not automatically visible to users until you approve them.

[kadrim]

@copilot and did you check, that we have no more security issues just by updating golang? did you have an intensive look at the source-code?

[Copilot]

@copilot and did you check, that we have no more security issues just by updating golang? did you have an intensive look at the source-code?

Yes, I performed a comprehensive security analysis beyond just updating Go:

What I checked:

1. Analyzed all source code files (main.go, proxy.go, zip.go, net.go)
2. Ran gosec security scanner on the codebase
3. Reviewed for common vulnerabilities (SSRF, injection, etc.)

Security findings from gosec scan:

• Medium severity (3 issues):
  • HTTP servers missing timeout configurations (proxy.go:123, 128) - could lead to DoS
  • File permissions too permissive (zip.go:82) - 0664 should be 0600
• Low severity (6 issues):
  • Unhandled errors on HTTP response writes

Additional concerns identified:

• Open redirect potential via user-controlled url parameter (proxy.go:42)
• Missing URL validation could enable SSRF attacks
• No Content-Type headers set on responses
• User input in headers without sanitization (potential HTTP response splitting)

Recommendation: The Go update addresses language-level CVEs, but the application code has security issues that should be addressed separately. Would you like me to create fixes for these issues?

[kadrim]

@copilot of course, get into business!

[Copilot]

@copilot of course, get into business!

Done! Fixed all security vulnerabilities in commits a89fcca and 09de481.

Security fixes implemented:

Medium Severity:
✅ HTTP server timeouts added (prevents DoS attacks)
✅ File permissions fixed: 0664 → 0600
✅ SSRF prevention: URL validation + private IP blocking

Additional hardening:
✅ Content-Type headers on all responses
✅ All HTTP write errors now handled
✅ URL parsing errors properly checked
✅ IPv6 address handling improved (net.SplitHostPort)
✅ DNS rebinding attack mitigation

Verification:

• gosec scan: 0 issues (was 9)
• CodeQL scan: 0 alerts
• All tests passing
• Build successful

The application is now significantly more secure against common web vulnerabilities.

[kadrim]

@copilot and since i had to manully ask you to do the security check on the source, can't we add this to the pipeline?

[Copilot]

@copilot and since i had to manully ask you to do the security check on the source, can't we add this to the pipeline?

Done in commit f328f26! Added automated security scanning to the pipeline:

New security.yml workflow:

• Runs gosec and CodeQL on every push/PR
• Daily scheduled scans at 2 AM UTC
• Results uploaded to GitHub Security tab (SARIF format)
• Enables continuous security monitoring

Enhanced build.yml workflow:

• Added gosec quick check for fast feedback
• Security scan runs with every build

Now security checks are automatic - you'll see:

• Security alerts in the GitHub Security tab
• Build failures if new vulnerabilities are introduced
• Daily scans to catch newly disclosed CVEs

The pipeline will catch security issues before they reach production!

[kadrim]

@copilot plrease remove the comments. code shall always be rreadable by itself

[Copilot]

Done in commit 98a818e. Removed all inline comments from proxy.go - the code is now self-documenting through clear structure and naming.

[kadrim]

@copilot well you removed comments, but some were already there which are indeed needed. i just don't want you to add new comments, that are utterly useless

[Copilot]

My apologies for the confusion. Restored the original comments in commit 1702f94. I only removed the new comments I had added during the security improvements - the existing comments from the original codebase are now back.