Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

fix(telegram): use CSPRNG for pairing codes and lock down store permissions#2722

Open
dweekly wants to merge 1 commit into
nanocoai:channels from
dweekly:fix/telegram-pairing-hardening
Open

fix(telegram): use CSPRNG for pairing codes and lock down store permissions #2722
dweekly wants to merge 1 commit into
nanocoai:channels from
dweekly:fix/telegram-pairing-hardening

Conversation

@dweekly

@dweekly dweekly commented Jun 9, 2026

Copy link
Copy Markdown

Type of Change

  • Fix - bug fix or security fix to source code

Description

Pairing codes gate chat registration, and the first pairer can be promoted to owner — but generateCode drew them from Math.random, which is predictable from observed outputs. Switched to crypto.randomInt.

Also locks down the pairing store, which holds pending codes in plaintext: directory 0700, file 0600. writeFileSync's mode only applies when the file is created, so a stale .tmp left by a crash could carry old permissions through the rename; it's now removed before writing.

Tested: new regression test asserts the store file lands at 0600 (skipped on Windows); telegram-pairing.test.ts passes 27/27. These files also typecheck and pass the full suite when copied into a trunk install. Note for reviewers: tsc on the channels branch tip fails for pre-existing, unrelated reasons (telegram.ts references resolveChannelName, absent from this branch's ChannelAdapter), same as noted in #2552.

...ssions
Pairing codes are an auth boundary — the first pairer can be promoted
to owner — but they were generated with Math.random, whose internal
state is recoverable from prior outputs, letting an attacker predict
upcoming codes. Switch to crypto.randomInt (uniform, no modulo bias).
Also restrict the pairing store to owner-only access: dir 0700, file
0600. writeFileSync's mode only applies at file creation, so a stale
.tmp left by a crash would carry its old permissions through the
rename — remove it before writing. Add a regression test asserting
the store lands at 0600 (skipped on Windows).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@gavrielc gavrielc Awaiting requested review from gavrielc gavrielc is a code owner

@gabi-simons gabi-simons Awaiting requested review from gabi-simons gabi-simons is a code owner

Assignees

No one assigned

Labels

PR: Fix Bug fix

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

AltStyle によって変換されたページ (->オリジナル) /