Package signing and build provenance improvements

[rajsin31415]

Hi Ulrich,

Thank you for the quick turnaround on the secure-zero fix in 2.3.3 — much appreciated.

I noticed a few supply-chain hygiene gaps that I wanted to flag. None of these are vulnerabilities, and I found no malicious payload — this is about making the packages easier for downstream consumers to verify.

1. Unsigned artifacts

The shipped sqlite3mc.dll (win-x64), SQLite3MC.PCLRaw.provider.dll, and SQLitePCLRaw.batteries_v2.dll are all Authenticode NotSigned. For a crypto-focused library, code signing would meaningfully improve tamper detectability for consumers who verify package contents after install.

2. Floating branch reference for native binaries

The GitHub Actions packaging workflows (publish.yml, dotnet.yml) check out utelle/SQLite3MultipleCiphers-cb at ref sqlite3mc — a branch name rather than a pinned commit SHA. The lib .csproj then packs binaries straight from ..\cb\bld\bin. If the sqlite3mc branch were compromised or force-pushed, a subsequent NuGet publish would silently pick up altered binaries.

Pinning to a specific commit SHA (or a signed tag) in the checkout step would close this gap.

3. Reproducibility / hash manifest

Publishing SHA256 hashes of the native artifacts alongside each NuGet release (e.g. in the GitHub release notes) would let consumers independently verify that the DLLs in their local NuGet cache match what was packaged. This is low effort and helps even without full reproducible builds.

Happy to discuss any of these further. Thanks for maintaining this package family.

[utelle]

I noticed a few supply-chain hygiene gaps that I wanted to flag. None of these are vulnerabilities, and I found no malicious payload — this is about making the packages easier for downstream consumers to verify.

Thanks for your comments. Of course, I'd love to make the SQLite3MC packages as user-friendly and trustworthy as possible. And if we can find practical ways to meet these requirements, I will be happy to implement them.

1. Unsigned artifacts

The shipped sqlite3mc.dll (win-x64), SQLite3MC.PCLRaw.provider.dll, and SQLitePCLRaw.batteries_v2.dll are all Authenticode NotSigned. For a crypto-focused library, code signing would meaningfully improve tamper detectability for consumers who verify package contents after install.

I fully agree. However, Authenticode certificates are not available for free. And even if they were, it is almost impossible to issue one for an individual developer like myself. Several years ago I really tried hard to get a code signing certificate - I even had a notary involved -, but in the end I had to gave up, because it turned out to be impossible to fulfill all requiremenst of the Certificate Authority.

2. Floating branch reference for native binaries

The GitHub Actions packaging workflows (publish.yml, dotnet.yml) check out utelle/SQLite3MultipleCiphers-cb at ref sqlite3mc — a branch name rather than a pinned commit SHA. The lib .csproj then packs binaries straight from ..\cb\bld\bin. If the sqlite3mc branch were compromised or force-pushed, a subsequent NuGet publish would silently pick up altered binaries.

Pinning to a specific commit SHA (or a signed tag) in the checkout step would close this gap.

Yes, I agree this process can certainly be improved, so that potential version mismatches can be avoided.

3. Reproducibility / hash manifest

Publishing SHA256 hashes of the native artifacts alongside each NuGet release (e.g. in the GitHub release notes) would let consumers independently verify that the DLLs in their local NuGet cache match what was packaged. This is low effort and helps even without full reproducible builds.

This would have to be integrated into the current GitHub release Workflow.

[utelle]

2. Floating branch reference for native binaries

The GitHub Actions packaging workflows (publish.yml, dotnet.yml) check out utelle/SQLite3MultipleCiphers-cb at ref sqlite3mc — a branch name rather than a pinned commit SHA. The lib .csproj then packs binaries straight from ..\cb\bld\bin. If the sqlite3mc branch were compromised or force-pushed, a subsequent NuGet publish would silently pick up altered binaries.
Pinning to a specific commit SHA (or a signed tag) in the checkout step would close this gap.

In the meantime I have reworked the GitHub actions of SQLite3MultipleCiphers-cb, so that the binaries are no longer stored in the repository itself. Instead a release is created automatically - including a file with a list of SHA256 hashes for the individual binary files.

The release artifacts are then use to build and test the actual NuGet package in SQLite3MultipleCiphers-NuGet.

I haven't yet adjusted the action which publishes the NuGet packages. The question is how the SHA256 hashes should be included in the NuGet packages, or where else this information should be published.

[utelle]

I haven't yet adjusted the action which publishes the NuGet packages.

This task is now completed. That is, the binaries are now built and published as a GitHub release in repository SQLite3MultipleCiphers-cb including a manifest file and a checksum file (see example here). And the Build&Publish workflow in this repository now consumes that release. The consistency of the binary release is checked. And GitHub attestation will be added for future NuGet releases.

@rajsin31415: Please let me know what you think of this approach and whether it achieves the desired improvements. TIA.

[rajsin31415]

Thanks, this is very helpful.