How to check a repo from LinkedIn before you build it

A post showed up in my LinkedIn feed: “2.11× faster than OpenCV. 575.4× faster feature matching. 96.9% fewer vision tokens”. It had 194 likes, 16 comments and a link to solidcv, “a pure Rust replacement for OpenCV with kernels for Apple Silicon and NVIDIA Grace-Blackwell”. I have a Jetson Nano, so I cloned the repo and asked Claude Code to see what it could do. I didn’t build it. The first thing it found was a build.rs that decrypts 88 KB of code during cargo build and compiles it into the library. That code would have run with my permissions before I called a single function.

Below is a breakdown of solidcv at commit 35c33e3 from 2026-10-22, and the list of checks I now run on every repo from the feed.

Why is building someone else’s repo already running their code?

cargo build first compiles and runs the author’s build.rs, with your permissions and no sandbox. npm does the same with preinstall and postinstall, Python with setup.py and build hooks. A script like that can read ~/.ssh and the tokens in ~/.config and send them anywhere.

solidcv’s src holds 26,407 lines of Rust, all of it written in five days. The README suggests checking the speedups with cargo run --release --example full_suite_benchmark. The first thing that command runs is build.rs.

What does build.rs do in solidcv?

It reads assets/solidcv_moat_vault.bin, XORs it with a byte stream derived from the key SOLIDSF!, and splits the result into .rs files in OUT_DIR, the temporary build directory. Three library modules pull those files in with include!, which pastes them into their code verbatim:

$ grep -rn 'include!(concat!(env!("OUT_DIR")' src
src/voxelean.rs:8:include!(concat!(env!("OUT_DIR"), "/vault_voxelean.rs"));
src/worldtube.rs:8:include!(concat!(env!("OUT_DIR"), "/vault_worldtube.rs"));
src/realitycomb.rs:8:include!(concat!(env!("OUT_DIR"), "/vault_realitycomb.rs"));
$ xxd -l 32 assets/solidcv_moat_vault.bin
00000000: 7361 a006 64fa aed8 0436 1e93 8f7a 7289  sa..d....6...zr.
00000010: 4b52 8dfe fd1c 54b3 7c5f 1704 926f c450  KR....T.|_...o.P

An encrypted file in the build doesn’t prove bad intent. Still, grep across the repo can’t see its contents, and neither can a reader on GitHub. The file appeared in the very first commit (71 KB back then) and grew along with the project.

What’s inside solidcv’s encrypted file?

Ordinary Rust with no networking, no process spawning and no file reads. To see that, I reproduced the decryption with a separate Python script in a temporary directory, without cargo. The algorithm sits in plain view in the same build.rs: an eight-byte key SOLIDSF!, a splitmix64-style hash of the byte index, an XOR on every byte, then a SSFVLT01 header and a list of “file name, contents” pairs. I ran Python with -I so it wouldn’t load anything from the current directory:

$ python3 -I tools/unvault.py ~/code/solidcv/assets/solidcv_moat_vault.bin vault
magic: b'SSFVLT01'
realitycomb.rs  41338 bytes
voxelean.rs  27715 bytes
worldtube.rs  19016 bytes
$ grep -cE "std::net|std::process|TcpStream|Command" vault/*.rs
vault/voxelean.rs:0
vault/realitycomb.rs:0
vault/worldtube.rs:0

Inside are 2363 lines: octrees, optical flow, three unsafe blocks. The first lines of the first file hold a notice (I removed the author’s address):

 *  [solidSF CLASSIFIED KERNEL VAULT - REVERSE-ENGINEER BOUNTY]
 *  Proprietary Engines: GB300 PTX | RealityComber | Voxelean | Worldtube
 * ----------------------------------------------------------------------------
 *  If you reversed the Zobrist-Feistel stream cipher to unpack this vault:
 *  please email ... because Andy Norris wants to fly you to SF

The encryption here works as a marketing quest: the key sits in the open build.rs. I found no trojan in solidcv, either in the encrypted file or in src. The examples and the solidcv-app application run ffmpeg, and the examples also read their frames from $HOME. That matches what they’re for. But the same delivery mechanism in another repo could carry anything, and you check it the same way.

Where do solidcv’s “N times faster than OpenCV” numbers come from?

The benchmark measures solidcv’s time, and the author typed the OpenCV column in as constants. The library is safe to build, but these multipliers are what the post is selling. The full_suite_benchmark example never calls OpenCV and prints seven fixed numbers:

$ grep -nE "opencv5?_s[0-9]+_us *=" examples/full_suite_benchmark.rs
137:    let opencv5_s1_us = 35.67;
176:    let opencv5_s2_us = 50.13;
215:    let opencv5_s3_us = 549.10;
245:    let opencv5_s4_us = 10_445.90;
281:    let opencv5_s5_us = 4_605.06;
504:    let opencv5_s8_us = 3_710.83;
720:    let opencv_s13_us = 323.41;

The README admits this in its FAQ: the author didn’t want to pull C++ OpenCV in as a dependency and wrote their own measurements down as numbers. The LinkedIn quote drops that caveat. And the README’s “575.4× faster feature matching” belongs to a different row of the table. The 575.35× figure is for SAE dictionary lookup (16 queries, 4096 atoms) compared with FP32 matrix multiplication. Feature matching, ORB BFMatcher against OpenCV, gets 5.53× in the same table.

Does solidcv compute on NVIDIA Tensor Cores?

No, on NVIDIA the library computes on the CPU only. The README promises PTX kernels (NVIDIA GPU assembly) for Grace-Blackwell GB300. In the code those kernels sit in a text constant that nothing loads onto the GPU. The only place that reads it counts the entry points in the text for a report:

$ grep -rn 'CUDA_PTX_KERNEL_SOURCE' src | grep -v '//!'
src/hardware.rs:1109:pub const CUDA_PTX_KERNEL_SOURCE: &str = r#"
src/hardware.rs:3377:    let ptx_kernels_ready = CUDA_PTX_KERNEL_SOURCE.matches(".visible .entry").count();
$ grep -rnE 'cuLaunch|cuModuleLoad|#\[link' src
src/hardware.rs:1139:#[link(name = "Metal", kind = "framework")]
src/hardware.rs:1140:#[link(name = "Foundation", kind = "framework")]
src/hardware.rs:1141:#[link(name = "objc")]

The only thing linked is Metal on macOS. The code contains no calls to the CUDA driver (cuLaunch, cuModuleLoad).

Will solidcv run on a Jetson Nano?

On the CPU, most likely yes. The NEON code (ARM SIMD instructions) in imgproc, calib3d and uplift is gated only on the aarch64 architecture, and the Nano’s CPU has it. The acceleration paths in hardware.rs are enabled only on macOS and iOS. The library won’t use the Nano’s GPU. Install Rust through rustup. I drew this conclusion from the code: I didn’t test it on the hardware, and I didn’t run cargo build on the Mac where I went through the repo either.

What should you check in someone else’s repo before building it?

Here’s the order Claude Code followed with solidcv:

The same as a list for the next repo from the feed:

1. Full history. Clone without --depth 1 or run git fetch --unshallow: a shallow clone always shows a single commit, and I tripped over that myself. Then git log --format='%h %ad %an' --date=short.
2. What runs on install. Rust: build.rs and build-dependencies. npm: preinstall, install, postinstall in package.json, the project's own and its dependencies'. Python: setup.py and build hooks in pyproject. Read them in full.
3. Binary files. git ls-files | xargs file | grep -v text. Anything that isn't an image or a font but gets read by the build needs an explanation.
4. Generated code pasted in. include!, eval, exec, importlib, new Function, long base64 strings.
5. Network, processes, secrets. grep -rnE 'TcpStream|reqwest|fetch\(|requests\.|subprocess|Command::new|child_process|\.ssh|\.aws'. Every hit should match a function you will call.
6. The post's main claim. Find it in the code. "GPU": where is the kernel launched? "N times faster": what was measured, against what, and is it the same row of the table?
7. The first build goes in a container or VM without your keys and tokens.

When I asked Claude Code to “clone it and check what’s there”, it stopped at build.rs on its own and decrypted the file separately before going further. Next time your feed promises “575× faster”, start with cat build.rs.