Run SQLite3MC's and SQLite's tests on the shipped amalgamation, plain and under sanitizers - #11
Conversation
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configurationConfiguration used: Repository: LucaCappelletti94/coderabbit/.coderabbit.yaml Review profile: ASSERTIVE Plan: Advanced Run ID:
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 |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #11 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 1 1
Lines 3 3
Branches 3 3
=========================================
Hits 3 3 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
… and under sanitizers
d4cbd8a to
639e332
Compare
|
1 participant
Until now CI compiled the amalgamation and ran one query, so a release that broke rekeying or a non-default cipher, or wrote one byte past a buffer, would still have passed. Two new jobs build SQLite3MC's shell and SQLite's testfixture from the shipped bytes and run SQLite3MC's own scripts and legacy SQLCipher databases, a rekey of every built-in cipher, and SQLite's veryquick suite. One job builds plainly and the other under ASAN and UBSan, where any report fails it. Upstream's CI only runs its scripts, so here their results are compared against a committed expectation. A wrong row fails the plain job, and a planted one-byte overflow fails the sanitizer job at its line.
SQLite's suite needs internal symbols exported, and SQLite3MC declares one function private but defines it static, so the build fails. The runner changes that single word in a scratch copy and stops once a release fixes it (utelle/SQLite3MultipleCiphers#276). The suite also found two NULL dereferences when an allocation fails during initialisation or opening, fixed on a separate upstream branch, and a dropped read error already fixed upstream after 2.5.1. They are named as expected crashes and failures, and each one fails the job once it starts passing, so the list cannot go stale.
Nothing new is pinned. The shell comes from the release archive checked against the signed checksums, the test files from the tag at the commit named in that signature's certificate, and the SQLite sources from the check-in hash the amalgamation itself carries.