Show the host keys this vault has approved
ci / build and test (ubuntu) (push) Canceled after 0s
ci / build (windows) (push) Canceled after 0s

Trust was created by the connect prompt and withdrawn from one host's editor, so
a pin for a host that had since been deleted or re-addressed was unreachable
from the interface entirely. It went on refusing connections and nothing in the
application would admit it was there. Two of the four recorded debts were really
this one: leftover pins, and no list to see them in.

A fourth section in the vault column, and the first that adding one has been
cheap for — three edits and two layout tests, which is what #8 and #9 were for.

No editor and no Add, which makes it the only section with neither. A pin is not
something anybody writes: it appears when somebody approves a fingerprint at the
moment of connecting, which is the one place a person can actually check it
against what the operator published. A form for typing one in would be a form
for pasting whatever a man in the middle just offered. So the section exists to
show and to withdraw, which is exactly what was missing.

The fingerprint is shown in full, wrapped, in a monospace line. The only thing
anybody does with one is compare it against a fingerprint an operator published,
and half of one cannot be compared — it can only be glanced at, which is the
habit pinning exists to replace. Nothing here is secret; a host key fingerprint
is published on purpose.

A pin no host in this vault dials is badged rather than hidden or deleted. That
is the leftover the debt was about, and keeping it is still right: the address
may be reached by something without a bookmark, and trust is about the endpoint
rather than the bookmark. The badge is a hint and not a verdict, which is why
nothing acts on it. Matched case-insensitively, because a host name is, and
because a list that called DB.internal unused next to a host saved as
db.internal would be inviting somebody to delete trust they rely on.

Forgetting goes through the same ForgetAsync as the host editor's button, which
withdraws every pin for the address rather than the selected row. Deliberate:
somebody who has stopped trusting a machine has not decided to keep trusting one
of its keys, and a second pin under another algorithm would go on being offered
at the next handshake — which reads as a withdrawal that did not work. The
status line says how many went, and the change is pushed immediately, because
the other machines are the ones still refusing to connect to a rebuilt server.

The list is read through the repository rather than through VaultKnownHostStore,
whose snapshot is shaped for the SSH handshake: one pin per endpoint,
deduplicated, no entity ids. This list has to show duplicates, because a
duplicate is one of the things worth seeing.

Two mutations, both caught: calling every pin dialled (3 tests), and defaulting
the selection to the first row (1) — the same hazard as the credential list,
since Forget acts on the selection.

The selector now holds four buttons in 340 pixels, and TheSelectorIsBigEnoughToClick
measures how much of that they use rather than leaving a fifth section to
discover it as "a button falls outside the window".

936 tests green across 16 projects, 6 of them new. Zero warnings, format clean.

Not verified: how the section looks. It joins the list in outstanding item #7.
This commit is contained in:
2026-07-30 17:44:33 +02:00
parent f86791e817
commit d162271a45
5 changed files with 384 additions and 1 deletions
@@ -1726,6 +1726,123 @@ public sealed class ShellFlowTests : IAsyncLifetime
vault.ShowsHosts.ShouldBeTrue();
}
// ---- Pinned host keys ----
/// <remarks>
/// The list that did not exist. Trust was created by the connect prompt and withdrawn from one host's
/// editor, so a pin for a host that had since been deleted or re-addressed was unreachable from the
/// interface entirely — it went on refusing connections, and nothing in the application would admit it
/// was there.
/// </remarks>
[Fact]
public async Task ThePinnedKeyList_ShowsWhatWasApprovedAndWhatNothingUsesAnyMore()
{
var vault = await ReadyToConnectAsync();
await knownHosts.TrustAsync(
new HostKeyPresentation("db.internal", 22, "ssh-ed25519", "SHA256:the-key"), Token);
await knownHosts.TrustAsync(
new HostKeyPresentation("gone.internal", 22, "ssh-ed25519", "SHA256:another-key"), Token);
// Pushed, as the connect path pushes a pin the moment it is approved. Without this both rows would
// be badged "not synced", which is true and would drown out the badge this test is about.
await vault.SyncCommand.ExecuteAsync(null);
await vault.LoadAsync(Token);
vault.KnownHostPins.Count.ShouldBe(2);
var dialled = vault.KnownHostPins
.Single(pin => string.Equals(pin.Host, "db.internal", StringComparison.Ordinal));
dialled.IsDialledByAHost.ShouldBeTrue("ReadyToConnectAsync's host is at db.internal:22");
dialled.Fingerprint.ShouldBe("SHA256:the-key", "in full, because that is what gets compared");
dialled.Badge.ShouldBeEmpty();
var orphan = vault.KnownHostPins
.Single(pin => string.Equals(pin.Host, "gone.internal", StringComparison.Ordinal));
orphan.IsDialledByAHost.ShouldBeFalse();
orphan.Badge.ShouldBe("no host uses this");
}
[Fact]
public async Task DeletingAHost_LeavesItsPinBehindAndTheListSaysSo()
{
// The behaviour the debt was about, now visible instead of silent. Keeping the pin is right — the
// address may still be reached by something else, and trust is about the endpoint rather than the
// bookmark — so the fix was never to cascade the delete. It was to stop the leftover being invisible.
var vault = await ReadyToConnectAsync();
await knownHosts.TrustAsync(
new HostKeyPresentation("db.internal", 22, "ssh-ed25519", "SHA256:the-key"), Token);
await vault.LoadAsync(Token);
vault.KnownHostPins.ShouldHaveSingleItem().IsDialledByAHost.ShouldBeTrue();
vault.SelectedHost = vault.Hosts[0];
await vault.DeleteHostCommand.ExecuteAsync(null);
vault.KnownHostPins.ShouldHaveSingleItem().IsDialledByAHost.ShouldBeFalse(
"the pin outlives the host, and the list has to admit it");
}
[Fact]
public async Task ForgettingAPinFromTheList_WithdrawsEveryKeyForThatAddress()
{
// One address, two algorithms, one decision. Somebody withdrawing trust from a machine has not
// decided to keep trusting one of its keys — and a pin left behind would go on being offered at the
// next handshake, which reads as a withdrawal that did not work.
var vault = await ReadyToConnectAsync();
await knownHosts.TrustAsync(
new HostKeyPresentation("db.internal", 22, "ssh-ed25519", "SHA256:the-ed25519-key"), Token);
await knownHosts.TrustAsync(
new HostKeyPresentation("db.internal", 22, "ecdsa-sha2-nistp256", "SHA256:the-ecdsa-key"), Token);
await vault.LoadAsync(Token);
vault.KnownHostPins.Count.ShouldBe(2);
vault.SelectedKnownHost = vault.KnownHostPins[0];
await vault.ForgetPinCommand.ExecuteAsync(null);
vault.KnownHostPins.ShouldBeEmpty();
vault.Status.ShouldContain("2 pinned key(s)");
// And it reached the vault, not just the snapshot: the next connection has to ask again.
(await knownHosts.FindAsync("db.internal", 22, "ssh-ed25519", Token)).ShouldBeNull();
// Pushed straight away, as trusting is — the other machines are the ones still refusing.
vault.PendingChanges.ShouldBe(0);
}
[Fact]
public async Task ForgettingWithNothingSelected_DoesNothing()
{
var vault = await ReadyToConnectAsync();
await knownHosts.TrustAsync(
new HostKeyPresentation("db.internal", 22, "ssh-ed25519", "SHA256:the-key"), Token);
await vault.LoadAsync(Token);
vault.SelectedKnownHost.ShouldBeNull("loading must not select a pin, because Forget acts on it");
await vault.ForgetPinCommand.ExecuteAsync(null);
vault.KnownHostPins.ShouldHaveSingleItem();
}
[Fact]
public async Task ThePinSectionIsReachableAndTakesItsTurn()
{
await UnlockedAsync();
var vault = shell.Vault!;
vault.ShowSectionCommand.Execute(VaultSection.KnownHosts);
vault.ShowsKnownHosts.ShouldBeTrue();
vault.ShowsHosts.ShouldBeFalse();
vault.ShowsKeys.ShouldBeFalse();
vault.ShowsCredentials.ShouldBeFalse();
}
// ---- Helpers ----
private static CancellationToken Token => TestContext.Current.CancellationToken;