| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
| |
Reader now keeps the private key bytes and the per-submission ECDH/HKDF
secrets in memguard.LockedBuffer (mlock + guaranteed wipe) instead of a
manual zero loop. Added a regression test for the decrypt path.
Message field gets a self-hosted Markdown toggle preview (no external
library): headers, bold/italic, inline code, code blocks, blockquotes,
lists, links. Output is HTML-escaped and link schemes are whitelisted
before rendering. Submitted content is still the raw Markdown source,
unchanged on the wire.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The old 10MB cap was checked against the wire body, but two base64 layers
sit between the raw file and that body: crypto.js base64-encodes the file
before AEAD encryption, then nym.Client.Send base64-encodes the ciphertext
again to embed it in the JSON sent to the local nym-client over its control
WebSocket. A file at exactly the old cap produced a wire body just over the
limit after the first layer, and would have blown nym-client's own hardcoded
16MB WebSocket message limit after the second, surfacing as an opaque 500.
Lower the wire-body cap to 11MB, which keeps the second base64 layer with
real margin under nym-client's 16MB ceiling. Effective safe raw file size
is now roughly 8MB, not 10MB.
Reported by Ch1ffr3punk on nym.forum, reproduced with an exact 10MB file.
|
| |
|
|
|
|
|
| |
String.fromCharCode(...bytes) spreads every byte as a separate call
argument, exceeding the engine's max-arguments limit on multi-MB files
(RangeError: Maximum call stack size exceeded). Chunk the conversion
instead. Reported by a real submitter trying a 1.5MB file.
|
| |
|
|
|
|
|
|
|
|
| |
Theme state persists via localStorage, applied pre-paint by theme-init.js
to avoid flash. All JS moved to external files (app.js, theme-init.js)
to keep script-src 'self' CSP intact, no inline scripts.
Dark theme footer/notice/tagline colors were too close to the background
(footer nearly matched the card border color) and hard to read; brightened
to readable grays while leaving the light theme and submit button untouched.
|
| |
|
|
|
|
|
|
|
| |
A tight loop of only-awaited crypto.subtle.digest calls never yields
to the browser's rendering pipeline (they resolve as microtasks), so
the "computing proof of work" status update was silently skipped from
the user's perspective even though the computation ran correctly.
Insert an explicit macrotask yield before and periodically during the
search so the message actually paints and the tab stays responsive.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Self-contained hashcash-style PoW on /submit: client finds a nonce so
SHA-256("<unix-ts>:<nonce>") has enough leading zero bits, sent as an
X-Nymdrop-Pow header; server verifies and rejects expired or replayed
stamps, no challenge round-trip required. Difficulty tunable via
--pow-difficulty without a rebuild.
Also fixes a latent bug in the browser crypto: X25519 was being
requested as ECDH with namedCurve "X25519", which is not a valid
WebCrypto combination and always throws. Modern WebCrypto exposes
X25519 as its own algorithm identifier.
|
|
|
End-to-end verified pipeline (browser -> HTTP relay -> Nym mixnet -> reader).
Client-side X25519+HKDF+AES-GCM-256, no-log blind relay, AGPL-3.0.
|