Fix/security patches #13
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add permalink frontmatter to all example documentation pages to fix Jekyll routing issues where pages were accessible at incorrect URLs. Changes: - Add permalink: /examples/clusters/ to clusters.md - Add permalink: /examples/discovery/ to discovery.md - Add permalink: /examples/users/ to users.md - Add permalink: /examples/roles/ to roles.md - Add permalink: /examples/network/ to network.md - Add permalink: /examples/infrastructure/ to infrastructure.md - Add permalink: /examples/dag-analysis/ to dag-analysis.md Fixes issue where clicking "Cluster Examples" from home page resulted in 404 error instead of navigating to correct URL.
Replace references to non-existent /examples/advanced/ page with appropriate existing documentation pages. Changes: - Update examples.md: Change "Search & VPC" section to link to "DAG Analysis" examples instead - Update network.md: Change VPC Endpoints link to point to YAML Kinds Reference documentation The /examples/advanced/ page never existed, causing 404 errors for users clicking these links.
Add missing relative_url filter to internal documentation links to ensure correct URL generation when site is deployed to subdirectory. Changes: - infra.md: Fix 4 links to /discovery/ and /dag-engine/ - dag-engine.md: Fix 3 links in Further Reading section - atlas.md: Fix link to /infra/ - database.md: Fix link to /atlas/ - examples/dag-analysis.md: Fix links in Further Reading Without relative_url filter, links break when site is deployed at https://teabranch.github.io/matlas-cli/ (baseurl set in _config.yml).
Update links that referenced /yaml-kinds/ to use correct /reference/ permalink path, matching the actual permalink setting in yaml-kinds.md. Changes: - alerts.md: Update YAML Kinds Reference link - examples/alerts.md: Update YAML Kinds Reference link - yaml-kinds.md: Fix malformed Related Documentation links The yaml-kinds.md file has permalink: /reference/ but links were pointing to /yaml-kinds/, causing 404 errors.
Add tracking/documentation.md documenting the comprehensive documentation link fixes that resolved Jekyll routing issues.
Implement comprehensive security improvements for sensitive data handling throughout the CLI. New Modules: - internal/fileutil/secure_writer.go: Secure file operations with restrictive permissions (0600 for files, 0700 for directories) - internal/security/masking.go: Safe masking of MongoDB connection strings and credentials in logs/output Security Improvements: 1. File Operations: - Replace direct os.WriteFile with SecureFileWriter - Apply secure permissions (0600) to all sensitive files - Prevent race conditions with atomic writes - Files affected: config exports, imports, migrations 2. Credential Protection: - Block insecure credential passing via CLI flags - Users must use environment variables, config files, or keychain - Mask connection strings in logs and error messages - Prevent credential exposure in process listings 3. Logging Security: - Automatically mask sensitive data in log output - Detect and redact credentials, tokens, and connection strings - Enhanced error formatting with credential masking Modified Components: - cmd/config/config.go: Use SecureFileWriter for config operations - cmd/root.go: Block credentials via CLI flags with helpful error - internal/clients/mongodb/client.go: Mask connection strings in logs - internal/config/credentials.go: Secure credential loading - internal/logging/logger.go: Add credential masking to log output - internal/output/create_formatters.go: Mask sensitive formatter data - internal/output/formatters_extended_test.go: Test credential masking - internal/services/database/temp_user.go: Mask temp user credentials Security Rationale: - Command-line arguments are visible in process listings (ps, htop) - Arguments are stored in shell history files - File permissions prevent unauthorized access to sensitive configs - Masked logs prevent credential leakage in debugging output Refs: #security-hardening
Move regex pattern compilation from hot path to package initialization to eliminate repeated compilation overhead in logging operations. Performance Issue: - containsSecretValue() was compiling 5 regex patterns on every call - Method is called from WithFields() which is in the hot logging path - Each log call with fields triggered unnecessary regex compilation Solution: - Pre-compile all secret detection patterns as package-level variables - Patterns are compiled once at package init time - Pattern matching order optimized by likelihood for early exit Impact: - Eliminates regex compilation overhead from every log call - Improves logging performance in high-throughput scenarios - No functional changes - all tests pass Benchmarks would show significant improvement in WithFields() calls, especially when logging multiple fields per call.
|
| GitGuardian id | GitGuardian status | Secret | Commit | Filename | |
|---|---|---|---|---|---|
| 23285670 | Triggered | MongoDB Credentials | 02b6991 | internal/security/masking.go | View secret |
🛠 Guidelines to remediate hardcoded secrets
- Understand the implications of revoking this secret by investigating where it is used in your code.
- Replace and store your secret safely. Learn here the best practices.
- Revoke and rotate this secret.
- If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.
To avoid such incidents in the future consider
- following these best practices for managing and storing secrets including API keys and other credentials
- install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.
🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.
d-teller
pushed a commit
that referenced
this pull request
Dec 11, 2025
…d releases Add comprehensive documentation and templates to enforce squash merge workflow and conventional commits, fixing semantic-release integration. Changes: - Add .github/pull_request_template.md: Guide contributors to provide conventional commit message in PR description for squash merge - Add .github/CONTRIBUTING.md: Complete contributing guide covering development setup, PR process, conventional commits, code style, testing, and feature development workflow - Add .github/SQUASH_MERGE.md: Repository configuration instructions for maintainers to enable squash merge only via GitHub settings or CLI - Update README.md: Add contributing section linking to new documentation and emphasizing squash merge requirement - Update tracking/documentation.md: Document this configuration work Problem Solved: Previous PR #13 merge commit "Fix/security patches (#13)" didn't follow conventional commit format, causing semantic-release to skip release. Squash merge ensures single commit per PR with proper format. Benefits: - Clean git history (one commit per feature/fix) - Automatic semantic versioning from commit messages - Proper changelog generation via semantic-release - Easy rollbacks with single commit per feature - Consistent commit format enforcement Configuration Required: Repository maintainer must configure GitHub settings to disable merge commits and rebase merging, enable squash merge only. Instructions provided in .github/SQUASH_MERGE.md. Refs: #13
d-teller
added a commit
that referenced
this pull request
Dec 11, 2025
…d releases (#14) Add comprehensive documentation and templates to enforce squash merge workflow and conventional commits, fixing semantic-release integration. Changes: - Add .github/pull_request_template.md: Guide contributors to provide conventional commit message in PR description for squash merge - Add .github/CONTRIBUTING.md: Complete contributing guide covering development setup, PR process, conventional commits, code style, testing, and feature development workflow - Add .github/SQUASH_MERGE.md: Repository configuration instructions for maintainers to enable squash merge only via GitHub settings or CLI - Update README.md: Add contributing section linking to new documentation and emphasizing squash merge requirement - Update tracking/documentation.md: Document this configuration work Problem Solved: Previous PR #13 merge commit "Fix/security patches (#13)" didn't follow conventional commit format, causing semantic-release to skip release. Squash merge ensures single commit per PR with proper format. Benefits: - Clean git history (one commit per feature/fix) - Automatic semantic versioning from commit messages - Proper changelog generation via semantic-release - Easy rollbacks with single commit per feature - Consistent commit format enforcement Configuration Required: Repository maintainer must configure GitHub settings to disable merge commits and rebase merging, enable squash merge only. Instructions provided in .github/SQUASH_MERGE.md. Refs: #13 Co-authored-by: Danny Teller <[email protected]>
d-teller
added a commit
that referenced
this pull request
Dec 11, 2025
* docs(ci): enforce squash merge with conventional commits for automated releases Add comprehensive documentation and templates to enforce squash merge workflow and conventional commits, fixing semantic-release integration. Changes: - Add .github/pull_request_template.md: Guide contributors to provide conventional commit message in PR description for squash merge - Add .github/CONTRIBUTING.md: Complete contributing guide covering development setup, PR process, conventional commits, code style, testing, and feature development workflow - Add .github/SQUASH_MERGE.md: Repository configuration instructions for maintainers to enable squash merge only via GitHub settings or CLI - Update README.md: Add contributing section linking to new documentation and emphasizing squash merge requirement - Update tracking/documentation.md: Document this configuration work Problem Solved: Previous PR #13 merge commit "Fix/security patches (#13)" didn't follow conventional commit format, causing semantic-release to skip release. Squash merge ensures single commit per PR with proper format. Benefits: - Clean git history (one commit per feature/fix) - Automatic semantic versioning from commit messages - Proper changelog generation via semantic-release - Easy rollbacks with single commit per feature - Consistent commit format enforcement Configuration Required: Repository maintainer must configure GitHub settings to disable merge commits and rebase merging, enable squash merge only. Instructions provided in .github/SQUASH_MERGE.md. Refs: #13 * docs: add quick start guide for squash merge setup and testing --------- Co-authored-by: Danny Teller <[email protected]>
d-teller
added a commit
that referenced
this pull request
Dec 11, 2025
Add comprehensive quick-start guide for configuring GitHub squash merge and testing semantic-release integration. Files Added: - SQUASH_MERGE_SETUP.md: Step-by-step guide for repository configuration, testing workflows, and troubleshooting common issues - RELEASE_ISSUE_DIAGNOSIS.md: Detailed diagnosis of release trigger issues This complements the PR template and contributing guides added in the previous commit to provide complete squash merge documentation. Refs: #13, #14
d-teller
pushed a commit
that referenced
this pull request
Dec 11, 2025
…docs commits The presetConfig.types only controls changelog visibility (hidden property), not which commits trigger releases. Add explicit releaseRules to specify that docs, refactor, perf, and other types should trigger patch releases. Without releaseRules, semantic-release uses default rules which only trigger releases for feat (minor) and fix (patch) commits. This caused docs commits to be ignored for release purposes despite being properly formatted. Refs: #13, #14
d-teller
pushed a commit
that referenced
this pull request
Dec 11, 2025
…types The previous configuration was missing: 1. Security commit type (used in security-patches PR #13) 2. Explicit release: false rules for non-releasing types 3. Complete releaseRules defining what triggers releases Changes: - Add 'security' type triggering patch releases - Add explicit release: false for chore, test, build, ci, style - Update PR template to include security type option - Update CONTRIBUTING.md with security type documentation - Add security section to changelog types This ensures semantic-release properly handles ALL conventional commit types and makes release behavior explicit and predictable. The security-patches PR (#13) contained security, perf, and docs commits that should have triggered a release but didn't because: 1. Merge commit format was wrong (Fix/security patches) 2. No explicit releaseRules defined what triggers releases Refs: #13, #14
d-teller
pushed a commit
that referenced
this pull request
Dec 11, 2025
Add detailed documentation of root cause analysis and solution for semantic-release not triggering releases. Files Added: - RELEASE_FIX_SUMMARY.md: Complete explanation of why releases weren't triggering and how it was fixed with explicit releaseRules Files Updated: - tracking/documentation.md: Document the semantic-release configuration fix work including root cause, solution, and impact Key finding: presetConfig.types only controls changelog visibility (hidden property), not what triggers releases. Explicit releaseRules are required to make docs, security, perf, and refactor commits trigger releases. This documents the solution to issues where properly formatted conventional commits were being ignored by semantic-release. Refs: #13, #14
|
🎉 This PR is included in version 4.0.1 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.