- Add hashcat as git submodule; compile with make, skip if already in PATH
- Convert princeprocessor from tracked files to git submodule
- Change .DEFAULT_GOAL to install so plain `make` does a full install
- Install uv, Xcode CLT (macOS), build-essential (Debian) if missing
- vendor-assets falls back to system hashcat if submodule not compiled
- Remove hcatOptimizedWordlists; all attacks now use hcatWordlists
- Default hcatWordlists to ./wordlists, rules_directory to ./hashcat/rules
- Default hcatTuning to empty string (no --force --remove)
- Backfill missing config.json keys from config.json.example at startup
- Wrap hcatBin/hcatTuning/hcatWordlists loading in try/except with defaults
- Fall back to vendored hashcat binary at hate_path/hashcat/hashcat
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
hcatPath now exclusively points to the hashcat install directory and is
auto-discovered from PATH when not configured. hate_path is resolved
from the package directory (installed) or repo root (development) with
no auto-discovery. Extracted vendor-assets/clean-vendor Makefile targets
to deduplicate the install logic.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Tests now verify that hashcat-utils are loaded from hate_crack repo
even when hcatPath points to a different directory (like /opt/hashcat).
Why previous tests didn't catch this bug:
- config.json.example has hcatPath = "" (empty)
- Code has fallback: hcatPath = config.get('hcatPath', '') or hate_path
- So hcatPath accidentally defaulted to hate_path during testing
- This masked the bug where utilities incorrectly used hcatPath
Added tests that would have caught this:
- test_hashcat_utils_uses_hate_path_not_hcat_path
- test_config_with_explicit_hashcat_path
- test_readme_documents_correct_usage
Also added code comment documenting the fallback behavior.
