| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
Tracked directly in-repo instead of a Forgejo release asset: this
instance's release/attachment upload hangs reproducibly on this specific
binary above ~55MB (isolated by bisection, not a size limit, not disk
space, unrelated to our code), while a plain git push works fine.
Downloadable read-only via cgit's plain view without touching Forgejo's
API. Built from commit 41d3abd.
|
| |
|
|
|
|
| |
Clarify that only the submission web form is truly cross-platform today;
nymdrop and nymdrop-reader are Linux/amd64 only because upstream nym-client
ships no Windows or macOS binary. Point to the linux/amd64 release build.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Extract reader logic (key management, embedded nym-client lifecycle,
receive loop, decrypt, save) into internal/reader as a Hooks-driven
package, shared by both the existing headless CLI and a new --gui mode
built with Fyne. Add --data-dir to make a reader instance fully
self-contained: privkey, inbox, and the embedded nym-client's own state
(normally fixed to $HOME/.nym) all live under the given directory via a
HOME override on the subprocess, enabling zero-trace USB operation.
CLI default behavior is unchanged (same paths, same protocol) so the
pietro deployment is unaffected.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
layer
Client.Send now speaks nym-client's native binary websocket protocol
(tag || recipient || conn_id || data_len || data) instead of wrapping
the ciphertext in a JSON text message, which required base64-encoding
it a second time on top of the browser's own base64 layer.
The reader's self-address query also switched to the binary protocol:
nym-client picks text-vs-binary for every later "received" push based
on the format of the last request seen on a connection, so leaving the
reader in JSON/text mode would have made nym-client run a lossy UTF-8
conversion over the now-unencoded binary payload, corrupting it. Fixed
the binary Received-frame parsing along the way (previous code assumed
a fixed 16-byte tag with no length prefix, which never matched the real
protocol and was never exercised while the connection stayed text-mode).
Verified end-to-end against the real embedded nym-client 1.1.76 binary,
with the exact wire format cross-checked against upstream nym source at
the pinned build commit.
|
| |
|
|
|
|
| |
favicon.ico/32/48 reference the official Nym icon so the site is
recognizable as Nym-community. CSP img-src 'self' data: was needed
for the PNG variants to load under the strict script-src 'self' policy.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
