Sync credentials as a vault item type, and bind one to a host

Closes the largest remaining M1 gap in the data layer: a username and password
can live in the vault, sync between machines, and be named by a host as how it
authenticates. What is not here is the interface for creating one — see the end
of this message.

The third item type, and the first one that cost almost nothing to add. Server:
a VaultCredential row, an EF configuration, a migration, and a CredentialKind.
Client: a secret, a codec, a merge, a cipher, a kind, a repository facade and a
session property. No new reconciliation logic, no change to the sync engine, no
client cache migration. That was the whole point of the item-kind seam, and this
is the evidence it holds.

The narrowest type of the three on plaintext, and not for symmetry. A host has a
deliberate concession — the relay needs an address it can resolve. A key has a
fingerprint, public by nature, which this client still declines to send. A
password has no part that is safe to expose: not its length, not a hash, not a
hint. So CredentialKind refuses every plaintext field there is, hydrates none,
and the table has no column to put one in.

HostSecret.CredentialId is the password counterpart of SshKeyId, and the two are
mutually exclusive. SSH itself would happily try a key and fall back to a
password, but a host naming both leaves "how does this authenticate?" without a
single answer — the interface, the connect path and the user would each be free
to guess differently. TryValidate refuses it. One consequence was not
anticipated: "a full host" stops being a coherent idea, which is what broke
AFullHost_RoundTrips and is now written into that test.

The schema version became a ladder rather than a maximum: credential-bound is 3,
key-bound is 2, neither is still 1. Adding credentials therefore does not drag
every key-bound host in every vault onto a version that clients understanding
keys perfectly well would refuse to edit. A test pins exactly that, because it is
the property the whole content-dependent-version rule exists to provide, and the
obvious implementation would quietly lose it.

Two tests had become false and said so:

- Push_AnUnsupportedEntityType_IsInvalidNotAFailedBatch used Credential as its
  example of a type this server does not implement. It now asks the server's own
  registry what is still missing, so it cannot go stale again, and skips with a
  reason if that set ever empties.
- ThePullFilterNamesEveryTypeThisBuildSynchronises pinned the exact list, which
  is what it is for.

Also fixes ten nullable warnings — eight in SyncEndpointTests, two in a test file
added earlier today. Neither set was introduced here; both were invisible until
an unrelated change forced their project to recompile, which means the
zero-warning claims made earlier in this work only ever covered what happened to
be rebuilt.

777 tests green. Zero warnings, dotnet format clean.

Not done, and deliberately: the credential interface. The vault column is 340
pixels wide and already holds two lists and two editors, kept from clipping its
own buttons at the window's minimum height only by the one-editor-at-a-time rule
added earlier today. A third list and a third editor would recreate that defect
rather than avoid it, so the column needs a shape decision first. Credentials
sync; they cannot yet be created in the interface.
This commit is contained in:
2026-07-29 21:09:08 +02:00
parent 70b3290a77
commit e24012b039
27 changed files with 2812 additions and 23 deletions
+150 -1
View File
@@ -584,6 +584,19 @@ public sealed class SyncEndpointTests(ApiFixture fixture)
{
// A newer client asking for something this server does not do yet gets a precise
// per-operation answer rather than a whole-batch rejection.
//
// The type is taken from the server's own registry rather than named, and that is not fussiness. This
// test used to name Credential, and implementing credentials turned it into a test asserting the
// opposite of the truth — it failed loudly, but a differently-shaped test would have gone quiet
// instead. Asking the registry what is still missing keeps it aimed at the branch it was written for.
var unsupported = Enum.GetValues<SyncEntityType>()
.Where(type => type != SyncEntityType.Unspecified)
.FirstOrDefault(type => Features.Sync.ItemKinds.For(type) is null);
Assert.SkipWhen(
unsupported == SyncEntityType.Unspecified,
"Every entity type in the contract is implemented, so this branch is no longer reachable.");
var (subject, vaultId) = await SeedUserWithVaultAsync();
var client = fixture.CreateClientFor(subject);
@@ -591,7 +604,7 @@ public sealed class SyncEndpointTests(ApiFixture fixture)
[
new SyncPushOperation(
Guid.CreateVersion7(),
SyncEntityType.Credential,
unsupported,
Guid.CreateVersion7(),
SyncOperation.Upsert,
null,
@@ -665,6 +678,125 @@ public sealed class SyncEndpointTests(ApiFixture fixture)
/// separately and then put them back in the log's order, because a client's cursor cannot resume from a
/// sequence that was regrouped.
/// </remarks>
[Fact]
public async Task ACredential_RoundTripsAsCiphertextWithNoPlaintextAtAll()
{
var (subject, vaultId) = await SeedUserWithVaultAsync();
var client = fixture.CreateClientFor(subject);
var credentialId = Guid.CreateVersion7();
var pushed = await client.PostContractAsync(
PushUrl(vaultId),
new SyncPushRequest(
[CredentialOperation(credentialId, expectedVersion: null, envelope: [7, 7, 7])]));
var results = await pushed.Content.ReadContractAsync<SyncPushResponse>();
results!.Results.ShouldHaveSingleItem().Status.ShouldBe(SyncOperationStatus.Applied);
var pulled = await client.PostContractAsync(
PullUrl(vaultId),
new SyncPullRequest(null, null, [SyncEntityType.Credential]));
var page = await pulled.Content.ReadContractAsync<SyncPullResponse>();
var change = page!.Changes.ShouldHaveSingleItem();
change.EntityType.ShouldBe(SyncEntityType.Credential);
change.EntityId.ShouldBe(credentialId);
change.Payload.ShouldNotBeNull().Envelope.ShouldBe([7, 7, 7]);
change.PlaintextFields.ShouldBeNull(
"a credential has no plaintext columns, so a pull has nothing to hydrate");
}
[Fact]
public async Task ACredentialCarryingPlaintextFields_IsRejected()
{
// Refused rather than dropped. A client that thinks it is storing something and is not will be
// surprised later, and for this type "something" would be a detail about a password.
var (subject, vaultId) = await SeedUserWithVaultAsync();
var client = fixture.CreateClientFor(subject);
var operation = new SyncPushOperation(
Guid.CreateVersion7(),
SyncEntityType.Credential,
Guid.CreateVersion7(),
SyncOperation.Upsert,
null,
Payload([1, 2, 3]),
new SyncPlaintextFields(RelayEnabled: true, Hostname: "db.internal", Port: 22));
var pushed = await client.PostContractAsync(PushUrl(vaultId), new SyncPushRequest([operation]));
var result = (await pushed.Content.ReadContractAsync<SyncPushResponse>())!.Results
.ShouldHaveSingleItem();
result.Status.ShouldBe(SyncOperationStatus.Invalid);
result.Detail.ShouldNotBeNull().ShouldContain("no relay target");
}
[Fact]
public async Task ACredentialWithAFingerprint_IsRejected()
{
// The one plaintext field a key may carry, refused here. A password has no public half, so a client
// sending one is confused about what it is storing.
var (subject, vaultId) = await SeedUserWithVaultAsync();
var client = fixture.CreateClientFor(subject);
var operation = new SyncPushOperation(
Guid.CreateVersion7(),
SyncEntityType.Credential,
Guid.CreateVersion7(),
SyncOperation.Upsert,
null,
Payload([1, 2, 3]),
new SyncPlaintextFields(PublicKeyFingerprint: "SHA256:whatever"));
var pushed = await client.PostContractAsync(PushUrl(vaultId), new SyncPushRequest([operation]));
var result = (await pushed.Content.ReadContractAsync<SyncPushResponse>())!.Results
.ShouldHaveSingleItem();
result.Status.ShouldBe(SyncOperationStatus.Invalid);
result.Detail.ShouldNotBeNull().ShouldContain("no public key");
}
[Fact]
public async Task ThreeItemTypesWithOneId_AreThreeSeparateItems()
{
// The tables are separate, so one id may name a host, a key and a credential at once. Not something a
// client would do — ids are UUIDv7 — but if the write path ever confused two types, this is the test
// that says so rather than a mystery about a missing item.
var (subject, vaultId) = await SeedUserWithVaultAsync();
var client = fixture.CreateClientFor(subject);
var sharedId = Guid.CreateVersion7();
var pushed = await client.PostContractAsync(
PushUrl(vaultId),
new SyncPushRequest(
[
NewOperation(sharedId, expectedVersion: null, envelope: [1, 1]),
KeyOperation(sharedId, expectedVersion: null, envelope: [2, 2]),
CredentialOperation(sharedId, expectedVersion: null, envelope: [3, 3]),
]));
(await pushed.Content.ReadContractAsync<SyncPushResponse>())!.Results
.ShouldAllBe(result => result.Status == SyncOperationStatus.Applied);
var pulled = await client.PostContractAsync(
PullUrl(vaultId),
new SyncPullRequest(null, null, null));
var page = await pulled.Content.ReadContractAsync<SyncPullResponse>();
page!.Changes.Count.ShouldBe(3);
page.Changes.ShouldAllBe(change => change.EntityId == sharedId);
page.Changes.Select(change => change.EntityType).Order().ShouldBe(
[SyncEntityType.Host, SyncEntityType.Credential, SyncEntityType.SshKey]);
}
[Fact]
public async Task APullMixingHostsAndKeys_ReturnsBothInLogOrder()
{
@@ -776,6 +908,23 @@ public sealed class SyncEndpointTests(ApiFixture fixture)
/// <c>PlaintextFields: null</c> rather than an empty instance, which is what a real client sends for a
/// type with no plaintext columns — and what the server must accept without inventing defaults.
/// </remarks>
/// <remarks>
/// Like <see cref="KeyOperation"/> with even less: a credential has no plaintext column at all, not even
/// the fingerprint a key may carry, so this is the narrowest an operation gets.
/// </remarks>
private static SyncPushOperation CredentialOperation(
Guid entityId,
int? expectedVersion,
byte[] envelope) =>
new(
Guid.CreateVersion7(),
SyncEntityType.Credential,
entityId,
SyncOperation.Upsert,
expectedVersion,
Payload(envelope),
PlaintextFields: null);
private static SyncPushOperation KeyOperation(Guid entityId, int? expectedVersion, byte[] envelope) =>
new(
Guid.CreateVersion7(),