From a8585067b63c396dd84a699a40d0e0652acae524 Mon Sep 17 00:00:00 2001 From: Anthony Ettinger Date: Sun, 30 Aug 2026 13:33:18 +0000 Subject: [PATCH] fix(fleet): the sudo password was being executed as a command MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Reported from the desktop, and reproducible in one line: /bin/sh: 1: : not found `sudo -S` reads the password from stdin **only when it actually needs one**. Under NOPASSWD, a still-valid sudo timestamp, or a login that is already root, it reads nothing at all — and the password, which was prepended to the script on the same stream, falls through to `sh -es` and runs as command number one. Which also puts it in an error message. That is not a corner case. It is what happens on every deploy account configured the way deploy accounts are configured, and it is why the feature looked fine in review: the mechanism is correct exactly when sudo challenges you, and silently wrong when it does not. The fix is to stop sharing the stream. With a sudo password the script now travels as a quoted argument (`sh -ec '