ElixirTorrent

Repository on GitHub, which provides public git repositories with URLs.

Repository on GitHub, which uses git. git can track the changes, who made them, and when they were made.

All development is pushed to the public master branch as it happens, so interim versions between releases are always available for review: https://github.com/daniboybye/ElixirTorrent/commits/master

Repository on GitHub, which uses git. git is distributed.

Every release carries a unique version number, defined once as @version in mix.exs and reused for the git tag, the GitHub release and the Hex.pm package. Current release: 0.6.3 — https://hex.pm/packages/elixir_torrent/versions

The project follows Semantic Versioning 2.0.0 (MAJOR.MINOR.PATCH), e.g. 0.6.3: feature/BEP additions bump the minor number, fix-only releases bump the patch number. See https://github.com/daniboybye/ElixirTorrent/blob/master/CHANGELOG.md

Each release is tagged in git with its bare version number (0.1.1 ... 0.6.3): https://github.com/daniboybye/ElixirTorrent/tags — the CI publish job is triggered by exactly these tags.

Non-trivial release notes file in repository: https://github.com/daniboybye/ElixirTorrent/blob/master/CHANGELOG.md.

Release notes are kept in CHANGELOG.md (also published at https://hexdocs.pm/elixir_torrent/changelog.html). No publicly known vulnerability (CVE or similar) has been reported or fixed to date; when one is, it will be named in the release notes of the release that fixes it and in the matching GitHub Security Advisory.

Non-trivial SECURITY[.md] file found file in repository: https://github.com/daniboybye/ElixirTorrent/blob/master/SECURITY.md. [osps_do_02_01]

GitHub Issues is the bug tracker and is enabled and public: https://github.com/daniboybye/ElixirTorrent/issues

The issue tracker is public and monitored by the maintainer. No third-party bug reports have been submitted in the last 2-12 months (the tracker currently holds no issues), so there are no unacknowledged reports; any report received will be acknowledged. Defects found by the maintainer are recorded and fixed — see https://github.com/daniboybye/ElixirTorrent/blob/master/CHANGELOG.md

No third-party enhancement requests have been submitted in the last 2-12 months (the public tracker currently holds no issues), so none are unanswered. CONTRIBUTING.md invites feature ideas as issues and the maintainer responds to them: https://github.com/daniboybye/ElixirTorrent/blob/master/CONTRIBUTING.md

The complete, publicly readable and searchable archive of reports and responses is GitHub Issues: https://github.com/daniboybye/ElixirTorrent/issues?q=is%3Aissue — pull request discussions are archived alongside it at https://github.com/daniboybye/ElixirTorrent/pulls

The vulnerability reporting process is documented in SECURITY.md: https://github.com/daniboybye/ElixirTorrent/blob/master/SECURITY.md — reports go privately through GitHub Security Advisories rather than public issues.

Vulnerabilities are reported privately through GitHub Security Advisories: https://github.com/daniboybye/ElixirTorrent/security/advisories/new (documented in SECURITY.md).

No vulnerability report has been received in the last 6 months (none to date). SECURITY.md commits to an initial response within a few days.

The library is built with Mix, the standard Elixir build tool: mix deps.get && mix compile rebuilds everything from source, with dependency versions and checksums pinned in mix.lock. CI performs a clean build on every push and pull request: https://github.com/daniboybye/ElixirTorrent/blob/master/.github/workflows/build-and-publish.yml

Mix ships with Elixir itself and is the conventional build tool for every Elixir project; the exact toolchain (Elixir 1.20 / OTP 29) is pinned in .tool-versions and installed in CI with erlef/setup-beam.

Elixir and Erlang/OTP (both Apache-2.0) plus Mix are FLOSS and the build runs on Ubuntu in CI; no proprietary tool is required to build the project.

An automated test suite (ExUnit) lives in https://github.com/daniboybye/ElixirTorrent/tree/master/test — roughly 1,500 tests across 132 files, including StreamData/PropCheck property-based tests and loopback-socket integration tests for the wire protocol, DHT, trackers, magnet metadata, uTP, MSE and storage.

mix test runs the whole suite with one command; this is documented in CONTRIBUTING.md and the README: https://github.com/daniboybye/ElixirTorrent/blob/master/CONTRIBUTING.md

Tests cover the wire protocol and handshakes, MSE/PE, DHT/KRPC, HTTP and UDP trackers plus scrape, magnet/BEP 9 metadata, uTP, BEP 52 Merkle hashing, storage/persistence and the entire public API, exercising both success and failure paths. Line coverage is about 88% and is reported to Codecov on every CI run (badge in the README).

GitHub Actions builds and runs the full test suite with coverage on every push to master and every pull request, together with format check, warnings-as-errors compile, Dialyzer, Credo, Sobelow and Trivy: https://github.com/daniboybye/ElixirTorrent/actions/workflows/build-and-publish.yml

CONTRIBUTING.md states that new functionality should come with tests and that a bug fix is a good opportunity to add a regression test: https://github.com/daniboybye/ElixirTorrent/blob/master/CONTRIBUTING.md

In practice every new feature/BEP and every bug fix is committed together with its tests; the suite has grown alongside the features to roughly 1,500 tests (see the commit history and CHANGELOG.md).

The policy is written down in CONTRIBUTING.md, section 'Before opening a pull request': https://github.com/daniboybye/ElixirTorrent/blob/master/CONTRIBUTING.md

The project compiles with warnings_as_errors: true (elixirc_options in mix.exs), so every compiler warning is surfaced, and additionally runs mix credo --all (strict) and Dialyzer through the mix quality alias.

Because warnings are errors, no warning can survive: the build fails until it is fixed. CI compiles both the dev and the test environment with --warnings-as-errors, and Dialyzer and Credo must report zero issues for the build to pass.

Maximum strictness is enabled by default rather than optionally: warnings-as-errors compilation, credo --all in strict mode, Dialyzer, Sobelow (--threshold medium) and Trivy, all enforced in CI on every push and pull request.

The design applies least privilege and fail-safe defaults: every byte coming from a peer, tracker or DHT node is treated as untrusted and validated at the decode boundary; message and metadata sizes are bounded before anything is buffered; file writes are confined to the torrent's own download directory with path-traversal sanitisation; the engine runs as an ordinary user process and needs no privileged port. Failure isolation is enforced by OTP supervision, so one misbehaving peer connection cannot corrupt or take down the session, and data integrity is enforced by per-piece hash verification before a piece is accepted.

The maintainer is familiar with the vulnerability classes relevant to a peer-to-peer network daemon and the countermeasures used here: untrusted input parsing (strict bencode/wire decoding with explicit length and type checks, malformed fields ignored instead of crashing), path traversal in multi-file torrents (path sanitisation), resource exhaustion and unbounded memory growth (bounded buffers, per-peer request rate limits, capped connection counts), spoofing/amplification in UDP protocols (BEP 42 node IDs, DHT write tokens bound to the source IP, transaction-ID checks, tracker connection IDs), and denial of service via malformed tracker responses. Sobelow and Trivy run in CI as an automated backstop.

All cryptography used comes from published, expert-reviewed specifications: SHA-1 and SHA-256 (FIPS 180-4) for infohashes and piece/Merkle verification as required by BEP 3 and BEP 52, and Diffie-Hellman key exchange plus RC4 exactly as specified by the public BitTorrent Message Stream Encryption / Protocol Encryption (MSE/PE) specification. Nothing is home-grown.

The project's primary purpose is not cryptography; it calls Erlang/OTP's :crypto module (backed by OpenSSL) for hashing, modular exponentiation, the RC4 stream cipher and random bytes. No cryptographic primitive is re-implemented in this codebase.

All cryptography goes through Erlang/OTP's :crypto (Apache-2.0) on top of OpenSSL (Apache-2.0), so every function that depends on cryptography is implementable with FLOSS.

The engine implements no confidentiality or authentication mechanism of its own, so it has no security keylength to choose. The only key agreement is the 768-bit Diffie-Hellman fixed by the BitTorrent MSE/PE specification, which exists for interoperability with other BitTorrent clients; MSE/PE is an obfuscation layer against traffic shaping and is explicitly not a confidentiality guarantee. The hash lengths used for content integrity (SHA-1 for v1, SHA-256 for v2/hybrid) are likewise mandated by BEP 3 and BEP 52.

No default security mechanism of the software depends on cryptography. SHA-1 (infohash and piece verification) and RC4 (MSE/PE stream obfuscation) are used solely because the BitTorrent v1 wire protocol and the MSE/PE specification mandate them for interoperability with existing clients: they guard against accidental corruption and ISP traffic shaping, not against an adversary. Where the protocol offers a modern alternative it is used — SHA-256 Merkle hashing for BEP 52 (v2 and hybrid) torrents.

See crypto_working: the software has no default security mechanism that depends on cryptography. The weak primitives present (SHA-1, RC4) are required verbatim by the BitTorrent v1 and MSE/PE specifications for interoperability with the existing swarm; SHA-256 is used for BEP 52 torrents wherever the protocol allows it.

The MSE/PE handshake performs a fresh ephemeral Diffie-Hellman exchange for every individual connection, and the private exponent is discarded with the connection. No long-term key exists or is stored anywhere, so compromising the host later does not expose earlier sessions.

The software neither authenticates external users nor stores any passwords; peer, tracker and DHT interaction uses no credentials at all.

All cryptographic keys and nonces are generated with :crypto.strong_rand_bytes/1 (OpenSSL's CSPRNG): MSE Diffie-Hellman private keys, the peer ID, DHT node IDs and transaction IDs, DHT write-token secrets, LSD cookies and STUN transaction IDs. Erlang's non-cryptographic :rand is used only for values that are neither keys nor nonces (MSE padding length, node-selection jitter, uTP connection and sequence numbers).

Distribution channels use HTTPS exclusively. [osps_br_03_02]

Nothing is retrieved over http and no unverified hash is used: sources and releases are served over HTTPS by GitHub and Hex.pm, dependency integrity is pinned by checksums in mix.lock, GitHub Actions are pinned by commit SHA, and release artifacts are signed with Sigstore/cosign and carry SLSA build provenance (see the publish job in https://github.com/daniboybye/ElixirTorrent/blob/master/.github/workflows/build-and-publish.yml).

No vulnerability has been reported to date, so none is outstanding. SECURITY.md commits to preparing a fix once a report is confirmed and shipping it as a new patch release together with an advisory — well inside 60 days.

There are no known unfixed vulnerabilities in the project, critical or otherwise.

The repository contains no credentials. Publishing to Hex.pm and signing releases use OIDC / short-lived tokens instead of stored long-lived secrets, and Trivy's secret scanner runs over the whole tree on every push and pull request in CI.

Static analysis runs on every push and pull request, and locally through the mix quality alias: Dialyzer (success-typing analysis of the whole application), Credo in strict mode (--all), Sobelow (security-focused static analysis, threshold medium, results uploaded as SARIF to GitHub code scanning) and Trivy (dependency and secret scanning). See https://github.com/daniboybye/ElixirTorrent/blob/master/.github/workflows/build-and-publish.yml

Sobelow is a security-focused static analyser for Elixir (command injection, unsafe deserialisation, path traversal, insecure configuration) and its findings are uploaded to GitHub code scanning; Trivy adds known-CVE scanning of dependencies and secret detection, and mix hex.audit flags retired packages. All three run in CI on every push and pull request.

Findings are fixed rather than accumulated: the CI job fails on any Dialyzer error, any Credo issue and any Sobelow finding of medium severity or higher, so a reported issue cannot reach master. No medium-or-higher exploitable vulnerability is currently outstanding.

The analysis runs on every push to master and on every pull request (plus on demand via workflow_dispatch) — far more often than once per release.

The full ExUnit suite exercises the real code paths over loopback sockets on every push, and property-based testing (StreamData and PropCheck/PropEr) generates randomised inputs for the protocol decoders and state machines. Dedicated aliases (mix test.stress, mix test.races, mix test.properties, mix test.state-machines) run the system under varied seeds and scheduler counts before releases.

The project is written entirely in Elixir and runs on the Erlang VM, which is memory-safe: no manual memory management, no pointer arithmetic, bounds-checked binaries. The project contains no C/C++ code and ships no NIFs of its own.

Tests run in the test environment with all ExUnit assertions active and nothing stripped; property-based tests assert protocol invariants on generated input, and the Erlang VM's own runtime checks (type and bounds checks on every term and binary) are always enabled.

No exploitable vulnerability has been found by dynamic analysis so far. Defects found by the test suite, property runs or the stress/race scripts are fixed before the change is merged — CI fails the build on any test failure — and past race findings were fixed together with deterministic regression tests (documented in CHANGELOG.md).