Z.ai GLM-4.7 implementation

[ShepAlderson]

Created using the Z.ai GLM-4.7 model on the Z.ai coding plan, using Claude Code as the agent and the ralph-tui as the "driver".

This mostly works on the one shot, however it also struggled with the scrolling and keybindings. With a couple additional prompts I was able to get it working. Functionally, it's probably the most complete, though it would need more tweaks to be "production ready"

Scrolling through the issues does update the details pane, though it does seem to be struggling with the embedded images.

[Copilot]

Pull request overview

This PR implements a TUI (Terminal User Interface) for viewing GitHub issues, generated by Z.ai GLM-4.7 model using Claude Code as the agent. The implementation includes comprehensive functionality for viewing, sorting, filtering, and navigating GitHub issues with markdown rendering support.

Changes:

• Adds complete TUI implementation with multiple views (list, detail, comments, help, error handling)
• Implements storage layer with SQLite database for caching issues
• Adds GitHub API client for fetching issues and comments
• Includes configuration management, authentication, theming, and sorting functionality
• Updates prd.json to mark all user stories as completed

Reviewed changes

Copilot reviewed 41 out of 57 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
tasks/prd.json	Marks all 14 user stories as completed with metadata timestamp
internal/tui/*.go	Complete TUI implementation with app, views, and state management
internal/tui/*_test.go	Comprehensive test coverage for TUI components
internal/theme/*.go	Theme system with 6 built-in color schemes
internal/storage/*.go	SQLite database layer for persistent storage
internal/github/*.go	GitHub API client with pagination and authentication
internal/config/*.go	TOML configuration management
internal/auth/*.go	Multi-source authentication (env, config, gh CLI)
internal/sync/*.go	Background sync with progress tracking and cancellation
internal/sort/*.go	Issue sorting with multiple fields
internal/timefmt/*.go	Relative time formatting utilities
internal/setup/*.go	Interactive setup wizard
internal/database/*.go	Database path resolution and validation

---

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

[ShepAlderson]

Review from Claude Code using Sonnet 4.5:

Security Review Report

Date: 2026-01-21
Repository: github-issues-tui
Reviewer: Claude Sonnet 4.5

Executive Summary

A comprehensive security review was conducted on the github-issues-tui codebase. The review identified 4 security issues requiring attention, with the most critical being a database file committed to git history containing potentially sensitive GitHub issue data. Overall, the codebase follows good security practices with proper SQL parameterization, input validation, and secure file permissions.

Risk Level: HIGH (due to data exposure in git history)

---

🔴 CRITICAL ISSUES

1. Database File Committed to Git History

Location: .ghissues.db
Severity: CRITICAL
Status: Active in git history

Description

The SQLite database file has been committed to git 5 times and contains:

• 100 GitHub issues
• 141 issue comments
• User data (usernames, issue content)
• File size: ~360KB (as of last commit)

Impact

Anyone with access to this repository's git history can extract all synced GitHub issues and comments, potentially exposing:

• Private discussions
• User information
• Issue content that may contain sensitive data
• Comment threads

Remediation

Option 1: Using git-filter-repo (Recommended)

# Install git-filter-repo if not already installed
# brew install git-filter-repo  # macOS
# pip install git-filter-repo    # or via pip

git filter-repo --path .ghissues.db --invert-paths

Option 2: Using git filter-branch

git filter-branch --force --index-filter \
  "git rm --cached --ignore-unmatch .ghissues.db" \
  --prune-empty --tag-name-filter cat -- --all

After removing from history:

# Force push to remote (WARNING: This rewrites history)
git push origin --force --all
git push origin --force --tags

---

2. Missing .gitignore File

Location: Repository root
Severity: CRITICAL
Status: Missing

Description

No .gitignore file exists in the repository root, allowing sensitive files to be accidentally committed. This is the root cause of Issue #1.

Impact

• Database files can be accidentally committed
• Configuration files with tokens can be exposed
• Build artifacts and OS-specific files clutter the repository
• Increased risk of credential exposure

Remediation

Create .gitignore file in repository root:

# Database files
*.db
.ghissues*.db

# Config files with potential secrets
auth.toml
config.toml
.env
.env.*

# Build artifacts
ghissues
*.exe
*.test
*.out

# IDE files
.vscode/
.idea/
*.swp
*.swo
*~

# OS files
.DS_Store
Thumbs.db
.Spotlight-V100
.Trashes

# Development
.ralph-tui/
*.log

---

3. Database File Permissions Too Permissive

Location: Database files created by the application
Current Permissions: 644 (world-readable)
Required Permissions: 600 (owner read/write only)
Severity: HIGH

Description

Database files are created with default permissions (644), making them readable by all users on the system. This exposes GitHub issue data to other users on shared systems.

Impact

On multi-user systems:

• Any user can read synced GitHub issues
• Potential exposure of private repository data
• Violation of principle of least privilege

Remediation

Add permission setting after database creation in internal/storage/storage.go:

func InitializeDatabase(dbPath string) (*sql.DB, error) {
	db, err := sql.Open("sqlite", dbPath)
	if err != nil {
		return nil, fmt.Errorf("failed to open database: %w", err)
	}

	// Set secure file permissions (owner read/write only)
	if err := os.Chmod(dbPath, 0600); err != nil {
		return nil, fmt.Errorf("failed to set database permissions: %w", err)
	}

	// ... rest of initialization

Alternative: Create the file first with proper permissions:

// Create file with secure permissions before opening
f, err := os.OpenFile(dbPath, os.O_RDWR|os.O_CREATE, 0600)
if err != nil {
	return nil, err
}
f.Close()

---

⚠️ MEDIUM SEVERITY ISSUES

4. Plaintext Token Storage in Config File

Location: internal/config/config.go:54, internal/setup/setup.go:151
Severity: MEDIUM
Current Mitigation: File permissions set to 0600

Description

GitHub tokens are stored in plaintext in the TOML configuration file. While the config file is created with secure permissions (0600), the tokens remain unencrypted at rest.

Impact

• If file permissions are accidentally changed, tokens are exposed
• Backup systems may expose tokens
• File could be read if system is compromised
• Risk increases on shared hosting environments

Current Mitigations

The code properly prioritizes authentication sources:

1. Environment variables (GITHUB_TOKEN)
2. Config file token
3. GitHub CLI token (more securely stored)

File permissions are set to 0600 in config.go:103

Recommendations

Short-term:

• Document the security implications in README
• Recommend using GitHub CLI or environment variables
• Add warning when prompting for token

Long-term:
Consider implementing OS-native credential storage:

• macOS: Keychain API
• Windows: Credential Manager
• Linux: Secret Service (libsecret)

Example libraries:

• github.com/99designs/keyring
• github.com/zalando/go-keyring

---

✅ POSITIVE SECURITY FINDINGS

1. No Hardcoded Secrets

• No API keys, tokens, or passwords found in source code
• Authentication properly sourced from environment or config files

2. SQL Injection Prevention

All database queries use parameterized statements with ? placeholders:

• internal/storage/storage.go:116 - StoreIssue
• internal/storage/storage.go:148 - StoreComment
• internal/storage/storage.go:237 - GetCommentsForIssue
• internal/storage/storage.go:336 - DeleteIssuesNotInList

3. Secure Configuration File Permissions

Config files created with 0600 permissions (internal/config/config.go:103)

4. Proper TLS/HTTPS Usage

• GitHub API accessed via HTTPS only
• Standard Go HTTP client with secure defaults
• No InsecureSkipVerify flags found

5. Input Validation

Repository names validated using regex patterns:

• internal/config/config.go:127 - ValidateRepository
• internal/github/github.go:301 - ValidateRepo

6. No Command Injection Vulnerabilities

No unsafe command execution or shell injection patterns detected

7. Path Traversal Protection

All file operations use filepath.Join() for safe path construction

8. No Token Logging

Tokens are never logged or printed to output. Only used in HTTP Authorization headers:

• internal/github/github.go:106
• internal/github/github.go:209

9. Proper Error Handling

Sensitive information not exposed in error messages

---

📋 RECOMMENDATIONS

Immediate Actions (Priority 1)

1. Remove database from git history (Issue Claude Sonnet 4.5 Implementation #1)

   • Use git-filter-repo to remove .ghissues.db
   • Force push to remote repositories
   • Notify collaborators of history rewrite

2. Create .gitignore file (Issue MiniMax M2.1 implementation #2)

   • Add database files, config files, and build artifacts
   • Commit and push immediately

3. Fix database permissions (Issue Z.ai GLM-4.7 implementation #3)

   • Add os.Chmod(dbPath, 0600) after database creation
   • Test on multiple platforms

Short-term Improvements (Priority 2)

1. Documentation

   • Add security section to README
   • Document token storage security model
   • Warn against committing database files

2. Pre-commit Hook

   • Add git hook to prevent committing .db files
   • Can be implemented in .git/hooks/pre-commit

3. User Guidance

   • Add warning message when user enters token manually
   • Recommend GitHub CLI or environment variables

Long-term Enhancements (Priority 3)

1. Credential Storage

   • Implement OS keychain integration
   • Migrate existing plaintext tokens

2. Audit Logging

   • Log security-relevant operations
   • Track authentication attempts

3. Rate Limiting

   • Implement client-side rate limiting for GitHub API
   • Prevent abuse and quota exhaustion

4. Data Encryption

   • Consider encrypting sensitive data at rest
   • Implement secure key management

5. Security Testing

   • Add security-focused unit tests
   • Implement automated security scanning (e.g., gosec)
   • Regular dependency updates for security patches

---

📊 RISK ASSESSMENT

Category	Rating	Notes
Data Exposure	HIGH	Database in git history
Authentication	MEDIUM	Plaintext token storage, mitigated by file permissions
Code Security	LOW	Good practices, proper parameterization
Input Validation	LOW	Proper validation implemented
Overall Risk	HIGH	Primarily due to git history exposure

---

🔍 TESTING METHODOLOGY

The following security testing methods were employed:

1. Pattern Matching

   • Searched for common secret patterns (API keys, tokens, passwords)
   • Regex-based detection of credentials

2. Code Review

   • Manual review of authentication logic
   • Analysis of file handling and permissions
   • SQL query examination

3. Git History Analysis

   • Checked for committed secrets and sensitive files
   • Analyzed file permissions in working directory

4. Dependency Analysis

   • Reviewed external dependencies
   • No known vulnerable dependencies detected

5. Static Analysis

   • Pattern detection for common vulnerabilities
   • Path traversal, command injection, SQL injection checks

---

📞 NEXT STEPS

1. Immediate: Address all critical issues before public release
2. Review: Have another developer review the remediation changes
3. Test: Verify fixes don't break existing functionality
4. Document: Update README with security best practices
5. Monitor: Set up security scanning in CI/CD pipeline

---

🔐 COMPLIANCE & BEST PRACTICES

This review considered:

• OWASP Top 10 vulnerabilities
• CWE (Common Weakness Enumeration) database
• Go security best practices
• GitHub security recommendations

Conclusion: The codebase demonstrates good security awareness with proper SQL parameterization, input validation, and secure file handling. The primary security concerns are operational (git hygiene) rather than code-level vulnerabilities. Addressing the critical issues will significantly improve the security posture of this project.