Android build links prebuilt OpenSSL 1.0.2k (Jan 2017) into sqlcipher, while a 1.1.1l tree in the same repo is unreferenced

Hello, and thank you for WCDB.

I tried to send this through TSRC first, but the submission form requires a QQ or WeChat account that I do not have. Since nothing here is undisclosed — the versions are readable in this repository, and #636 already states the position publicly — I am raising it as a normal issue rather than leaving it unsent. If you would prefer it moved to a private channel, tell me where and I will resend.

What I observed

tools/prebuild/openssl/ contains sixteen committed OpenSSL static libraries across five platform families. Reading the version two independent ways — the shipped headers and the binaries themselves — they agree:

The android_old headers state it plainly:

#define OPENSSL_VERSION_TEXT "OpenSSL 1.0.2k-fips  26 Jan 2017"

Which one the Android build links

I enumerated all 32 prebuild/openssl references in src/CMakeLists.txt rather than sampling. The Android branches are these six:

435:  ${TARGET_NAME} PRIVATE  .../openssl/android_old/${CMAKE_ANDROID_ARCH}/include
436:  ${TARGET_NAME} PRIVATE  .../openssl/android_old/${CMAKE_ANDROID_ARCH}/lib
437:  sqlcipher      PRIVATE  .../openssl/android_old/${CMAKE_ANDROID_ARCH}/include
438:  sqlcipher      PRIVATE  .../openssl/android_old/${CMAKE_ANDROID_ARCH}/lib
478:  sqlcipher      PUBLIC   .../openssl/android_old/${CMAKE_ANDROID_ARCH}/include
479:  sqlcipher      PUBLIC   .../openssl/android_old/${CMAKE_ANDROID_ARCH}/lib

Both the shared and the static branch select android_old, and sqlcipher is among the targets — so this is the cryptography behind encrypted databases, not a peripheral dependency.

The android/ directory holding 1.1.1l, added in March 2023, appears at none of the 32 references.

Why it may matter

OpenSSL's own listing gives the 1.0.2 series an end-of-life date of 1 January 2020 and records 45 CVEs fixed after 1.0.2k, four of which OpenSSL rates High:

Ten further Moderates are in range. For accuracy: the 1.0.2z* releases are OpenSSL's extended-support line, so most of those fixes were never freely available — the last public 1.0.2 was 1.0.2u in December 2019.

What I did NOT establish

• No exploitability or reachability analysis. I did not determine which of the 45 CVEs are reachable through WCDB's use of OpenSSL, and I am not claiming any of them is triggerable here.
• I did not confirm what your published Android artifacts contain — only which path src/CMakeLists.txt selects. Verifying a released AAR would settle that and I have not done it.
• The OpenHarmony archives gave me no version string, so I have listed them as undetermined rather than guessing.
• I did not build or run WCDB, and no database, key or credential was created or tested. This is read-only inspection.

About #636

I found #636 — "Is openssl upgraded？" — where the answer was "Not yet." in 2019, closed in 2024. I am not raising this as though it were news; the answer given then still appears to describe the Android path today. I mention it because it seemed more honest to acknowledge the question has been asked than to pretend I found something new.

Why no tooling would flag it

A committed .a file has no manifest, so Dependabot and SCA scanners have nothing to read. The one artifact a human would look for — a VERSION file — does not exist under tools/prebuild/. That is a structural blind spot rather than an oversight.

Two suggestions, one small

1. Small: record a VERSION file (or generate one at build time) for each prebuilt tree, so the shipped version is discoverable without running strings on a binary.
2. Larger, and yours to weigh: point the Android branches at the existing android/ (1.1.1l) tree if whatever required android_old no longer applies. A supported line would be better still, since 1.1.1 is also past end-of-life.

I am glad to prepare a pull request for the first if that would help.

Credit and disclosure

If this leads to a fix, I would be grateful to be credited as Kobi Hikri (GitHub @kobihikri).

For transparency: this analysis was assisted by an AI coding agent (Claude Code). Every observation — the version strings from headers and binaries, all 32 CMake references, the OpenSSL CVE list, and the #636 history — was reproduced and verified by hand before posting.

Thank you for your time.