fix(cli): read a piped enrollment code as UTF-8 bytes on every console code page #46

2026-11-11T02:48:33Z

james.maes commented

2026-11-11 02:48:33 +00:00

A piped enrollment code was misread on every console code page but UTF-8.

What was wrong

The command line dropped a leading byte-order mark from piped input only when the console input code page was UTF-8. Under Windows PowerShell 5.1 on an ordinary console, the mark arrived as three stray characters in front of the code and the code was refused; piping nothing at all was taken for a code.

What changes

A piped or redirected enrollment code is read as bytes and decoded as UTF-8 whatever the console code page. A UTF-16 mark at the very start is honoured, so a file written by PowerShell 5.1's > works.
Typing at a console is unchanged: the prompt appears only there, and the code is never shown, printed or logged.
Three inputs are deliberately not repaired and send something that is not the code, which the server refuses: UTF-16 with no mark, a UTF-16 mark behind a UTF-8 mark, and a byte that is not UTF-8. Tests pin them.

Also in this pull request

A test-helper fix written earlier and not reviewed until now: the process tests tolerate a child that exits without reading its standard input (it failed once under machine load as "the pipe is being closed").

How the process tests stay away from the installed service

The service's pipe name is a constant, so the tests name a server address that is alone longer than the pipe accepts; such a request is refused before a connection is opened, and the helper asserts that before it starts a process. The reviewer checked the guard and found it sound.

Verification

Head 7c5a8c5 on release/2.0 at f481c43.
build/Verify.ps1 passed on that head: 968 Core, 1,568 Windows runtime and command line, 352 presentation tests, none failed; command line 100% of 120 lines; coverage gate passed.
Checked by the author and again by the reviewer against real Windows PowerShell 5.1 on a code page 437 console, with the unsendable server address.

Review (the reviewer who found the defect)

905ac62 (the test helper): Verdict on 905ac62: 0 blockers, 0 should-fix, 1 nit.
1e2d7e3: Verdict on 1e2d7e3: 0 blockers, 0 should-fix, 4 nits. Seven mutations of the reviewer's own, all caught by tests.
The head merged is 1e2d7e3 replayed onto f481c43; git range-diff e2ca086..1e2d7e3 f481c43..7c5a8c5 reports all three patches identical.

Left open, to be recorded in the audit (nits)

An older process test still names a sendable server; it is safe only because its input is empty.
A code holding U+FFFD or a control character could be refused locally with better advice.
A typo in docs/ADMINISTRATION.md; UTF-32 marks are honoured by the library and not mentioned; the helper leaves its writer open after a failed write.

🤖 Generated with Claude Code

A piped enrollment code was misread on every console code page but UTF-8. **What was wrong** - The command line dropped a leading byte-order mark from piped input only when the console input code page was UTF-8. Under Windows PowerShell 5.1 on an ordinary console, the mark arrived as three stray characters in front of the code and the code was refused; piping nothing at all was taken for a code. **What changes** - A piped or redirected enrollment code is read as bytes and decoded as UTF-8 whatever the console code page. A UTF-16 mark at the very start is honoured, so a file written by PowerShell 5.1's `>` works. - Typing at a console is unchanged: the prompt appears only there, and the code is never shown, printed or logged. - Three inputs are deliberately not repaired and send something that is not the code, which the server refuses: UTF-16 with no mark, a UTF-16 mark behind a UTF-8 mark, and a byte that is not UTF-8. Tests pin them. **Also in this pull request** - A test-helper fix written earlier and not reviewed until now: the process tests tolerate a child that exits without reading its standard input (it failed once under machine load as "the pipe is being closed"). **How the process tests stay away from the installed service** - The service's pipe name is a constant, so the tests name a server address that is alone longer than the pipe accepts; such a request is refused before a connection is opened, and the helper asserts that before it starts a process. The reviewer checked the guard and found it sound. **Verification** - Head `7c5a8c5` on `release/2.0` at `f481c43`. - `build/Verify.ps1` passed on that head: 968 Core, 1,568 Windows runtime and command line, 352 presentation tests, none failed; command line 100% of 120 lines; coverage gate passed. - Checked by the author and again by the reviewer against real Windows PowerShell 5.1 on a code page 437 console, with the unsendable server address. **Review (the reviewer who found the defect)** - `905ac62` (the test helper): `Verdict on 905ac62: 0 blockers, 0 should-fix, 1 nit.` - `1e2d7e3`: `Verdict on 1e2d7e3: 0 blockers, 0 should-fix, 4 nits.` Seven mutations of the reviewer's own, all caught by tests. - The head merged is `1e2d7e3` replayed onto `f481c43`; `git range-diff e2ca086..1e2d7e3 f481c43..7c5a8c5` reports all three patches identical. **Left open, to be recorded in the audit (nits)** - An older process test still names a sendable server; it is safe only because its input is empty. - A code holding U+FFFD or a control character could be refused locally with better advice. - A typo in `docs/ADMINISTRATION.md`; UTF-32 marks are honoured by the library and not mentioned; the helper leaves its writer open after a failed write. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

james.maes added 3 commits 2026-11-11 02:48:33 +00:00

test(cli): a child that exits without reading its input does not fail the process test f2b7760618

PrinterWorkerArgument_IsAnUnknownCommand offers a line on standard input to
a program that refuses its arguments and exits without reading. When the
program had already closed its end, the write failed with "The pipe is
being closed" and the test failed, once in a loaded verification run. The
helper now treats that as what it is: the program not reading.

Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
Signed-off-by: James Maes <james@kof22.com>

fix(cli): read a piped enrollment code as UTF-8 bytes on every console code page 06cea949f1

The command line read redirected standard input with Console.ReadLine,
which decodes in the console input code page and looks for no byte-order
mark, and then dropped a leading U+FEFF. The three bytes of a UTF-8 mark
are U+FEFF only when that code page is UTF-8. Windows PowerShell 5.1 puts
the mark in front of piped text whenever $OutputEncoding is UTF-8, whatever
the code page, so on an ordinary OEM console the mark arrived as three
other characters in front of the code and the server refused the code as
unknown.

Redirected input is now opened as bytes and its first line is decoded as
UTF-8 with the mark detected, so the result no longer depends on the code
page. A code is ASCII, which is the same bytes in every code page. Reading
at a console is unchanged: the prompt is written only there, and the code
is typed without being shown. Nothing new is printed, and the code still
goes only into the request.

A UTF-16 mark at the very start is honoured and the text is decoded as
UTF-16, not refused: a file Windows PowerShell 5.1 writes with ">" is
UTF-16 with a mark, and refusing it would send an operator away from input
that is unambiguous. Nothing else is guessed. UTF-16 with no mark is read
as UTF-8, a UTF-16 mark behind a UTF-8 mark is not a mark, and a byte that
is not UTF-8 becomes the replacement character; in each case what is sent
is not the code. Tests state these three on purpose.

The host hands the command line a stream in place of a line reader, and
the test fixture scripts standard input as bytes.

The process tests give the real executable input bytes and still cannot
reach the installed service: they name a server address that, written as
JSON, is by itself longer than the pipe accepts, and such a request is
refused before a connection is opened. The executable therefore ends with
"Enrollment code is required." when it found no code and with "Local pipe
message exceeds the permitted size." when it found one. The helper checks
that the address is that large before it starts a process.

Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
Signed-off-by: James Maes <james@kof22.com>

docs(cli): say how a piped enrollment code is decoded 7c5a8c530a

The changelog said the byte-order mark is dropped whichever way the code
arrives, and the administration guide named a UTF-8 console code page as
the only case. Both now say what the command line does: piped input is
read as bytes and decoded as UTF-8 on every console code page, a mark at
the start is recognized, input that begins with a UTF-16 mark is read as
UTF-16, and UTF-16 without a mark is not recognized.

Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
Signed-off-by: James Maes <james@kof22.com>

james.maes merged commit fe95a9fcae into release/2.0

2026-11-11 02:48:52 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: QRun-IO/qqq-print-agent#46