docs 📝: Comment out allowlist rule for badge URLs in README #16
Reference in New Issue
Block a user
Delete Branch "dev"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Updated the README to comment out the allowlist rule for badge URLs, as it is no longer necessary.
handle_failuresto run regardless of previous job resultsReview Summary
pr-check-yaml. The deleted workflow appears to be a series of jobs and steps for performing checks such as linting, leak testing, and handling success or failure scenarios. As the file has been removed, it is not possible to perform a detailed review according to the provided guidelines. However, some potential issues that may have existed in the original workflow are: 1. Security (Score: 4): Thegitleakscommand used for leak testing was run without any specific configuration or sensitive data filtering, which could potentially expose secret keys, credentials, or other sensitive information found within the codebase. 2. Performance (Score: 3): The use ofgitleaksmight have a performance impact on the workflow due to its thorough scanning of the repository for secrets. 3. Maintainability (Score: 3): Hardcoding the GitHub API endpoint, GIT_SERVER_URL, and GITEA_TOKEN as secrets in the workflow file makes it less flexible and harder to manage when changes are required. It's generally a good practice to use environment variables or secure secrets stored in a centralized location for such configurations. Without the actual contents of the file, I cannot provide specific line comments or LGTM status. However, I strongly recommend reviewing the reasons mentioned above and ensuring that proper configuration and security measures are implemented if similar workflows are being used..gitea/workflows/pr-check.yaml) that performs various checks on pull requests, including leak tests and linting. The code looks good with no issues scoring >= 2, so here's the summary: LGTM This workflow will help ensure that pull requests are thoroughly checked for potential security leaks, coding style issues, and syntax errors before they are merged into the main branch. This promotes a higher standard of code quality and reduces the risk of introducing vulnerabilities or code inconsistencies in the project.diff File: b/.gitleaks.toml Context: Line 1: + title = "Gitleaks Config" Line 2: + Line 3: +# ========================== Line 4: +# Allowlist / False Positive Rules Line 5: +# ========================== Line 6: +# [[allowlist]] Line 7: +# description = "Ignore placeholder secrets in README.md" Line 8: +# filepath = "README.md" Line 9: +# # Add all placeholder-like patterns that trigger false positives Line 10: +# regex = "cafebabe|deadbeef|DB_PASSWORD" Line 11: + Line 12: +# [[allowlist]] Line 13: +# description = "Ignore badge URLs in README" Line 14: +# filepath = "README.md" Line 15: +# regex = "https://img.shields.io" Line 16: + Line 17: +# ========================== Line 18: +# Rules Line 19: +# ========================== Line 20: +[[rules]] Line 21: +id = "generic-api-key" Line 22: +description = "Generic API Key" Line 23: +regex = "(?i)(api[_-]?key|secret|token)=\\S+" Line 24: +entropy = 3.5 Line 25: + Line 26: +[[rules]] Line 27: +id = "sidekiq-secret" Line 28: +description = "Sidekiq Secret" Line 29: +regex = "export BUNDLE_ENTERPRISE__CONTRIBSYS__COM=\\S+" Line 30: +entropy = 2.5 LGTM❌ CI checks failed.
Leak: failure
Lint: success
Pull request closed