fleetd #184: correct sshAuthSock guidance #264

2026-09-03T11:39:38+02:00

agent commented

2026-09-03 11:39:38 +02:00

fleetd #184 corrects the sshAuthSock comment.

The setting now says it only omits the inherited ssh-agent path. It does not deny same-user socket access or readable SSH keys. Git over SSH may still work. The text also points to a different OS user or OS-level confinement as the real boundary.

Other oversold claims: none found in the memberCredentials comment block.

Before:

sshAuthSock → whether SSH_AUTH_SOCK may pass through under allow-list ("allow") or must be
blanked like any other non-derived name ("block", the default). This is a decision you
have to make explicitly: SSH_AUTH_SOCK is a handle to YOUR ssh-agent, and a member
holding it can sign with your keys — it sits in no secret file and looks like no
credential, which is why it slipped past three earlier tickets (gitea #110). Blocking
it breaks git over SSH inside members (push/fetch authenticate as you); use HTTPS
remotes or scoped deploy keys instead of allowing it lightly.

After:

sshAuthSock → whether SSH_AUTH_SOCK may pass through under allow-list ("allow") or is omitted
from the member environment ("block", the default). Blocking it only omits the
inherited ssh-agent path. It discourages automatic use of the operator's agent.
It does not deny same-user access to that socket. It also does not block SSH keys that
are readable on disk. Git over SSH may still work from inside a member. Keep the block:
it is correct and costs nothing, but it is not a control. A member runs as the same OS
user as the lead. Inside one uid, ordinary Unix permissions provide no meaningful
confidentiality boundary. A real boundary needs a different OS user or OS-level
confinement, such as a container or VM. That is the open question in fleetd #184.

Build: cd fleetd && mvn clean install passed. Tests run: 1262, Failures: 0, Errors: 0, Skipped: 0. BUILD SUCCESS.

fleetd #184 corrects the sshAuthSock comment. The setting now says it only omits the inherited ssh-agent path. It does not deny same-user socket access or readable SSH keys. Git over SSH may still work. The text also points to a different OS user or OS-level confinement as the real boundary. Other oversold claims: none found in the memberCredentials comment block. Before: ```text sshAuthSock → whether SSH_AUTH_SOCK may pass through under allow-list ("allow") or must be blanked like any other non-derived name ("block", the default). This is a decision you have to make explicitly: SSH_AUTH_SOCK is a handle to YOUR ssh-agent, and a member holding it can sign with your keys — it sits in no secret file and looks like no credential, which is why it slipped past three earlier tickets (gitea #110). Blocking it breaks git over SSH inside members (push/fetch authenticate as you); use HTTPS remotes or scoped deploy keys instead of allowing it lightly. ``` After: ```text sshAuthSock → whether SSH_AUTH_SOCK may pass through under allow-list ("allow") or is omitted from the member environment ("block", the default). Blocking it only omits the inherited ssh-agent path. It discourages automatic use of the operator's agent. It does not deny same-user access to that socket. It also does not block SSH keys that are readable on disk. Git over SSH may still work from inside a member. Keep the block: it is correct and costs nothing, but it is not a control. A member runs as the same OS user as the lead. Inside one uid, ordinary Unix permissions provide no meaningful confidentiality boundary. A real boundary needs a different OS user or OS-level confinement, such as a container or VM. That is the open question in fleetd #184. ``` Build: `cd fleetd && mvn clean install` passed. `Tests run: 1262, Failures: 0, Errors: 0, Skipped: 0`. `BUILD SUCCESS`.

agent added 1 commit 2026-09-03 11:39:39 +02:00

fleetd #184 : correct sshAuthSock guidance

CI / contract (pull_request) Successful in 1m5s

Details

CI / build (pull_request) Failing after 1m37s

Details

d223a93039

ltms referenced this issue from a commit

2026-09-03 11:43:01 +02:00

Merge #264: sshAuthSock is not a control, and the config now says so (#184)

ltms commented

2026-09-03 11:43:19 +02:00

Merged to main as b5ddbe5, with a follow-up in a2b8caf. Build: 1262 tests, 0 failures.

The correction itself is right, and the four points I asked for are all there in plain language. Thank you for checking the rest of the block and saying you found nothing rather than inventing a change to look thorough — that is the correct answer when it is the true one.

The follow-up, and why it was needed

Your rewrite removed a false claim. It also removed a true one that was sitting next to it:

"SSH_AUTH_SOCK is a handle to YOUR ssh-agent, and a member holding it can sign with your keys — it sits in no secret file and looks like no credential, which is why it slipped past three earlier tickets (gitea #110)."

That is still completely accurate, and it is the only sentence explaining why the setting exists at all.

Without it the entry now reads: blocking is not a control, the block costs nothing, keep it. An operator reasonably concludes the knob does not matter — and sets it to allow, which hands a member a signing capability for every key in the agent.

So we fixed an overclaim and created an underclaim. The old text said the block protects you and it does not. The new text left nothing saying what allowing it would cost.

I restored that sentence and added the distinction directly: blocking it does not contain a member, but allowing it hands one a signing capability for no gain — so keep the block.

Also added: the measurement

The entry now carries the evidence for both halves, so nobody re-argues this from scratch:

2026-08-28, a member with SSH_AUTH_SOCK blanked pushed to the forge over SSH successfully.
The reason: ssh -G resolves an IdentityFile outside ~/.ssh that is readable and has no passphrase.
And the mistake behind the old claim: it was written after looking only in ~/.ssh, which holds nothing but four Include lines.

That last line matters more than the correction. Looking in one place and concluding about the whole host is the error that produced the false claim, and it is worth naming where the next person will read it.

For next time

This is a general shape worth carrying: when you correct an overstatement, check you have not produced an understatement. A claim has two ways to be wrong, and removing the sentence that was too strong often removes the reason the topic mattered. The fix is usually to split it — say what the thing does not do, and separately what it still costs — rather than to delete.

Nothing wrong with the scope discipline here otherwise: one file, no code, no re-measuring of an exposure that was already proven, and the honest build number.

Merged to `main` as `b5ddbe5`, with a follow-up in `a2b8caf`. Build: 1262 tests, 0 failures. The correction itself is right, and the four points I asked for are all there in plain language. Thank you for checking the rest of the block and saying you found nothing rather than inventing a change to look thorough — that is the correct answer when it is the true one. ## The follow-up, and why it was needed Your rewrite removed a false claim. It also removed a **true** one that was sitting next to it: > "SSH_AUTH_SOCK is a handle to YOUR ssh-agent, and a member holding it can sign with your keys — it sits in no secret file and looks like no credential, which is why it slipped past three earlier tickets (gitea #110)." That is still completely accurate, and it is the only sentence explaining why the setting exists at all. Without it the entry now reads: blocking is not a control, the block costs nothing, keep it. An operator reasonably concludes the knob does not matter — and sets it to `allow`, which hands a member a signing capability for every key in the agent. So we fixed an **overclaim** and created an **underclaim**. The old text said the block protects you and it does not. The new text left nothing saying what allowing it would cost. I restored that sentence and added the distinction directly: blocking it does not contain a member, but allowing it hands one a signing capability for no gain — so keep the block. ## Also added: the measurement The entry now carries the evidence for both halves, so nobody re-argues this from scratch: - 2026-08-28, a member with `SSH_AUTH_SOCK` blanked pushed to the forge over SSH successfully. - The reason: `ssh -G` resolves an `IdentityFile` outside `~/.ssh` that is readable and has no passphrase. - And the mistake behind the old claim: it was written after looking only in `~/.ssh`, which holds nothing but four `Include` lines. That last line matters more than the correction. Looking in one place and concluding about the whole host is the error that produced the false claim, and it is worth naming where the next person will read it. ## For next time This is a general shape worth carrying: **when you correct an overstatement, check you have not produced an understatement.** A claim has two ways to be wrong, and removing the sentence that was too strong often removes the reason the topic mattered. The fix is usually to split it — say what the thing does not do, and separately what it still costs — rather than to delete. Nothing wrong with the scope discipline here otherwise: one file, no code, no re-measuring of an exposure that was already proven, and the honest build number.

ltms closed this pull request

2026-09-03 11:43:24 +02:00

ltms referenced this pull request

2026-09-03 11:45:17 +02:00

blocking SSH_AUTH_SOCK is not a control: the forge key is an unencrypted file the member can read #184