今日已更新 374 条资讯 | 累计 23957 条内容
关于我们

标签：#Git

找到 1246 篇相关文章

AI 资讯

The .gitleaks-baseline.json That Suppressed Live Production Secrets

Originally published at woitzik.dev A previous article here covered setting up gitleaks for homelab secret scanning - the setup, the pre-commit hook, getting CI to fail on new commits that contain secrets. The setup was correct. The tool was running. The CI was green. And it had been quietly suppressing a live production credential for months. This is the follow-on story: not about getting gitleaks running, but about the specific way a baseline file breaks the guarantees you think you have once it's in place. View the complete homelab infrastructure source on GitHub 🐙 What a Baseline File Does (and Is Supposed to Do) When gitleaks first runs on an existing repo, it finds every secret-shaped string in the full git history - including secrets that were introduced years ago, rotated long since, and are completely inert. Flagging those in CI creates noise that causes developers to tune out gitleaks entirely, which is worse than not having it. The baseline workflow is the standard answer: run gitleaks on the current state, export all findings to a JSON file, commit that file to the repo, and tell gitleaks to suppress any finding that already appears in the baseline. Future commits that introduce new secrets still fail; old known-inert findings don't. # Generate baseline from current HEAD gitleaks detect --report-format json --report-path .gitleaks-baseline.json # Tell gitleaks to use it gitleaks detect --baseline-path .gitleaks-baseline.json The assumption embedded in this workflow: findings that appear in the baseline are inert. They were there before the baseline was generated; they've been there; they're known. The Assumption That Broke It The baseline was generated at a point when the repo contained Garage's rpc_secret and admin_token committed in a YAML file. Those were real production values - the cluster was live, using those exact secrets - but the baseline suppression treated them as "known, reviewed, not a problem." The commit that introduced them had happened

2026-07-13 原文 →
AI 资讯

I built Regdrift, a CLI and GitHub Action for detecting breaking CMSIS-SVD changes

Hi guys, I've been working on Regdrift, my first open-source project. It's a CLI and GitHub Action that compares two CMSIS-SVD files to check whether there are any register-map changes that could affect firmware functionality. It catches changes such as moved registers, interrupt renumbering, access changes, and altered read/write behavior. It then classifies those changes as BREAKING , WARNING , or SAFE so the tool can act as a CI gate. I'm looking for feedback from people who maintain SVDs, HALs, PACs, SDKs, or firmware repositories. If possible, I'd like to test it against real old/new SVD pairs and learn where the classifications produce false positives, miss important changes, or are unclear. For people who work frequently with CMSIS-SVD files: which types of register-map changes are most detrimental to firmware or cause the most difficult code-related problems? Resources GitHub: https://github.com/Pranav-s79/regdrift Install pip install regdrift Usage regdrift check old.svd new.svd

2026-07-13 原文 →
← 上一页 下一页 →