mars/openssl VERSION files state 1.0.2k and 1.1.1c, but all seven prebuilt binaries are OpenSSL 1.1.1l

Hello, and thank you for mars.

I tried TSRC first, but its submission form requires a QQ or WeChat account I do not have. Nothing below is undisclosed — the versions are all readable in this repository — so I am raising it here rather than leaving it unsent. Happy to move it to a private channel if you would rather; just tell me where.

I have put two things in one issue to save you a second thread. The first is the one I think matters.

1. The VERSION files do not match the binaries they describe

mars/openssl/ ships prebuilt OpenSSL for seven platform/ABI combinations — iOS, watchOS, macOS, Linux x64, Android (armeabi-v7a, arm64-v8a, x86, x86_64) and Windows (x86, x64).

Two plain-text VERSION files sit beside them, and they are the only human-readable statement of what those binaries are:

mars/openssl/openssl_lib_iOS/VERSION      ->  OpenSSL 1.0.2k
mars/openssl/openssl_lib_windows/VERSION  ->  OpenSSL 1.1.1c

Reading the version constant out of the binaries themselves gives a different — and consistent — answer:

iOS · watchOS · macOS · Linux x64 · Android (arm64-v8a, armeabi-v7a) · Windows x64
      ->  OpenSSL 1.1.1l  24 Aug 2021

All seven are 1.1.1l. Neither VERSION file is correct, and they are wrong by different amounts.

The history shows how it happened, and it is an ordinary thing to happen:

The binaries were rebuilt; the note beside them was not updated. The Windows binary's own commit message says 1.1.1l while the VERSION file in the same directory still says 1.1.1c.

Why this is the part worth fixing: a prebuilt .a/.lib is opaque to Dependabot and to every source scanner, so the VERSION file is the only thing a human auditor can consult — and it currently gives the wrong answer. Deriving it from the binary at build time would stop it drifting again.

On the version itself: OpenSSL's listing records 16 CVEs fixed after 1.1.1l, two of which OpenSSL rates High (CVE-2022-0778, fixed 1.1.1n; CVE-2023-0286, fixed 1.1.1t), plus eight Moderates. The 1.1.1 line is no longer maintained. I did not do any reachability analysis and I am not claiming any of them is exploitable in mars.

2. Vendored zstd 1.4.4 — a smaller note, and a correction to myself

mars/zstd/ is a full copied-in upstream tree. mars/zstd/lib/zstd.h declares:

#define ZSTD_VERSION_MAJOR   1
#define ZSTD_VERSION_MINOR   4
#define ZSTD_VERSION_RELEASE 4

zstd 1.4.4, from November 2019.

I want to flag something I checked and got the opposite answer to what I first assumed. The obvious advisories to reach for are CVE-2021-24031 and CVE-2021-24032, whose range ("beginning in v1.4.1 and prior to v1.4.9") contains 1.4.4 exactly. Reading them shows they concern the zstd command-line utility's output-file permissions. mars links the library, not the CLI, so they do not apply and I am not reporting them against you.

So this is only a note that the vendored codec is around six years behind upstream, with no advisory I could find that applies to it. Entirely your call whether that is worth acting on.

What I did not establish

• No exploitability, reachability or reproduction for anything above. Nothing was built or run; this is read-only inspection plus strings on the committed archives.
• I verified the OpenSSL version from the compiled-in version constant. I did not verify the build provenance of the blobs beyond that.
• I did not diff either vendored tree against upstream, so if you have backported fixes locally, the version numbers understate what you actually ship.

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 file contents, the version strings read from all seven binaries, the commit dates, and the CVE applicability check that ruled the zstd advisories out — was reproduced and verified by hand before posting.

Thank you for your time.