patanyx

github.com/EdgeXene/patanyx, public, created 2026-08-01. https://github.com/EdgeXene/patanyx

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

The public repository carries interim snapshots of the release line between releases, exported through the same content sweeps as a release. The first is https://github.com/EdgeXene/patanyx/commit/6107f7f1, published 2026-09-23 between 1.0.1 and the next release.

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

Each release carries a unique version: 0.9.61, 0.9.62, 0.9.63, 0.9.65. scripts/check-version.sh gates the app version against the AppStream version because they once drifted 0.9.0 to 0.9.52 unnoticed.

Releases are tagged v0.9.61, v0.9.62, v0.9.63, v0.9.65 on GitHub.

Release notes are published through the GitHub Releases workflow at https://github.com/EdgeXene/patanyx/releases. Every release carries a human-readable summary of what changed and a statement of upgrade impact, written as prose rather than generated from the version control log. This criterion's details explicitly permit release notes provided by version control system mechanisms such as GitHub Releases; the automated check looks for a CHANGELOG file in the repository tree and therefore cannot see them.

The v0.9.65 release body states 'No security advisory applies to this build. If one ever does, it will be published here and at https://patanyx.net/ rather than removed.' No CVE has been fixed in a published release to date.

Non-trivial SECURITY[.md] file found in repository: https://github.com/EdgeXene/patanyx/blob/main/SECURITY.md. [osps_do_02_01]

GitHub Issues is the tracker.

no bug reports have been received.

no enhancement requests have been received. Same justification as report_responses.

The GitHub issue tracker is the public archive: every report and every response is retained, searchable, and individually addressable by URL. https://github.com/EdgeXene/patanyx/issues

SECURITY.md gives the reporting address, what to include, a 5-business-day acknowledgment commitment, supported-version policy, scope, and the documented-limits carve-out. https://github.com/EdgeXene/patanyx/blob/main/SECURITY.md

The contact form at patanyx.net/contact/ with the Privacy question category is a private channel; the destination address is held server-side and is not in the page source. https://github.com/EdgeXene/patanyx/blob/main/SECURITY.md

N/A. No vulnerability report has been received in the last 6 months.

cargo build --release --bin patanyx, documented in the README. Windows binaries cross-compile from Linux with scripts/build-windows.sh via cargo-xwin.

Cargo, the standard Rust build tool.

Rust, Cargo and cargo-xwin are all FLOSS, on a Debian 13 base (packaging/Dockerfile.ci).

1110 #[test] and #[tokio::test] sites across the ten crates, run by cargo test --workspace. Beyond that, scripts/ci-trixie.sh runs feature-gated suites that the default line misses, plus roughly a dozen project-specific gates.

README Testing section: 'Run the tests with cargo test --workspace.'

1110 tests across ten crates, plus gates that assert absence as well as presence (drag-regression-gate.js) and a planted-defect gate (licence-planted-defect-gate.sh) that stubs out each licence verification mechanism and asserts the suite FAILS there, which is real evidence the suite can detect a defect rather than merely pass.

LIVE at f24431b. CONTRIBUTING.md states: 'As major new functionality is added, tests for that functionality are added to the automated test suite in the same change.' https://github.com/EdgeXene/patanyx/blob/main/CONTRIBUTING.md

Evidenced by the gate suite growing alongside features, and by gates added specifically after regressions escaped (drag-regression-gate.js was added after the same Windows API call broke tab reordering twice).

LIVE at f24431b, same sentence in CONTRIBUTING.md.

Rust's safe mode is the qualifying mechanism, and it is partly enforced rather than assumed: eight of the ten crates (update, corroborate, chat, tunnel, integrity, ocr, store, license) declare #! [forbid (unsafe_code)].[forbid(unsafe_code)]. crates/app uses unsafe for the Windows and GTK platform APIs, and crates/vault holds one unsafe block: the flock(2) call at src/lock.rs:115, which carries a SAFETY comment. Nothing in the CI script asserts that the attribute is still present, so this is convention rather than a gate. The pinned toolchain installs rustfmt and clippy as components.

The project uses Rust's safe language mode, with #![forbid(unsafe_code)] declared in eight of the ten crates, and runs cargo clippy across the workspace and all targets in scripts/ci-trixie.sh before each release. A full clippy run reports 102 unique warnings across 75,682 lines of Rust, a density of 0.13 per 100 lines, which is within the threshold this criterion allows. All are style lints such as unnecessary_map_or and manual_div_ceil; none is a correctness or memory-safety finding.

Yes. The architecture is the evidence: least privilege in the chrome (default-src 'none'; script-src 'self' with no unsafe-inline), signed update manifests verified against a key compiled into the binary so a compromised distribution server cannot push an update, forbid(unsafe_code) outside the platform crate, and a documented threat boundary that says plainly what the product does not defend against.

Same evidence, plus fuzz targets aimed at exactly the parsers an attacker controls (update manifests, delta files, licence tokens and receipts, chat wire frames, blocklist manifests), and a chrome gate that bans innerHTML in the webview holding IPC and the vault.

Ed25519 for manifest and blocklist signatures, X25519, ChaCha20-Poly1305, Argon2id for the vault, SHA-2, and TLS through rustls and ring. All published and reviewed. Verified in Cargo.lock: argon2, chacha20poly1305, curve25519-dalek, ed25519-dalek, x25519-dalek, ring, rustls, sha2, zeroize.

The project calls established implementations (ring, rustls, the dalek curve crates, RustCrypto argon2 and chacha20poly1305) rather than implementing primitives itself.

All of the above are FLOSS crates.

Ed25519 and X25519 provide roughly 128-bit security; ChaCha20-Poly1305 uses a 256-bit key; SHA-2. All at or above the 112-bit floor this criterion sets.

No broken or known-weak primitive is used for a security purpose. The 128-bit hashes in the malicious-host list are a storage format for a public blocklist, not a security mechanism.

No MD5, SHA-1, or single-round password hashing in a security role.

TLS through rustls, which offers only forward-secret (ECDHE) key exchange.

The vault derives its key with Argon2id, with m_cost, t_cost and p_cost stored per slot and implausible parameters rejected before Argon2 runs (crates/vault/src/format.rs). The project stores no user passwords on a server.

getrandom and rand, which take entropy from the operating system CSPRNG.

Downloads are served over HTTPS, and the update channel does not rely on transport security alone: every update is described by an Ed25519-signed manifest verified against a key compiled into the binary, so a compromise of the distribution server, its DNS, or a certificate for it still cannot make an installation accept a modified update.

Every published binary carries a Sigstore bundle recorded in a public append-only transparency log, with the cosign verify-blob invocation, signing identity and issuer documented in the README, SECURITY.md and the release body. Windows binaries are additionally Authenticode-signed. Release bodies publish per-file SHA-256.

The most recent example: CVE-2026-85046 (V8 type confusion, exploited in the wild, fixed in WebView2 152.0.4191.62) was addressed on the release trunk on 2026-09-05 with a minimum engine version, a boot-time warning banner, and a signed-manifest mechanism that raises the floor on already-installed browsers. Days, not sixty. As of 2026-09-23 no medium or higher vulnerabilities are open: two Dependabot advisories (GHSA-wrw7-89jp-8q8g, CVE-2026-25727) were verified unreachable in PATANYX's code and dependencies and dismissed as "vulnerable code not used"; a dependency upgrade removing the affected time version is planned.

Same evidence.

Checked today. The only odd file in the public root is .publish-blocklist.lock, which is zero bytes and holds nothing. scripts/export-public-tree.sh runs a secrets sweep before accepting an export, and the exclusion list keeps the license server and relay entirely outside the repository.

CLOSED on the release trunk at commit 8ff3bb4. scripts/ci-trixie.sh now runs cargo clippy --workspace --all-targets --locked in a lints block before the toolchain pin gate, so a static analysis tool is applied before a release. Verified by running it: clippy executes and reports.

cargo audit (RustSec advisories against the locked dependency set) added to the lints block in scripts/ci-trixie.sh at 8ff3bb4, guarded so the gate reports a skip rather than failing where cargo-audit is not installed.

Clippy reports 3 findings, all in crates/integrity and all style lints (doc_lazy_continuation, if_same_then_else, unnecessary_map_or). None is an exploitable vulnerability of medium or higher severity, which is what this criterion asks about.

Clippy is in scripts/ci-trixie.sh, the gate run before every release.

cargo-fuzz with seven targets under fuzz/fuzz_targets: update_manifest, update_delta, licence_token_parse, licence_receipt_parse, chat_wire_decode, chat_wire_read_frame, blocklist_manifest. Those are precisely the attacker-controlled parsers.

cargo-fuzz builds with AddressSanitizer by default, and the fuzz targets cover the parsing code. The wider memory-unsafe surface is confined to crates/app; the other eight crates forbid unsafe outright.

Rust enables debug assertions in the default test and fuzz profiles, so assertions are active during both cargo test and fuzzing runs.

No outstanding medium or higher defect from fuzzing.