ncpeer_vcpkg

model: haiku-4-5-20251001 cpp static analysis off 0 PR(s) seen

workspaceninjarmm jira projectNJ review targetsncpeer_* thresholdsseverity ≥ major · confidence ≥ high · cap 6 max diff1.0 MB pollevery 300s

open repo in Bitbucket →

What this is

vcpkg dependency fork for NinjaRemote — pinned/patched third-party ports (libvpx, openssl/FIPS, boost, pdfium, ...) plus custom ports-ninja + triplets, shared by ncpeer and nmsnj builds. Review PRs into the pinned ncpeer_YYYY_MM lines (dep bumps, port patches, build fixes); master / master_overlays rebase branches are out of scope.

Project primer

Durable orientation injected into every review as .ai-review/project.md.

ncpeer_vcpkg — NinjaRemote dependency fork (review primer)

A fork of Microsoft's vcpkg holding NinjaOne's pinned + patched C/C++ dependencies
for the NinjaRemote builds (ncpeer and nmsnj build against it). Not application code —
package/build infrastructure (CMake + port manifests + patches + version pins).

Structure & maintenance model

Upstream ports/ plus NinjaOne's custom/overlay ports (e.g. ports-ninja),

triplets/, versions/, scripts/, toolsrc/, and overlay dirs.

Branch model: the pinned lines ncpeer_YYYY_MM (e.g. ncpeer_2026_06 — the exact

month rolls forward) are what the products build against — review PRs into those (dep
bumps, port patches, build fixes). master / master_overlays track upstream + carry the overlay and are
periodically rebased; those large rebase PRs are out of scope.

What matters most when reviewing here (durable risk areas)

Dependency security & provenance. A version bump or new port pulls third-party code

into the shipped products — check the source/tag is legitimate, the bump doesn't regress
a security fix, and any CVE relevance.

Version pinning & reproducibility. versions/ and baseline changes must stay

consistent; an inconsistent pin silently changes (or breaks) what everyone builds.

Port patches. Patches to a dependency must be correct, minimal, and apply cleanly to

the pinned version.

Triplet / toolchain correctness. Triplet and toolchain changes (static linking, arch,

FIPS/OpenSSL config) affect every consumer — wide blast radius.

Security-sensitive zones

Dependency sources/versions (supply chain); patches to crypto/TLS libraries (OpenSSL/FIPS);
anything changing how binaries are linked into the shipped clients.

Compatibility surfaces (contracts that must not silently break)

The pinned dependency set/versions the products expect (bumps ripple into ncpeer/nmsnj).
Triplet names and toolchain assumptions consumers rely on.

Conventions & gotchas

This is a fork of upstream vcpkg — most files are upstream; the reviewable NinjaOne work

is in the custom ports/overlays, triplets, versions, and pins.

License of newly-pulled dependencies matters (shipped product) — see the licensing dimension.

_Orientation only — verify current specifics in the code; this describes the durable
maintenance model & risk areas, not a snapshot._

Ecosystem map

Shared cross-project relationships, injected as .ai-review/ecosystem.md.

NinjaRemote / NinjaOne project ecosystem (relationship map)

How the monitored repos relate — so a change in one repo is reviewed with its blast
radius in mind (a change upstream of ncpeer can break ncpeer even if it looks local).
Orientation only; verify specifics in code.

NinjaRemote product

ncpeer — the remote-desktop client/agent (streamer host + player viewer). The hub.
ncrp — the server/relay component NinjaRemote peers connect through; ncpeer ⇄ ncrp

speak the NCRP wire protocol (protocol/format changes must stay compatible across
client and server versions).

ncinstaller — installs the ncpeer player onto end machines.
qclauncher — bootstraps/launches an ncpeer quick-connect session.

Cloud-side relays of the ninja-remote system (AWS-hosted, Python/Go)

websocket-switch — generic WebSocket pairing relay: two clients join with signed

URLs, it pairs them and forwards frames verbatim. Signed join URLs are minted by the
Ninja backend — the signature scheme is a backend⇄relay contract, and the frame
semantics are a peer⇄peer contract.

file-transfer-service — the same pairing idea over plain HTTP for file transfer:

a signed upload leg streams to a signed download leg through memory (never stored).
Two parallel implementations (Python ftsv2/ + Go fts_go/) must stay behaviorally
identical; the URL/signature scheme is shared-family with websocket-switch.
NinjaRemote file-transfer features ride on these relays when peers can't go direct.

Pulled INTO ncpeer (and sometimes nmsnj) — upstream of the products

nccommon — shared C++ library; a submodule of BOTH ncpeer and nmsnj. An API/ABI

or behaviour change here affects both consumers.

nr-i18n — localization resources; a submodule of ncpeer.
nrvirtdisplay — Windows virtual-display driver used by ncpeer.
nrvusb — virtual-USB driver used by ncpeer.
ncpeer_vcpkg — the pinned/patched dependency set (vcpkg fork) that **ncpeer and nmsnj

build against**. A dependency bump changes what those products link (security/ABI/build).

ncpeer_qt6win7 — patched Qt6 (QtBase) for legacy-OS support, delivered to the clients

through the ncpeer_vcpkg overlay.

Largely independent

nmsnj — network-management delegate (talks to the Ninja Backend over WAMP/RPC);

shares nccommon and ncpeer_vcpkg with ncpeer.

ninjaflow — packet-capture library + agent (a distinct network-telemetry product, NOT

part of the remote-desktop family). Runs as a child process of the NinjaRMM agent (the
parent owns install/upgrade/policy/launch); NinjaFlow owns the CLI contract, config schema,
credential precedence, DB schema/migrations, and exit-code meanings the parent consumes —
those are cross-process contracts. Submits telemetry to the Ninja Backend. Shares no code with
ncpeer/nmsnj; adjacent to nmsnj only in domain (network), not in implementation.

desktop-companion — internal companion app; mostly standalone.
spaceship — AppSec SBOM-ingestion backend (Python/Flask). A distinct security product,

not part of any product's build. It consumes the SBOMs the other products' pipelines emit
(Ninja-Remote/ncpeer, NMS/nmsnj, NinjaFlow all appear in its scope maps), scans them for CVEs
and files Jira issues — a downstream *security-scanning* relationship, not a code dependency.
Shares no code with the others; has its own DB/schema and a toolbox submodule.

ssh-pam-ninja — SSH one-time-password PAM gatekeeper (Linux C). A standalone

authentication component: its pam_ninja.so gates SSH reverse-tunnel access into
Ninja infrastructure with a time-based OTP. Shares no code with the other repos; its
blast radius is operational (who can SSH-tunnel into hosts), not code-level. The client OTP
generators and the module must agree on the OTP scheme + shared secret.

Review implications

Reviewing nccommon / nr-i18n / nrvirtdisplay / nrvusb / ncpeer_vcpkg / ncpeer_qt6win7:

these are *upstream* of ncpeer (and nccommon/vcpkg also of nmsnj) — weigh the consumer
side: API/ABI compatibility, build impact, and cross-platform reach.

Reviewing ncpeer or ncrp: the NCRP wire protocol between them is a cross-version

contract.

Also in every review's context

The reviewer instructions CLAUDE.md (rules, house C++ style, output schema); the PR/ticket block pr.md (title, description, linked Jira + acceptance criteria, commits, changed files); the full diff.patch.