feat: protect against reentrancy attacks in smart contracts#421
Conversation
- Add reentrancy latch (_acquire_lock/_release_lock) to all mutative functions in contracts/src/lib.rs: create_project, batch_create_projects, fund_project, submit_work, approve_work, raise_dispute, resolve_dispute, check_deadline, set_metadata, remove_metadata, pause, unpause - Enforce checks-effects-interactions (CEI) pattern across all functions: deposited is zeroed and status committed to storage before any event emission or token transfer interaction in approve_work, resolve_dispute, and check_deadline - Add emergency circuit breaker: pause(admin) / unpause(admin) / is_paused() backed by DataKey::Paused; all mutative functions call _require_not_paused first; upgrade intentionally exempt so security patches can deploy while paused - Add nonReentrant modifier to BatchSplitter.batchTransfer (was the only EVM contract missing a reentrancy guard) - Add cross-contract reentrancy protection via shared latch that blocks all mutative entry points simultaneously - Add fuzz and invariant tests in contracts/test/foundry/ReentrancyFuzz.t.sol covering: direct reentrancy, cross-function reentrancy, read-only reentrancy, constructor reentrancy, BatchSplitter guard, forwarder nonce replay, balance invariant, no-double-payment, over-withdraw prevention - Add formal verification spec contracts/certora/specs/ReentrancySafety.spec with 10 rules: latch zero at entry/exit, latch released on revert, no direct/cross-function reentrancy, balance bounds, only-owner withdraw, platformFeeBps bounded - Expand contracts/src/security_properties.rs with 14 new proptest properties covering latch mutual-exclusion, read-only reentrancy, cross-function reentrancy, constructor reentrancy, CEI invariants, circuit-breaker state machine All 39 Rust tests pass. Solidity files compile clean.
|
@od-hunter is attempting to deploy a commit to the smartdevs17's projects Team on Vercel. A member of the Team first needs to authorize it. |
|
@od-hunter Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits. You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀 |
|
| GitGuardian id | GitGuardian status | Secret | Commit | Filename | |
|---|---|---|---|---|---|
| 15742864 | Triggered | Generic Password | 059aaa6 | .devcontainer/docker-compose.yml | 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.
2 participants
Closes #397
#397