Public Access
Free the terminal from the Hosts screen, and fill the room it left
The WebView sat inside the Hosts grid, so navigating to Files or the keychain hid every open terminal and the strip that named them. A connection you had opened was invisible from four of the five screens. The window now has two surfaces rather than one: a nav rail that says which page you are on, and a terminal strip that is always there and switches the whole content area to a shell. Screen keeps meaning "which page" and never becomes a sixth kind of page, which is why this is two properties instead of one enum with a terminal member in it. Every screen lives inside one wrapper panel that collapses when a terminal is showing. That is not tidiness — the WebView hosts a Win32 child window that composites above everything Avalonia draws, so a screen left visible over its rectangle is a screen sliced in half, and this window has shipped that defect once already. One decision point, IsTerminalShowing, and a nested panel rather than five compound bindings nobody would remember to extend. The focus choreography is the part no test in this repo can see. Every reveal path now focuses in the same turn the WebView appeared, so all three of them post at DispatcherPriority.Loaded and let the native control re-push its bounds first. Going the other way had a real bug: the screen-changed branch called a bare Focus() where it had to release the keyboard from the native child, so switching from a terminal to Files silently ate the first keystrokes. Rare before this commit and the primary gesture after it. The tab strip grew a cross inside each tab, a plus that opens the quick-connect palette, and middle-click close. Nested buttons are correct here: Avalonia handles a left press on the cross and deliberately does not handle other buttons, which is exactly what lets middle-click bubble up from the cross as well as the tab. The test is PointerUpdateKind rather than IsMiddleButtonPressed, because the latter reports button state and is also true for a left press made while the middle button happens to be held. The handler is on the tab and not the strip, so the background closes nothing by construction. Plus opens the palette rather than a flyout, since a menu dropping into the WebView's rectangle may or may not composite above a child HWND and this repo does not make rendering claims it has not photographed. Everything a user reads now says keychain. The wire, the database and the cryptographic spec still say vault, deliberately: renaming those is a migration and a protocol change for a word. That split is written down rather than left to be rediscovered as an inconsistency. Four things that were squeezed into the keychain's category rail, or into nothing at all, now have screens. Pinned host keys get one, with fingerprints never truncated and a filter that matches them, because comparing what you have against what the operator published is the whole workflow; the approved date is read out of the item's UUIDv7 rather than added as a column, and says so, since it means first approval and not last use. Keys can be generated in the client, which needed the openssh-key-v1 container written by hand — there is no BCL or NSec helper, and the PKCS#8 route is unverified in the SSH library this uses. The armour carries no passphrase: encrypting it needs bcrypt_pbkdf, which is Blowfish with a swizzle, in a project whose crypto is otherwise entirely libsodium, for a protection the key's own remarks argue is redundant inside a vault. Generation fills the existing editor and stops, so SAVE stays the one thing that writes. ~/.ssh/config can be imported behind a preview that is ticked per row and writes nothing until the button; IdentityFile records the path and imports the key material only on an explicit opt-in, because reading somebody's private key into a vault is precisely the act this product exists to make deliberate. Match blocks and ProxyJump are reported rather than obeyed — one cannot be evaluated statically and the other has nothing behind it to route with, and a preview that implied otherwise would be worse than one that admits it. Files can be dragged in all four directions that are honestly available. Remote to Explorer does not ship and is not pretended to: the shell wants the bytes during the drop, which needs a virtual file and a native COM data object, outside what Avalonia offers. Note for the next person that Avalonia 12 replaced the drag model outright — DataObject and DataFormats are no-op stubs and IDataObject is not in the reference assembly, so every tutorial written for 11 does not compile here. Hosts can be grouped, flat and never nested. A parent id merged as a scalar lets two offline clients each re-parent A under B and B under A, producing a cycle inside an encrypted payload that no server can police and every reader would have to detect for ever. Membership lives in that payload rather than in the one plaintext concession ADR 0001 allows, whose test is that the relay cannot function without it — nothing on the server reads a group, so what plaintext would hand over is a clustering of the estate for nothing. The plaintext column reserved for it is dropped, provably always null, and the server now refuses a client that sends one; it was never populated, was copied on apply, and was not cleared on delete, so a group id would have outlived the host it described. Snippets insert through xterm rather than through the pump, because xterm is the only thing that knows whether the remote has bracketed paste on, and that is what makes a shell treat embedded newlines as text instead of as execute. The host process moves opaque bytes and never parses output, so it would have to guess, and guessing wrong runs every line. Running is off by default and the copy says the text goes into whatever is there — the terminal has no notion of being at a prompt, and may be in vi or at a password prompt with echo off, so the Enter the user presses themselves is the entire safety property. Connections and keychain changes are recorded as synced encrypted items, which is what makes them auditable by a team later and costs the server knowledge of connection rate and timing from row counts alone. ADR 0001 already concedes it cannot hide that class of metadata; the trade is now written into it rather than left implicit. A connection entry is written once, at close, which is what makes a synced log tractable: nothing to merge, one outbox row, no chance of colliding with itself. Live sessions come from memory, not from the log. The write is void by contract and posts to a bounded channel, because putting an encrypt-and-write on the teardown path of every session is how closing the application comes to take four seconds. A ticket opened before a lock still closes afterwards, since a shell outlives the vault. The activity log hooks the one generic repository every kind writes through, so it cannot miss a caller — which is also why the log kinds themselves declare they are not audited, or the first entry would write an entry about writing an entry. It records the names of the fields that changed and never their values; a log with an old password in it would be a plaintext credential store with no vault around it. Retention is 90 days or 5,000 entries, whichever bites first, pruned on the sync loop rather than on a second timer. That log traffic then broke the status line, which is worth recording because the fix is a shape and not a patch: background sync counted its own log rows as pushed items, so the quiet rule stopped being quiet and every action's message was overwritten a second later by a sync report. The report now separates log rows from user items and the rule reads the latter. S3 buckets appear as a remote in the file browser, behind the same interface an SFTP session implements, so the queue and both panes did not have to learn what they are talking to. Uploads go through a pipe, because the queue wants to write and the SDK wants to read; memory is then bounded by the part size instead of buffering a file to disk twice. Finally, the Windows device key store moved out of the session project, which was the one thing keeping it from being portable — everything else in it is platform-neutral, and a Windows CNG dependency in the middle of the vault code meant a second head could not reference it without dragging Windows along. The seam that made the move free was already there. docs/android-port.md is the audit behind that: what ports, what does not, in order of cost, the four decisions taken, and an inventory of every screen and state the interface has to carry, written so a design can be made from it directly. dotnet build, dotnet test and dotnet format --verify-no-changes are all clean: 1240 tests at zero warnings, including the end-to-end suite against real containers. The manual checks that headless Avalonia cannot make — the drag from Explorer, a generated key against a real host, twelve tabs at the minimum window width — are listed in docs/manual-checks.md and are still outstanding.
This commit is contained in:
+374
-3
@@ -16,6 +16,15 @@ namespace DodoSSH.Domain;
|
||||
/// it becomes an authenticated open TCP proxy into the operator's own network. A database CHECK
|
||||
/// constraint enforces the pairing so it cannot drift. See ADR 0004.
|
||||
/// </para>
|
||||
/// <para>
|
||||
/// <b>There is no group column, and there used to be one.</b> A <c>group_id</c> was reserved here from the
|
||||
/// first migration and never written by any shipped client; it was dropped when groups actually landed,
|
||||
/// because membership belongs inside <see cref="Payload"/>. The test ADR 0004 sets for a plaintext
|
||||
/// concession is that the server <em>cannot function</em> without the value, and nothing on the server reads
|
||||
/// a group — the client decrypts its own vault to draw the sidebar. What the column would have handed over
|
||||
/// is a clustering of the estate: which machines this user files together, for free, in the clear. See
|
||||
/// <see cref="VaultHostGroup"/>.
|
||||
/// </para>
|
||||
/// </remarks>
|
||||
public sealed class SshHost : IVaultItem
|
||||
{
|
||||
@@ -56,9 +65,6 @@ public sealed class SshHost : IVaultItem
|
||||
/// <summary>Target port. Permitted only when <see cref="RelayEnabled"/> is set.</summary>
|
||||
public int? Port { get; set; }
|
||||
|
||||
/// <summary>Owning group, for tree placement. Groups arrive in M2.</summary>
|
||||
public Guid? GroupId { get; set; }
|
||||
|
||||
/// <summary>
|
||||
/// Client-visible, monotonic item version. Used for optimistic concurrency on push, and
|
||||
/// deliberately distinct from the internal <c>xmin</c> guard, which is never exposed because
|
||||
@@ -315,3 +321,368 @@ public sealed class VaultKnownHostKey : IVaultItem
|
||||
/// <summary>Who last modified it.</summary>
|
||||
public Guid UpdatedByUserId { get; set; }
|
||||
}
|
||||
|
||||
/// <summary>
|
||||
/// A folder hosts can be filed under, as ciphertext.
|
||||
/// </summary>
|
||||
/// <remarks>
|
||||
/// <para>
|
||||
/// A group is a name and nothing else, so this row is the narrowest one in the schema: an envelope and its
|
||||
/// bookkeeping. There is no <c>parent_id</c> and no <c>name</c> column, and both absences are deliberate.
|
||||
/// </para>
|
||||
/// <para>
|
||||
/// <b>No parent, because groups are flat.</b> A nesting pointer merged by a scalar three-way merge lets two
|
||||
/// offline clients each re-parent A under B and B under A, and the result is a cycle the server cannot see —
|
||||
/// the pointer would be inside the payload, which the server cannot read — and which every client would then
|
||||
/// have to detect on every read, forever. Flat costs one level of organisation and removes a whole class of
|
||||
/// unrepairable state.
|
||||
/// </para>
|
||||
/// <para>
|
||||
/// <b>No name, for the reason <see cref="VaultKnownHostKey"/> has no host column.</b> A group name is not
|
||||
/// confidential the way a password is, but the set of names one person files their machines under is a
|
||||
/// description of the estate — "customer-a", "pci", "on-call" — and the server has no use for any of it. It
|
||||
/// sorts nothing; the client decrypts its own vault to draw a list.
|
||||
/// </para>
|
||||
/// <para>
|
||||
/// <b>Membership lives on the host, not here.</b> The alternative — a member id list in this payload — would
|
||||
/// make adding one host to a group a write to the group, so two clients adding two different hosts at once
|
||||
/// would collide on one item. <c>ThreeWayMerge</c> has no set merge, so that collision would resolve by one
|
||||
/// side winning and the other host quietly leaving the group. One pointer per host makes each of those two
|
||||
/// operations a write to a different item, which cannot collide at all.
|
||||
/// </para>
|
||||
/// </remarks>
|
||||
public sealed class VaultHostGroup : IVaultItem
|
||||
{
|
||||
/// <summary>Primary key. UUIDv7, generated by the client so a group can be created offline.</summary>
|
||||
public Guid Id { get; set; }
|
||||
|
||||
/// <summary>Owning vault.</summary>
|
||||
public Guid VaultId { get; set; }
|
||||
|
||||
/// <summary>Owning vault.</summary>
|
||||
public Vault? Vault { get; set; }
|
||||
|
||||
/// <summary>The encrypted group: a DSH1 envelope. Opaque to the server.</summary>
|
||||
public byte[] Payload { get; set; } = [];
|
||||
|
||||
/// <summary>The item's data key, wrapped under the vault key. Opaque.</summary>
|
||||
public byte[]? DataKeyWrap { get; set; }
|
||||
|
||||
/// <summary>Reserved for per-item content keys wrapped to individual users; see docs/crypto.md §3.</summary>
|
||||
public Guid? ContentKeyId { get; set; }
|
||||
|
||||
/// <summary>Vault key generation this payload was encrypted under.</summary>
|
||||
public int KeyGeneration { get; set; }
|
||||
|
||||
/// <summary>AAD rule version, enabling a lazy re-encrypt-on-write migration later.</summary>
|
||||
public short PayloadAadVersion { get; set; }
|
||||
|
||||
/// <summary>Client-visible, monotonic item version, used for <c>expectedVersion</c> checks.</summary>
|
||||
public int Version { get; set; }
|
||||
|
||||
/// <summary>Latest change-log sequence touching this row, so a delta pull can join directly.</summary>
|
||||
public long ChangeSequence { get; set; }
|
||||
|
||||
/// <summary>Creation timestamp.</summary>
|
||||
public DateTimeOffset CreatedAtUtc { get; set; }
|
||||
|
||||
/// <summary>Last modification timestamp.</summary>
|
||||
public DateTimeOffset UpdatedAtUtc { get; set; }
|
||||
|
||||
/// <summary>
|
||||
/// Soft-delete marker; a tombstone, so an offline client learns the group went away.
|
||||
/// </summary>
|
||||
/// <remarks>
|
||||
/// Deleting a group leaves every host that named it holding an id that resolves to nothing, and that is
|
||||
/// the intended outcome rather than an oversight: those hosts fall back to the ungrouped heading. The
|
||||
/// alternative is rewriting N host payloads inside one delete, which turns a single user action into N
|
||||
/// pushes, N outbox rows and N chances to merge against a change nobody made.
|
||||
/// </remarks>
|
||||
public DateTimeOffset? DeletedAtUtc { get; set; }
|
||||
|
||||
/// <summary>Who created it.</summary>
|
||||
public Guid CreatedByUserId { get; set; }
|
||||
|
||||
/// <summary>Who last modified it.</summary>
|
||||
public Guid UpdatedByUserId { get; set; }
|
||||
}
|
||||
|
||||
/// <summary>
|
||||
/// An S3-compatible bucket and the credentials that reach it, as ciphertext.
|
||||
/// </summary>
|
||||
/// <remarks>
|
||||
/// <para>
|
||||
/// <see cref="VaultCredential"/>'s shape, and it holds the same class of thing: a secret access key is a
|
||||
/// password by another name, and everything around it — the endpoint, the region, the bucket — describes
|
||||
/// somewhere the user keeps data. There is no plaintext column and there is no argument for one; the relay
|
||||
/// does not dial a bucket, so ADR 0004's single concession has no analogue here.
|
||||
/// </para>
|
||||
/// <para>
|
||||
/// <b>The endpoint is inside the payload even though it is often <c>s3.amazonaws.com</c>.</b> For everybody
|
||||
/// self-hosting MinIO or Ceph it is an address on their own network, which is precisely the thing the host
|
||||
/// table only stores in the clear when the relay cannot work without it. Nothing on the server dials this.
|
||||
/// </para>
|
||||
/// </remarks>
|
||||
public sealed class VaultObjectStore : IVaultItem
|
||||
{
|
||||
/// <summary>Primary key. UUIDv7, generated by the client so a bucket can be added offline.</summary>
|
||||
public Guid Id { get; set; }
|
||||
|
||||
/// <summary>Owning vault.</summary>
|
||||
public Guid VaultId { get; set; }
|
||||
|
||||
/// <summary>Owning vault.</summary>
|
||||
public Vault? Vault { get; set; }
|
||||
|
||||
/// <summary>The encrypted bucket and its keys: a DSH1 envelope. Opaque to the server.</summary>
|
||||
public byte[] Payload { get; set; } = [];
|
||||
|
||||
/// <summary>The item's data key, wrapped under the vault key. Opaque.</summary>
|
||||
public byte[]? DataKeyWrap { get; set; }
|
||||
|
||||
/// <summary>Reserved for per-item content keys wrapped to individual users; see docs/crypto.md §3.</summary>
|
||||
public Guid? ContentKeyId { get; set; }
|
||||
|
||||
/// <summary>Vault key generation this payload was encrypted under.</summary>
|
||||
public int KeyGeneration { get; set; }
|
||||
|
||||
/// <summary>AAD rule version, enabling a lazy re-encrypt-on-write migration later.</summary>
|
||||
public short PayloadAadVersion { get; set; }
|
||||
|
||||
/// <summary>Client-visible, monotonic item version, used for <c>expectedVersion</c> checks.</summary>
|
||||
public int Version { get; set; }
|
||||
|
||||
/// <summary>Latest change-log sequence touching this row, so a delta pull can join directly.</summary>
|
||||
public long ChangeSequence { get; set; }
|
||||
|
||||
/// <summary>Creation timestamp.</summary>
|
||||
public DateTimeOffset CreatedAtUtc { get; set; }
|
||||
|
||||
/// <summary>Last modification timestamp.</summary>
|
||||
public DateTimeOffset UpdatedAtUtc { get; set; }
|
||||
|
||||
/// <summary>Soft-delete marker; a tombstone, so an offline client learns the bucket went away.</summary>
|
||||
public DateTimeOffset? DeletedAtUtc { get; set; }
|
||||
|
||||
/// <summary>Who created it.</summary>
|
||||
public Guid CreatedByUserId { get; set; }
|
||||
|
||||
/// <summary>Who last modified it.</summary>
|
||||
public Guid UpdatedByUserId { get; set; }
|
||||
}
|
||||
|
||||
/// <summary>
|
||||
/// One connection that was made, as ciphertext.
|
||||
/// </summary>
|
||||
/// <remarks>
|
||||
/// <para>
|
||||
/// <b>Written once, at close, and never updated.</b> That single decision is what makes a synced log
|
||||
/// tractable: an entry that is created and then left alone needs no three-way merge, produces exactly one
|
||||
/// outbox row, and cannot collide with the unique index that allows one outbox row per item. A connection
|
||||
/// that is still open is shown from the workspace's own in-memory state instead, because that is where the
|
||||
/// truth about a running shell actually lives.
|
||||
/// </para>
|
||||
/// <para>
|
||||
/// <b>Synced, and that is a deliberate trade rather than the obvious choice.</b> A log kept on the machine
|
||||
/// that produced it cannot be read by an administrator, cannot survive a reinstall, and cannot be checked
|
||||
/// against anything. Keeping it here buys team auditing; what it costs is that the operator learns a user's
|
||||
/// connection <em>rate and timing</em> from row counts and <c>updated_at</c>, even though every field inside
|
||||
/// is sealed. ADR 0001 already concedes it cannot hide that class of metadata; this widens it, and says so.
|
||||
/// </para>
|
||||
/// <para>
|
||||
/// The shape is <see cref="VaultCredential"/>'s: an envelope and its bookkeeping, no plaintext column of any
|
||||
/// kind. Which machines somebody reaches and when is the single most revealing thing this schema could hold
|
||||
/// in the clear, which is exactly why it holds none of it.
|
||||
/// </para>
|
||||
/// </remarks>
|
||||
public sealed class VaultConnectionLogEntry : IVaultItem
|
||||
{
|
||||
/// <summary>Primary key. UUIDv7, generated by the client, so an entry can be written offline.</summary>
|
||||
public Guid Id { get; set; }
|
||||
|
||||
/// <summary>Owning vault.</summary>
|
||||
public Guid VaultId { get; set; }
|
||||
|
||||
/// <summary>Owning vault.</summary>
|
||||
public Vault? Vault { get; set; }
|
||||
|
||||
/// <summary>The encrypted entry: a DSH1 envelope. Opaque to the server.</summary>
|
||||
public byte[] Payload { get; set; } = [];
|
||||
|
||||
/// <summary>The item's data key, wrapped under the vault key. Opaque.</summary>
|
||||
public byte[]? DataKeyWrap { get; set; }
|
||||
|
||||
/// <summary>Reserved for per-item content keys wrapped to individual users; see docs/crypto.md §3.</summary>
|
||||
public Guid? ContentKeyId { get; set; }
|
||||
|
||||
/// <summary>Vault key generation this payload was encrypted under.</summary>
|
||||
public int KeyGeneration { get; set; }
|
||||
|
||||
/// <summary>AAD rule version, enabling a lazy re-encrypt-on-write migration later.</summary>
|
||||
public short PayloadAadVersion { get; set; }
|
||||
|
||||
/// <summary>
|
||||
/// Client-visible, monotonic item version.
|
||||
/// </summary>
|
||||
/// <remarks>
|
||||
/// Always 1 in practice, because nothing updates a log entry. The column stays because the shared write
|
||||
/// path needs it, and a kind that opted out of the version check would be a second write path.
|
||||
/// </remarks>
|
||||
public int Version { get; set; }
|
||||
|
||||
/// <summary>Latest change-log sequence touching this row, so a delta pull can join directly.</summary>
|
||||
public long ChangeSequence { get; set; }
|
||||
|
||||
/// <summary>Creation timestamp.</summary>
|
||||
public DateTimeOffset CreatedAtUtc { get; set; }
|
||||
|
||||
/// <summary>Last modification timestamp.</summary>
|
||||
public DateTimeOffset UpdatedAtUtc { get; set; }
|
||||
|
||||
/// <summary>
|
||||
/// Soft-delete marker; a tombstone, so an offline client learns the entry was pruned.
|
||||
/// </summary>
|
||||
/// <remarks>
|
||||
/// Retention is the only thing that deletes one of these, and it is a real tombstone that pushes — which
|
||||
/// is why it is rate-limited rather than run on a timer. A prune that did not sync would delete the same
|
||||
/// thousand entries again on every machine, for ever.
|
||||
/// </remarks>
|
||||
public DateTimeOffset? DeletedAtUtc { get; set; }
|
||||
|
||||
/// <summary>Who created it.</summary>
|
||||
public Guid CreatedByUserId { get; set; }
|
||||
|
||||
/// <summary>Who last modified it.</summary>
|
||||
public Guid UpdatedByUserId { get; set; }
|
||||
}
|
||||
|
||||
/// <summary>
|
||||
/// One create, edit or delete of a vault item, as ciphertext.
|
||||
/// </summary>
|
||||
/// <remarks>
|
||||
/// <para>
|
||||
/// <see cref="VaultConnectionLogEntry"/>'s shape and its write-once rule, for a different history: what
|
||||
/// changed in the keychain rather than what was connected to. The payload records the <em>names</em> of the
|
||||
/// fields that changed and never their values, which is the same rule ADR 0006 imposes on the server's own
|
||||
/// <c>detail</c> column. A log that recorded an old password would be a plaintext credential store with no
|
||||
/// vault around it.
|
||||
/// </para>
|
||||
/// <para>
|
||||
/// Note the deliberate asymmetry with the outbox, because it reads as a discrepancy otherwise: the outbox
|
||||
/// <em>coalesces</em> two edits of one item into a single pending row, and this log does not — two edits are
|
||||
/// two lines. The outbox describes what still has to be sent; this describes what somebody did.
|
||||
/// </para>
|
||||
/// </remarks>
|
||||
public sealed class VaultActivityLogEntry : IVaultItem
|
||||
{
|
||||
/// <summary>Primary key. UUIDv7, generated by the client, so an entry can be written offline.</summary>
|
||||
public Guid Id { get; set; }
|
||||
|
||||
/// <summary>Owning vault.</summary>
|
||||
public Guid VaultId { get; set; }
|
||||
|
||||
/// <summary>Owning vault.</summary>
|
||||
public Vault? Vault { get; set; }
|
||||
|
||||
/// <summary>The encrypted entry: a DSH1 envelope. Opaque to the server.</summary>
|
||||
public byte[] Payload { get; set; } = [];
|
||||
|
||||
/// <summary>The item's data key, wrapped under the vault key. Opaque.</summary>
|
||||
public byte[]? DataKeyWrap { get; set; }
|
||||
|
||||
/// <summary>Reserved for per-item content keys wrapped to individual users; see docs/crypto.md §3.</summary>
|
||||
public Guid? ContentKeyId { get; set; }
|
||||
|
||||
/// <summary>Vault key generation this payload was encrypted under.</summary>
|
||||
public int KeyGeneration { get; set; }
|
||||
|
||||
/// <summary>AAD rule version, enabling a lazy re-encrypt-on-write migration later.</summary>
|
||||
public short PayloadAadVersion { get; set; }
|
||||
|
||||
/// <inheritdoc cref="VaultConnectionLogEntry.Version" />
|
||||
public int Version { get; set; }
|
||||
|
||||
/// <summary>Latest change-log sequence touching this row, so a delta pull can join directly.</summary>
|
||||
public long ChangeSequence { get; set; }
|
||||
|
||||
/// <summary>Creation timestamp.</summary>
|
||||
public DateTimeOffset CreatedAtUtc { get; set; }
|
||||
|
||||
/// <summary>Last modification timestamp.</summary>
|
||||
public DateTimeOffset UpdatedAtUtc { get; set; }
|
||||
|
||||
/// <inheritdoc cref="VaultConnectionLogEntry.DeletedAtUtc" />
|
||||
public DateTimeOffset? DeletedAtUtc { get; set; }
|
||||
|
||||
/// <summary>Who created it.</summary>
|
||||
public Guid CreatedByUserId { get; set; }
|
||||
|
||||
/// <summary>Who last modified it.</summary>
|
||||
public Guid UpdatedByUserId { get; set; }
|
||||
}
|
||||
|
||||
/// <summary>
|
||||
/// A saved command, as ciphertext.
|
||||
/// </summary>
|
||||
/// <remarks>
|
||||
/// <para>
|
||||
/// <see cref="VaultCredential"/>'s shape exactly, and for a stronger reason than symmetry. A snippet is a
|
||||
/// command somebody runs on their infrastructure — <c>systemctl restart</c> against a named unit, a
|
||||
/// <c>psql</c> line naming a database — and read as a set it describes what the estate is made of at least
|
||||
/// as precisely as a list of hostnames does. There is nothing here the server could sort by that is worth
|
||||
/// what holding it would cost, so there is no plaintext column to put it in even by mistake.
|
||||
/// </para>
|
||||
/// <para>
|
||||
/// Whether the snippet runs on its own or merely gets typed into the terminal is inside the payload too, and
|
||||
/// that is worth stating: it is the field the whole feature's safety rests on, so it must be one that
|
||||
/// travels sealed and merges with everything else it belongs to, rather than a flag the server could see or
|
||||
/// change.
|
||||
/// </para>
|
||||
/// </remarks>
|
||||
public sealed class VaultSnippet : IVaultItem
|
||||
{
|
||||
/// <summary>Primary key. UUIDv7, generated by the client so a snippet can be written offline.</summary>
|
||||
public Guid Id { get; set; }
|
||||
|
||||
/// <summary>Owning vault.</summary>
|
||||
public Guid VaultId { get; set; }
|
||||
|
||||
/// <summary>Owning vault.</summary>
|
||||
public Vault? Vault { get; set; }
|
||||
|
||||
/// <summary>The encrypted snippet: a DSH1 envelope. Opaque to the server.</summary>
|
||||
public byte[] Payload { get; set; } = [];
|
||||
|
||||
/// <summary>The item's data key, wrapped under the vault key. Opaque.</summary>
|
||||
public byte[]? DataKeyWrap { get; set; }
|
||||
|
||||
/// <summary>Reserved for per-item content keys wrapped to individual users; see docs/crypto.md §3.</summary>
|
||||
public Guid? ContentKeyId { get; set; }
|
||||
|
||||
/// <summary>Vault key generation this payload was encrypted under.</summary>
|
||||
public int KeyGeneration { get; set; }
|
||||
|
||||
/// <summary>AAD rule version, enabling a lazy re-encrypt-on-write migration later.</summary>
|
||||
public short PayloadAadVersion { get; set; }
|
||||
|
||||
/// <summary>Client-visible, monotonic item version, used for <c>expectedVersion</c> checks.</summary>
|
||||
public int Version { get; set; }
|
||||
|
||||
/// <summary>Latest change-log sequence touching this row, so a delta pull can join directly.</summary>
|
||||
public long ChangeSequence { get; set; }
|
||||
|
||||
/// <summary>Creation timestamp.</summary>
|
||||
public DateTimeOffset CreatedAtUtc { get; set; }
|
||||
|
||||
/// <summary>Last modification timestamp.</summary>
|
||||
public DateTimeOffset UpdatedAtUtc { get; set; }
|
||||
|
||||
/// <summary>Soft-delete marker; a tombstone, so an offline client learns the snippet went away.</summary>
|
||||
public DateTimeOffset? DeletedAtUtc { get; set; }
|
||||
|
||||
/// <summary>Who created it.</summary>
|
||||
public Guid CreatedByUserId { get; set; }
|
||||
|
||||
/// <summary>Who last modified it.</summary>
|
||||
public Guid UpdatedByUserId { get; set; }
|
||||
}
|
||||
|
||||
@@ -48,6 +48,15 @@ public enum ChangeEntityType
|
||||
|
||||
/// <summary>A known SSH host key. M2.</summary>
|
||||
KnownHostKey = 10,
|
||||
|
||||
/// <summary>One connection that was made, and how long it lasted. M2.</summary>
|
||||
ConnectionLogEntry = 11,
|
||||
|
||||
/// <summary>One create, edit or delete of a vault item. M2.</summary>
|
||||
ActivityLogEntry = 12,
|
||||
|
||||
/// <summary>An S3-compatible bucket, and the credentials that reach it. M2.</summary>
|
||||
ObjectStore = 13,
|
||||
}
|
||||
|
||||
/// <summary>
|
||||
|
||||
Reference in New Issue
Block a user