Cargo.toml

[package]
# Package name = binary name.  Brand history:
#   v0 : OpenSentry         → original brand; repo was
#                             `opensentry-cloud-node`
#   v0 : SourceBox Sentry   → mid-life rename; binary was minted here as
#                             `sourcebox-sentry-cloudnode`
#   v0+: Sentinel by SourceBox (current — repo renamed to
#        `Sentinel-CameraNode` in May 2026; GitHub auto-redirects the
#        old URL)
#
# The binary lagged the repo by one brand for years.  This comment used
# to say the rename was deferred until "probably alongside a v1.0.0
# release" because renaming would orphan existing systemd units, Windows
# service registrations, and Docker volumes.
#
# Done 2026-09-09 instead, while the product had **zero installs** —
# there was nothing to orphan, and that is the only moment this costs
# nothing.  The deferral was protecting against a cost that did not
# exist yet and would only have grown.
#
# `cameranode` is also simply the more accurate word: this binary drives
# cameras.  It was never a cloud node.
name = "sourcebox-sentry-cameranode"
version = "0.1.77"
edition = "2021"
authors = ["SourceBox LLC"]
description = "Sentinel CameraNode — turns a USB webcam into a cloud-connected security camera."
license = "GPL-3.0"
repository = "https://github.com/SourceBox-LLC/Sentinel-CameraNode"
homepage = "https://sentinel-command.com"

[dependencies]
# Async runtime.  Explicit feature list instead of `full` so we don't
# pull in `io-std` (async stdin — we use std::io::stdin directly),
# `net` (TCP/UDP — reqwest and tungstenite pull whatever transport
# bits they need transitively), or `parking_lot` (alternate mutex
# impl, not used).  Inventory of in-tree usage:
#   - tokio::fs::*                 → fs
#   - tokio::io                    → io-util
#   - tokio::process               → process
#   - tokio::spawn / task / runtime / spawn_blocking
#                                  → rt-multi-thread
#   - tokio::select! / #[tokio::main] / #[tokio::test]
#                                  → macros
#   - tokio::signal::ctrl_c        → signal
#   - tokio::sync::* (mpsc, RwLock, Notify, …)
#                                  → sync
#   - tokio::time::*               → time
tokio = { version = "1", features = [
    "fs",
    "io-util",
    "macros",
    "process",
    "rt-multi-thread",
    "signal",
    "sync",
    "time",
] }

# HTTP client
# default-features = false drops the `default-tls` (OpenSSL) feature so the
# Docker Alpine build doesn't need openssl-dev headers.  rustls-tls is pure
# Rust and works everywhere without a system TLS library.
reqwest = { version = "0.12", default-features = false, features = ["json", "rustls-tls", "stream", "blocking"] }

# WebSocket client
tokio-tungstenite = { version = "0.30", features = ["rustls-tls-webpki-roots"] }
futures-util = "0.3"

# HTTP server (for serving recordings locally)
warp = { version = "0.4", features = ["server"] }

# Serialization
serde = { version = "1", features = ["derive"] }
serde_json = "1"

# Configuration.  Used only for parsing legacy `config.yaml` files
# on first boot — values get migrated into the SQLite config DB and
# the YAML file is never read again.  No migration impact for
# existing nodes because they're already on the DB code path.
#
# Note on dep choice: `yaml-rust` (last release 2018, archived) was
# the original.  `serde_yaml` 0.9 is the current pin: it's marked
# deprecated by the upstream maintainer but is functionally stable,
# widely used, gets occasional security backports, and has a
# familiar serde-flavoured API.  The maintained alternatives
# (`serde_yml`, `yaml-rust2`) are either pre-1.0 (serde_yml=0.0.x)
# or have a different shape (yaml-rust2 is lower-level).  Revisit if
# a real CVE shows up and serde_yaml has no fix.
serde_yaml = "0.9"

# CLI
clap = { version = "4", features = ["derive", "env"] }

# Logging
tracing = "0.1"
tracing-subscriber = { version = "0.3", features = ["env-filter", "json", "registry"] }
once_cell = "1"

# Error handling
anyhow = "1"
thiserror = "1"

# UUID
uuid = { version = "1", features = ["v4", "serde"] }

# Phase C: embed the Vite-built local web UI into the binary at compile
# time. `debug-embed` makes embeds work in `cargo run` debug builds too,
# so a fresh `cargo build` after editing `web/` always picks up the
# latest `web-dist/`.  Without that feature, debug builds re-read
# `web-dist/` from disk on every request, which loses the "single
# binary" property.  Trade-off accepted: slightly larger debug binaries.
rust-embed = { version = "8", features = ["debug-embed"] }
mime_guess = "2"

# Time
chrono = { version = "0.4", features = ["serde"] }

# Bytes
bytes = "1"

# Base64 encoding (for snapshot image transfer over WebSocket)
base64 = "0.22"

# (`percent-encoding` was a direct dependency until v0.1.65 when the WS
# client moved its credentials from URL query parameters to HTTP request
# headers — see `src/api/websocket.rs::build_ws_request`.  Removed because
# nothing else in the codebase needed it.  If a future feature wants URL
# encoding, prefer the percent_encoding crate again over hand-rolled.)

# System info
sysinfo = "0.39"

# Terminal UI
crossterm = "0.29"
inquire = "0.7"
indicatif = "0.18"
colored = "2.1"

# Archive extraction
zip = "0.6"

# Environment file loading
dotenvy = "0.15"

# Local storage database
rusqlite = { version = "0.40", features = ["bundled"] }

# Encryption (API key at rest)
aes-gcm = "0.10"
sha2 = "0.10"
rand = "0.8"

# Local-admin auth (LAN-exposed installs — Local mode / --lan-streaming).
# argon2 hashes the admin password; hmac signs stateless session tokens
# (paired with the sha2 already above). Neither the recording-store nor
# API-key-at-rest use these — aes-gcm there is reversible encryption,
# not password hashing / message authentication.
argon2 = "0.5"
hmac = "0.12"

# Raw V4L2 ioctl on Linux (camera capability detection).  Already pulled
# in transitively by tokio/reqwest, but we declare it directly so the
# unsafe ioctl call in src/camera/platform/linux.rs has a stable surface.
[target.'cfg(target_os = "linux")'.dependencies]
libc = "0.2"

# Windows-only: service control + non-blocking file logger.
#   - windows-service handles the Service Control Manager handshake
#     (Start/Stop notifications, status reporting). Used by src/service.rs
#     when the binary is invoked as a Windows Service via the `service`
#     subcommand.
#   - tracing-appender provides a daily-rolling file logger so the
#     service has *somewhere* to write — the standard `tracing` →
#     DashboardLayer path is TUI-only and a Service has no terminal.
[target.'cfg(target_os = "windows")'.dependencies]
windows-service = "0.8"
tracing-appender = "0.2"

[dev-dependencies]
# `test` pulls warp::test::request for the filter tests. Declared
# here rather than in [dependencies] so hyper/client stays out of
# the shipped binary — warp 0.4 made all features opt-in.
warp = { version = "0.4", features = ["server", "test"] }
tokio-test = "0.4"
tempfile = "3"

[profile.release]
opt-level = 3
lto = true
# strip = "debuginfo" instead of "symbols" / true
#
# `strip = true` is equivalent to `strip = "symbols"`, which removes
# the entire COFF symbol table along with debuginfo. On Windows MSVC
# that breaks two things we want for a service binary:
#
#   1. Windows Error Reporting (WER) writes Application Error events
#      with the faulting module + offset; without symbols, the offset
#      is into a blob of unnamed code and can't be matched back to a
#      function. A service that crashes silently with no symbol info
#      is essentially undebuggable post-mortem.
#
#   2. Stack traces produced by `panic = "unwind"` need symbols to
#      resolve frame names. With `strip = "symbols"` they're empty.
#
# `strip = "debuginfo"` keeps the symbol table (small — symbols are
# names, ~10s of KB for our binary) and only drops the debuginfo
# sections (which are the bulk of debug bloat, MBs). That's the right
# trade-off for a release service binary: small enough to ship,
# debuggable when something goes wrong on a customer machine.
strip = "debuginfo"
# Generate line tables (function name + file/line) but not full
# debuginfo. WER and `windbg` use this to produce readable crash
# traces. ~1 MB of binary growth, worth every byte for a binary
# that runs as a Windows Service with no console for live debugging.
debug = 1

# ── cargo-wix MSI build configuration ───────────────────────────────
#
# `cargo wix` reads from this section but most of the knobs we care
# about — culture, no-build, locale — are CLI flags rather than metadata
# fields. The release.yml workflow passes them via the command line
# (`--culture en-US --no-build`).
#
# UpgradeCode and component GUIDs live in wix/main.wxs (NOT here) so
# they stay stable across releases — Windows Installer treats a changed
# UpgradeCode as a brand-new product, breaking the upgrade chain.
[package.metadata.wix]
# Reserved for future use. Empty today; kept so cargo-wix recognises
# this project as wix-aware and doesn't try to scaffold from scratch
# the next time someone runs `cargo wix init`.