Repository navigation
Fix #17: Add hardening check: security hardening flags are enabled - #42
Conversation
… options There was no check that projects enable security hardening. The new `hardening` check scans CMake files, CI configuration and CMake presets for _FORTIFY_SOURCE, -fstack-protector-strong, -fcf-protection, -fstack-clash-protection and _GLIBCXX_ASSERTIONS/_LIBCPP_HARDENING_MODE (and, when MSVC is in CI, /sdl /guard:cf /DYNAMICBASE /CETCOMPAT), ignoring disabled spellings. GCC's -fhardened satisfies the GCC/Clang set, but warns when Clang is in CI since it is GCC-only; it passes, warns listing missing options, or fails when none are found. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #42 +/- ##
==========================================
+ Coverage 97.25% 97.39% +0.14%
==========================================
Files 32 33 +1
Lines 1202 1269 +67
Branches 99 104 +5
==========================================
+ Hits 1169 1236 +67
Misses 28 28
Partials 5 5 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
@leftibot update and resolve merge conflicts, get tests up to current standards. Look into additional hardening options that might exist for other programming languages, and enhance tests as necessary. |
|
|
|
✅ leftibot finished addressing the review feedback. |
Requested by @lefticus in PR cpp-best-practices#42 review. Resolves the conflicts with main: the hardening tests move out of the deleted tests/test_checks.py into tests/checks/test_hardening.py, written to the current standard (every C/C++ layout and CI provider, exact results). The check now declares the C/C++ languages and is judged per ecosystem. found_and_missing() moves into project_validator.text so that hardening and compiler-warnings no longer duplicate it (jscpd runs with a zero threshold). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…g check Requested by @lefticus in PR cpp-best-practices#42 review. Python and Rust projects are now judged on their own hardening options rather than C/C++ compiler flags: - Python: security lints (bandit, as a command, pre-commit hook or action, or ruff selecting the flake8-bandit S rules) and hash-checked dependencies (pip --require-hashes, pip-compile --generate-hashes, uv sync --locked or --frozen). - Rust: unsafe_code forbidden or denied crate-wide (Cargo [lints.rust], #![forbid(unsafe_code)] in a crate root, or -F/-D unsafe_code rustflags) and overflow-checks enabled for release builds ([profile.release] or -C overflow-checks). Module-level lints and dev-profile overflow checks, which are on by default, do not count. The well-configured Python and Rust fixtures enable these, so they still pass --strict, and the mixed-language CLI test now covers hardening too. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Addressed review feedback from @lefticus. New commits: |
|
@leftibot resolve merge conflicts |
|
@leftibot get this project passing its own tests for hardening |
|
✅ leftibot finished addressing the review feedback. |
…ion passes hardening The hardening check failed on project_validator itself because no Python security linting was enabled. Add ruff's flake8-bandit rules (S) to the lint selection and suppress its two false positives inline (the PASS status label and the shell-free subprocess argv in ctest_runs). Self-validation now exits 0; hardening reports WARN for the remaining hash-checked dependencies option, which would need CI install steps changed to --require-hashes. CI config is out of scope for this run, so that is left for a follow-up. Requested by @lefticus in PR cpp-best-practices#42 review. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Addressed review feedback from @lefticus. New commits: |
|
@leftibot fix the merge conflicts |
|
✅ leftibot finished addressing the review feedback. |
Resolved the conflict in the well_configured_python CI fixture by keeping the hash-pinned install and bandit step from this branch alongside the lizard function-limits step from main. Requested by @lefticus in PR cpp-best-practices#42 review. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Addressed review feedback from @lefticus. New commits: |
Nothing checked that projects enable security hardening. The new `hardening` check judges each ecosystem by its own options, ignoring disabled spellings, and passes, warns listing missing options, or fails when none are found: - C/C++: _FORTIFY_SOURCE, -fstack-protector-strong, -fcf-protection, -fstack-clash-protection and _GLIBCXX_ASSERTIONS or _LIBCPP_HARDENING_MODE, plus /sdl /guard:cf /DYNAMICBASE /CETCOMPAT when MSVC is in CI. GCC's -fhardened satisfies the GCC/Clang set but warns when Clang is in CI, since it is GCC-only. - Python: security lints (bandit as a command, pre-commit hook or action, or ruff selecting the S rules) and hash-checked dependencies (pip --require-hashes, pip-compile --generate-hashes, uv sync --locked or --frozen). - Rust: unsafe_code forbidden or denied crate-wide and overflow-checks enabled for release builds. The well-configured Python and Rust fixtures enable these options. This project enables ruff's flake8-bandit (S) rules, suppressing two false positives inline; hardening still warns about hash-checked dependencies, which needs CI install steps changed. Closes: #17 Refs: #42 Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Automated fix by @leftibot.
What changed
Files
Closes #17
Triggered by @lefticus.