Add EfCore.TamperEvident to Security section - #923
Conversation
Added EfCore.TamperEvident library for audit logging.
📝 WalkthroughWalkthroughThis PR adds a single entry to the Security section of README.md, documenting the EfCore.TamperEvident library—a zero-trust, tamper-evident audit logging library for EF Core that employs cryptographic hash chaining and SMTP anchoring for security. ChangesSecurity Documentation Update
🎯 1 (Trivial) | ⏱️ ~2 minutes
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment Warning |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@README.md`:
- Line 699: The README entry for "EfCore.TamperEvident" should be removed or
replaced with evidence of maturity: either delete the "*
[EfCore.TamperEvident](https://github.com/furkiak/EfCore.TamperEvident) ..."
line, or update it to include links/badges proving test coverage and adoption
(e.g., CI badge, coverage badge, link to a tests directory and representative
test files, NuGet download/stats and community links); reference the repository
by name "EfCore.TamperEvident" in your change so reviewers can verify the added
test/CI artifacts and community metrics before re-inclusion.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
|
|
||
| ### Security | ||
| * [aspnetcore-security-headers](https://github.com/juunas11/aspnetcore-security-headers) - Middleware for adding security headers to an ASP.NET Core application. | ||
| * [EfCore.TamperEvident](https://github.com/furkiak/EfCore.TamperEvident) - A zero-trust, tamper-evident audit logging library for EF Core using cryptographic hash chaining and SMTP anchoring to detect database tampering. |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify the repository exists and check basic quality metrics
# Check if repository exists and is accessible
echo "=== Repository Check ==="
gh repo view furkiak/EfCore.TamperEvident --json name,description,createdAt,updatedAt,stargazerCount,forkCount,isArchived,isEmpty 2>&1
# Check for README/documentation
echo -e "\n=== Documentation Check ==="
gh api repos/furkiak/EfCore.TamperEvident/readme --jq '.name' 2>&1 || echo "No README found"
# Check recent activity
echo -e "\n=== Recent Activity ==="
gh api repos/furkiak/EfCore.TamperEvident/commits --jq '.[0:3] | .[] | {date: .commit.author.date, message: .commit.message}' 2>&1
# Check for test files
echo -e "\n=== Test Files Check ==="
gh api repos/furkiak/EfCore.TamperEvident/contents --jq '.[] | select(.name | test("test|spec"; "i")) | .name' 2>&1 || echo "No obvious test directories found in root"
# Check for NuGet package
echo -e "\n=== NuGet Package Check ==="
curl -s "https://api.nuget.org/v3-flatcontainer/efcore.tamperevident/index.json" | jq -r '.versions[-1] // "Package not found on NuGet"' 2>&1Repository: thangchung/awesome-dotnet-core
Length of output: 936
🌐 Web query:
EfCore.TamperEvident .NET security library reviews adoption
💡 Result:
As of May 17, 2026, there is no widely recognized or standard.NET library named EfCore.TamperEvident. The term appears to refer to a specific architectural concept or a custom, niche implementation rather than a mainstream, publicly adopted NuGet package [1]. Recent technical discussions in the.NET ecosystem highlight that developers seeking tamper-evident audit trails in Entity Framework Core (EF Core) typically implement custom solutions using cryptographic hash chains [1]. These custom implementations often leverage EF Core's SaveChangesInterceptor to capture entity states and generate SHA-256 hashes that link transactions, ensuring that any unauthorized modification to historical audit logs breaks the chain [1]. For general auditing and change tracking in EF Core, the community and industry standard remains Audit.NET, which is widely used for its broad feature set and integration capabilities [2][3]. While Audit.NET is suitable for most standard auditing needs, experts note that it may not meet the strict requirements for immutable, tamper-evident logs [2]. Consequently, teams with high-compliance or zero-trust requirements often opt for custom-built interceptors or database-level features like SQL Server Temporal Tables, rather than relying on a single third-party library [4][5][2][6].
Citations:
- 1: https://dev.to/furkiak/building-a-zero-trust-tamper-evident-audit-trail-in-ef-core-and-why-standard-logs-fail-20om
- 2: https://developersvoice.com/blog/database/efcore_audit_implementation_guide/
- 3: https://blog.rufer.be/2025/12/29/howto-implement-audit-logging-in-a-net-core-application-using-entity-framework-core-and-audit-net/
- 4: https://github.com/ramazan-gunes/EFCore9TemporalTable
- 5: https://bytecrafted.dev/ef-core-saas-audit-logging-savechanges-interceptors/
- 6: https://www.linkedin.com/pulse/history-changes-made-simple-entity-framework-core-features-%C4%87osi%C4%87-efnxf
Remove library or provide evidence of test coverage and active community adoption.
Repository exists with documentation and a NuGet package, but lacks critical maturity indicators for inclusion in a curated awesome list:
- No test coverage: Repository contains no test directories or test files, critical for any security library
- Zero community adoption: 0 stars, 0 forks, newly created on 2026-05-17
- Brand new: Initial NuGet release (1.0.0) with only 3 commits, all on creation day
- Not recognized in ecosystem: Web search indicates EfCore.TamperEvident is not widely adopted; mainstream alternative remains Audit.NET
For security libraries especially, the awesome list should prioritize established solutions with proven reliability, test coverage, and community validation. Consider waiting for this library to gain traction, demonstrate test coverage, and receive community review before inclusion.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@README.md` at line 699, The README entry for "EfCore.TamperEvident" should be
removed or replaced with evidence of maturity: either delete the "*
[EfCore.TamperEvident](https://github.com/furkiak/EfCore.TamperEvident) ..."
line, or update it to include links/badges proving test coverage and adoption
(e.g., CI badge, coverage badge, link to a tests directory and representative
test files, NuGet download/stats and community links); reference the repository
by name "EfCore.TamperEvident" in your change so reviewers can verify the added
test/CI artifacts and community metrics before re-inclusion.
There was a problem hiding this comment.
Thank you for the review. I understand the concerns regarding the library being new. To address the testing requirements, I have just added comprehensive unit tests to the repository ( (https://github.com/furkiak/EfCore.TamperEvident/tree/main/EfCore.TamperEvident.Tests). While the project is newly released, it solves a critical architecture gap in EF Core auditing. I am actively working on building its community adoption.
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify the test files have been added and check current repo metrics
echo "=== Repository Metrics ==="
gh repo view furkiak/EfCore.TamperEvident --json name,description,stargazerCount,forkCount,createdAt,updatedAt 2>&1
echo -e "\n=== Test Directory Contents ==="
gh api repos/furkiak/EfCore.TamperEvident/contents/EfCore.TamperEvident.Tests --jq '.[] | {name: .name, type: .type}' 2>&1
echo -e "\n=== Recent Commits ==="
gh api repos/furkiak/EfCore.TamperEvident/commits --jq '.[0:5] | .[] | {date: .commit.author.date, message: .commit.message}' 2>&1
echo -e "\n=== NuGet Stats ==="
curl -s "https://api.nuget.org/v3/registration5-semver1/efcore.tamperevident/index.json" | python3 -c "
import json, sys
data = json.load(sys.stdin)
items = data.get('items', [])
if items:
for page in items:
for entry in page.get('items', []):
print('Version:', entry.get('catalogEntry', {}).get('version'), 'Published:', entry.get('catalogEntry', {}).get('published'))
else:
print('No entries found')
" 2>&1
Length of output: 1227
🏁 Script executed:
#!/bin/bash
echo "=== AuditVerifierTests.cs ==="
gh api repos/furkiak/EfCore.TamperEvident/contents/EfCore.TamperEvident.Tests/AuditVerifierTests.cs --jq '.content' | base64 -d 2>&1
echo -e "\n=== SecurityHelperTests.cs ==="
gh api repos/furkiak/EfCore.TamperEvident/contents/EfCore.TamperEvident.Tests/SecurityHelperTests.cs --jq '.content' | base64 -d 2>&1
Length of output: 7031
@furkiak, thank you for the quick follow-up — I've verified the test additions.
What looks good now:
- ✅
AuditVerifierTests.cscovers the two most critical scenarios: valid hash chain passes and a broken chain is correctly detected - ✅
SecurityHelperTests.csvalidates hash determinism, key sensitivity, and dictionary serialization ordering - ✅ Tests follow proper Arrange/Act/Assert structure using xUnit with an in-memory EF Core database
- ✅ NuGet updated to v1.0.1 on the same day
Remaining concerns for the maintainer's consideration:
The tests address the coverage gap I raised, which is a meaningful step. However, for inclusion in a curated "awesome" list, a few maturity signals are still worth noting:
- Community adoption — The repo currently has 0 stars and 0 forks. Awesome lists typically reflect community-validated libraries, not just newly published ones.
- CI/CD pipeline — There's no visible CI badge or GitHub Actions workflow running the tests on push, which is standard practice for security libraries.
- Age — All activity (creation, tests, NuGet publish) occurred on the same day (2026-05-17), making it difficult for reviewers to assess real-world reliability.
A suggested path forward would be to add a GitHub Actions CI workflow to prove tests pass automatically, and revisit this PR once the library has gathered some community traction (stars, issues, external users). The final inclusion decision, of course, rests with the repository maintainer.
(◕‿◕✿) 🐇 — good progress on the tests!
There was a problem hiding this comment.
Following up on the previous feedback, I have successfully added a GitHub Actions CI workflow to automatically build the project and run the unit tests. The pipeline is now fully active, and all checks are passing completely green.
https://github.com/furkiak/EfCore.TamperEvident/actions/runs/26022300709
Thank you again for the constructive guidance on improving the repository's maturity. I will continue working on building community adoption and addressing the compiler warnings in the meantime.
|
looks good |
2 participants
Hi! I'd like to contribute my open-source library to the Security section.
Thank you for maintaining this awesome list!
Summary by CodeRabbit