Skip to content

[security-fix] Fix unhandled error in semver.go (Alert #477)#9141

Merged
pelikhan merged 1 commit intomainfrom
main-9b7e76afa8d2dd94
Jan 6, 2026
Merged

[security-fix] Fix unhandled error in semver.go (Alert #477)#9141
pelikhan merged 1 commit intomainfrom
main-9b7e76afa8d2dd94

Conversation

@github-actions
Copy link
Contributor

@github-actions github-actions bot commented Jan 6, 2026

Security Fix: Unhandled Error in Semantic Version Parsing

Alert Number: #477
Severity: Low
Rule: G104 - Improper Check or Handling of Exceptional Conditions
Tool: gosec (Golang security checks)
Location: pkg/workflow/semver.go:58

Vulnerability Description

Gosec detected an unhandled error return value from fmt.Sscanf() in the extractMajorVersion() function at line 58. The security scanner flagged this as improper exception handling, which could potentially lead to unexpected behavior if errors are silently ignored without explicit intent.

While the error handling in this case is intentional (the function is designed to default to 0 for non-numeric version parts), the error return value was not explicitly assigned to the blank identifier _, making it unclear whether the error was intentionally ignored or accidentally missed.

Fix Applied

Added explicit error handling by assigning the error return value to the blank identifier _, consistent with the existing pattern used elsewhere in the same file:

Before (line 58):

var major int
fmt.Sscanf(parts[0], "%d", &major)
return major

After (line 58):

var major int
_, _ = fmt.Sscanf(parts[0], "%d", &major) // Ignore error, defaults to 0 for non-numeric parts
return major

This matches the existing error handling pattern used in the compareVersions() function on lines 29 and 32, where errors are explicitly ignored with the same comment.

Security Best Practices

Explicit Error Handling: Makes it clear that errors are intentionally ignored, not accidentally missed
Consistent Code Pattern: Matches the existing pattern used elsewhere in the same file
Documented Behavior: Inline comment explains why the error is ignored
Satisfies Security Scanner: Eliminates gosec G104 alert
No Functional Changes: Behavior remains identical - defaults to 0 for non-numeric parts

Testing

Build succeeded: go build ./pkg/workflow/... passes without errors
No breaking changes: Function behavior is completely unchanged
Minimal change: Only adds explicit error handling for clarity
Code consistency: Matches existing patterns in the same file

Impact Assessment

Risk: None
Breaking Changes: None
Backwards Compatibility: Full
Performance: No impact

The fix is purely cosmetic - it makes explicit what was already happening implicitly. The function continues to return 0 for non-numeric version parts, which is the intended behavior for semantic version comparison.

Context

The extractMajorVersion() function is used to extract the major version number from semantic version strings (e.g., "v5.0.0" → 5). It's designed to be lenient and default to 0 for malformed version strings, which is why error handling is intentionally ignored. This fix simply makes that intent explicit for security scanners and code reviewers.

Files Modified

  • pkg/workflow/semver.go:
    • Line 58: Added explicit error handling with _, _ assignment and explanatory comment

References


🤖 Generated by Security Fix Agent in workflow run 20754292055

AI generated by Security Fix PR

- Added explicit error handling on line 58 in extractMajorVersion function
- Changed 'fmt.Sscanf()' call to '_, _ = fmt.Sscanf()' to explicitly ignore error
- Consistent with existing pattern in lines 29 and 32
- Function intentionally defaults to 0 for non-numeric version parts
- Satisfies gosec G104 security check

🤖 Generated with Claude Code
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
@pelikhan pelikhan marked this pull request as ready for review January 6, 2026 16:28
@pelikhan pelikhan merged commit fc5c60d into main Jan 6, 2026
3 checks passed
@pelikhan pelikhan deleted the main-9b7e76afa8d2dd94 branch January 6, 2026 16:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant