Repository navigation
HTTPS everywhere via static BoringSSL (one cpp-httplib copy), dockcross images by digest (PR B) - #497
Merged
Merged
Conversation
…copy jllama compiled httplib.cpp itself, without SSL, next to the SSL-enabled copy upstream's llama-common links for downloads. Which copy the linker took decided per platform: Linux jars had no HTTPS at all (an https:// download threw), the macOS dylib depended on Homebrew's openssl@3. Now jllama and jllama_test link upstream's cpp-httplib target, LLAMA_BUILD_BORINGSSL is on for Linux x86-64/aarch64, macOS and Windows (Android and s390x: LLAMA_OPENSSL off), the two Homebrew allowlist lines are gone and crypt32.dll is allowed on Windows. The fat-jar smokes and the macOS smoke gain an HTTPS round: a server behind a self-signed certificate serving a model it downloaded from an https:// URL with the OS certificate store. Verified locally on Linux x86-64: no new NEEDED entry, 603/603 ctest, the Java suite green, TLS 1.3 served and plain HTTP refused on the TLS port, a download refused with an untrusted certificate and completed with SSL_CERT_FILE. macOS and Windows are verified by CI (verify-native-deps, the smokes). Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AytmJF9faEiQEVt6eetQS2
The manifest digests Docker Hub serves for tag 20260712-79e54f9 (the image the wrappers already used), like the manylinux aarch64 image; the wrappers stay dockcross's generated output except for that one line. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AytmJF9faEiQEVt6eetQS2
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AytmJF9faEiQEVt6eetQS2
icx/icpx report the compiler id IntelLLVM, which BoringSSL's CMake treats as neither GCC nor Clang; the jars are build-only in CI, so a BoringSSL problem there could not be told apart from a real one. Windows SYCL keeps BoringSSL, as it had before. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AytmJF9faEiQEVt6eetQS2
bernardladenthin
had a problem deploying
to
maven-central
October 9, 2026 20:15 — with 
GitHub Actions
Failure
GitHub Actions
Failure
bernardladenthin
had a problem deploying
to
maven-central
October 9, 2026 20:15 — with
GitHub Actions
Failure
GitHub Actions
Failure
|
This was referenced Oct 9, 2026
Merged
vaiju1981
pushed a commit
to vaiju1981/java-llama.cpp
that referenced
this pull request
Oct 12, 2026
…ions about this machine The B2 block asked the local agent to discover seven things about the Windows CPU variants. Four of them were measured on that same workstation on 2026-10-09, so each item now says MEASURED or OPEN with the numbers, and the header says so too. Verifying a MEASURED line is still worth the minute it costs -- a different result there is a finding -- but the time belongs to the open ones. Measured, now stated: plain clang 23.1.3 builds all 14 variants with 0 errors; the directory holds 18 DLLs with nothing left in a Release/ subdirectory and jllama-files.txt naming 15 of them; verify-native-deps.py reports 18 libraries and 0 violations. Two assumptions in the draft do not hold on this machine, and both would have cost the local agent time: PATH carries clang 23.1.3, not 20.1.8, and Visual Studio ships no clang here at all (neither 2022\Community nor 18\BuildTools has VC\Tools\Llvm\x64) -- so the "newer versus older clang" choice the prompt set up does not exist; the 20.1.8 of the earlier comparison was unpacked separately. And jllama-extras.txt is ABSENT locally by design: CMake never writes it, merge-native-artifacts.sh derives it in CI from everything jllama-files.txt does not name. Asking "whether it exists" invites a false defect report, so the item now says what its absence means. Two things added that the measurements make useful rather than obvious. The Java suite is marked as the item that decides whether the variant path works at all, with the reason it is open: the measuring session's `mvn compile` dies in an Error Prone / NullAway crash on args/package-info.java, unrelated to the native work, and disabling annotation processing then breaks Lombok. And the variant-selection step carries a caveat before the agent spends time on it -- CLAUDE.md records that ggml logs module decisions at GGML_LOG_DEBUG only, so `-lv 4` may not name the chosen module; listing the DLLs the JVM has mapped is the fallback. The throughput item gets the static-build figures (pp512 391.6, tg128 82.3 t/s with clang and GGML_OPENMP=OFF) as the line a variant build should land near, so the number means something when it arrives. Committed on a branch off main rather than onto claude/hopeful-pascal-9jlbqb: that branch carries an unrelated open PR (bernardladenthin#497, BoringSSL), and this file already lives on main, so it reaches the session branch on its next merge without mixing concerns into someone else's review. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01E2h8gXyyE5UeimkL9vQv9G
This branch had an error being deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
jllamacompiledhttplib.cppitself without SSL, next to the SSL-enabled copy upstream'sllama-common(the download code) links. On Linux our copy won andlibsslwas never linked, so--model-url https://…/-hfthrew "HTTPS is not supported" in every Linux jar ever shipped; on macOS the archive member was pulled and the dylib depended on/opt/homebrew/opt/openssl@3(the known-defect allowlist entry). Fix:jllamaandjllama_testlink upstream'scpp-httplibtarget (one copy,CPPHTTPLIB_OPENSSL_SUPPORTas its PUBLIC define), andLLAMA_BUILD_BORINGSSL=ONon Linux x86-64/aarch64, macOS and Windows (where it already was), as upstream's release builds do. Android, s390x and the Linux SYCL jars stay without SSL (LLAMA_OPENSSL=OFF, as upstream'subuntu-24-sycl). The two Homebrew lines leavenativedeps.py;crypt32.dll(cpp-httplib's certificate-store lookup, an OS component) joins the Windows allowlist. The embedded server's--ssl-key-file/--ssl-cert-filework as a result. New CLAUDE.md section "HTTPS: BoringSSL, statically"; TODO entry closed.smoke-test-fatjar.sh/.ps1(all four fat-jar rows) andsmoke-native-macos.shgain a second round: the server behind a self-signed certificate (plain HTTP on the TLS port must be refused) serving a model it downloaded itself from thehttps://URL of the 1 MBstories260K.ggufwith the OS certificate store. That download is the end-to-end client test no local check can give, and the macOS one is the only check that can see the Homebrew defect (the runner has the formula). Learned on the way and now in the scripts:--model-urlalone starts the server in router mode (is_router_serverlooks atmodel.path/hf_repo/docker_repobefore the URL is resolved), so the smokes name the target with-mtoo.20260712-79e54f9), like the manylinux aarch64 image; the wrappers remain dockcross's generated output except for that line (REUSE note adjusted).Test plan
0.20260929.0from the GitHub mirror: fresh configure + build;ctest603/603;mvn -f llama/pom.xml test1869 run, 0 failures, 280 skipped (no models);NEEDEDlist unchanged (nolibssl/libcrypto), 56httplib::SSLClientsymbols linkedNativeServerin router mode behind a self-signed certificate answered/healthand/modelsover TLS 1.3; a plain-HTTP request on the TLS port was refused (curl exit 52)HEAD failed, status: -1, nothing written) and completed withSSL_CERT_FILEpointing at it (then failed the GGUF magic of the dummy file, as intended)bash -non both bash smokes;check-run-scripts.py,check-natives.py,check-release-gate.py,check-shared-files.py(0 changed here alone), 113 buildcheck unit tests,reuse lintcompliantverify-native-deps.pyinpackage(macOS without the Homebrew paths, Windows withcrypt32.dll, the manylinuxGLIBC_2.28ceiling with BoringSSL), and the HTTPS round ofsmoke-fatjar×4 andsmoke-fatjar-macos(first run of the PowerShell round and ofopensslon the Windows runners)Related issues / PRs
release.ymlpasses-DLLAMA_BUILD_BORINGSSL=ONformacos-cpu,windows-*,android-*and-DLLAMA_OPENSSL=OFFforubuntu-24-sycl.Checklist
CONTRIBUTING.mdandCODE_OF_CONDUCT.mdSECURITY.md)🤖 Generated with Claude Code
https://claude.ai/code/session_01AytmJF9faEiQEVt6eetQS2
Generated by Claude Code