kingchenc
b7ef63400d
Adds an R binding (`bindings/r`) over the C ABI hub — the third language stecker after C# and Go, reaching the hub through R's native `.Call` interface (not extendr). ## What's here - **`bindings/r`** — an R package exposing all 514 indicators as constructors that return a `wickra_indicator` object with generic `update`/`batch`/`reset` methods. The C glue (`src/wickra.c`) and R wrappers (`R/indicators.R`) are generated from `bindings/c/include/wickra.h` (same archetype taxonomy as the C#/Go generators: scalar/batch, multi-output, bars, profile, profile-values, array-input). The opaque handle is an R external pointer freed by a registered finalizer; multi-output returns a named vector (`NA` at warmup), bars a matrix, profiles a list. - **`examples/r`** — the full example suite mirroring C/C#/Go: streaming, backtest, multi_timeframe, parallel_assets (`mclapply`), three strategies, and `fetch_btcusdt`/`live_binance`. - **CI** — an `r` job builds the C ABI library, installs the package, runs the `testthat` suite and the offline examples on Linux, macOS and Windows (`R CMD check` is clean: 0 warnings, 0 notes). - **Docs** — R added to the README languages table, project layout, building/testing, CONTRIBUTING binding table + regenerate note, ARCHITECTURE, examples index, issue/PR templates, the About-description template, and the other binding READMEs. ## Linking / distribution The package compiles a thin `.Call` glue layer against the prebuilt C ABI library (header via `WICKRA_INCLUDE_DIR`, library via `WICKRA_LIB_DIR`). On Windows the package's own `wickra.dll` would collide with the C ABI's `wickra.dll`, so `configure.win` stages a renamed copy (`wickra_abi.dll`) and builds an import library referencing it; `install.libs.R` bundles the DLL and `.onLoad` puts it on the load path. On Linux/macOS the rpath locates the shared library. No `release.yml` change — R is distributed via r-universe / source install (gated). No Rust crate or `Cargo.toml` change — the R package is standalone and additive.
4.0 KiB
4.0 KiB
Threat model
This document describes Wickra's attack surface and the threats considered,
together with their mitigations. It complements the security assurance case in
SECURITY.md. Wickra is a computational technical-analysis
library (a Rust core with Python, Node.js and WebAssembly bindings plus a C ABI
and the .NET, Go and R bindings built on it),
not a network service or trading system; the attack surface is correspondingly
small.
Assets
- Integrity of computed indicator values — consumers may use them in automated decisions, so silently wrong output is the primary concern.
- Availability of the calling process — a library must not crash or hang its host on malformed input.
- Integrity of published artifacts — the crates, wheels and npm packages users install.
- The build and release pipeline and its secrets (publishing tokens).
Actors / trust boundaries
- Library consumer (trusted) — calls the API with numeric data. Data may originate from untrusted sources (e.g. a market feed), so input values are treated as untrusted even though the caller is trusted.
- Optional live feed — with the
live-binancefeature, data crosses a network boundary from an exchange over TLS. - Contributors (semi-trusted) — propose changes via pull requests.
- Supply chain — upstream dependencies and the CI/CD platform.
Threats and mitigations
| Threat | Mitigation |
|---|---|
| Memory-safety exploit (buffer overflow, UAF) via crafted input | Pure safe Rust; unsafe is forbidden/minimised, so the compiler precludes these classes. |
| Misuse of the C ABI FFI boundary (invalid/dangling handle, undersized batch buffer) | The C ABI (bindings/c) is the sole unsafe surface. Its shim adds no logic, NULL-checks every handle (returning NaN/no-op), writes only into caller-sized buffers, and catches panics so none cross the boundary. A caller passing a non-NULL but dangling pointer is undefined behaviour by C's own contract — out of scope, the same as any C library. |
| Denial of service via malformed/degenerate input (NaN, infinities, extreme magnitudes) | Indicators reject non-finite inputs and validate parameters at construction; update paths are exercised by coverage-guided fuzzing and unit tests for edge cases. |
| Silently incorrect results | 100% line coverage on the core crate; reference-value tests against known-good sources; streaming/batch parity tests. |
| Integer overflow / panics | clippy::pedantic with -D warnings; debug assertions and overflow checks enabled in test/fuzz builds. |
| Adversary-in-the-middle on the optional live feed | Connection uses TLS via the platform library; transport security is delegated to that reviewed implementation. |
| Compromised dependency (supply chain) | Dependencies pinned (Cargo.lock, hash-locked CI requirements), monitored by Dependabot, audited by cargo-deny (advisories + licenses) on every change. |
Malicious or accidental change to main |
Branch protection requires signed commits and blocks force-push and deletion; all changes flow through pull requests with required CI; static analysis (CodeQL, Clippy) and fuzzing run on every change. |
| Compromised CI / leaked secrets | Workflows use least-privilege permissions:; secrets live only as encrypted GitHub Actions secrets; secret scanning with push protection is enabled; workflows are linted by zizmor. |
| Tampered release artifact | Releases are built in CI, tags are signed, and assets carry build provenance attestations (verifiable with gh attestation verify). |
Out of scope
- Wickra implements no authentication, authorization or cryptography of its own, stores no user data, and exposes no network listener; those threat classes do not apply.
- Vulnerabilities in third-party dependencies that do not affect Wickra are
tracked as exploitability (VEX) records (see
SECURITY.md).
Maintenance
This threat model is reviewed when the architecture changes materially (for example, a new input family, a new network feature, or a new release channel).