gateway v0.4.0
A minor release of the attested-input gateway: three changes since v0.3.1. gateway-connections gains personal file management for Google Drive, Amazon S3 and local Obsidian vaults, as a control surface apart from the engine. An operator may give a source a timeout of up to seven days. The document adapter's page walk reads its deadline in one more place.
Personal storage file management (#166)
gateway-connections can now browse a connected store and make file changes a person has reviewed, for Google Drive, Amazon S3 and an existing local Obsidian vault. Catalog version 3 advertises five operations for those three providers: files-list, files-read, files-prepare, files-commit and files-status. The earlier catalog, the attachment operations, the signed acquisition formats and SPEC.md are unchanged.
This is not an engine surface. ADR-0005 places it beside the connection controls, apart from /acquire and /act. It issues no evidence receipt and no action receipt, and it keeps no audit log: one pending or recent plan is retained per connection, for recovery only. An engine-governed write still goes through /act, and the README now says so in those words. A host must not expose files-commit as an assistant tool or as a scheduled job's action.
How a change is made:
files-preparefreezes the target, the content, the base revision and the connection generation into a plan, and changes no file. A plan expires five minutes after it is prepared.- The host shows the plan for review. A deletion also needs the exact filename, or the full S3 key, given back as confirmation.
files-commitrecords its claim durably before it sends a change, and never sends one twice. No provider request is retried. A transport failure or an unexpected provider response is reported asneeds-attention: inspect the source before starting another change.
What a change does, by provider:
| Provider | Create | Update | Delete |
|---|---|---|---|
| Amazon S3 | If-None-Match: * |
If-Match on the reviewed ETag |
If-Match on the reviewed ETag. No version ID is supplied, so deletion in an unversioned bucket can be permanent. |
| Google Drive | under an ID reserved at preparation | If-Match on a strong ETag; refused as conditional-write-unavailable where Drive returns none |
sets trashed=true; never a permanent deletion |
| Local vault | exclusive | rechecks the content digest and keeps the previous bytes under .jpack-history/ |
moves the file under .jpack-trash/ |
Bounds: a listing returns at most 24 entries, and a file read or upload is at most 4 MiB. A disconnect or reconfiguration invalidates every selection and plan made before it.
Permissions do not change by upgrading. The Drive scope remains drive.file, so only files already authorized through it are visible. S3 changes need s3:PutObject or s3:DeleteObject granted separately on the selected prefix; the gateway does not change IAM.
What this does not establish:
- The confirmation is a consent mechanism in a trusted host, not cryptographic proof that a person intended the change. Programs running as the same OS user are inside the trust boundary.
- A local recheck cannot rule out a race with another editor of the same vault.
- The tests use temporary vaults and TLS stand-ins for the providers. No change has been made against a live Google or AWS account.
docs/design/storage-files.md states the protocol, the discovery budgets and the failure handling.
Source timeouts up to seven days (#162)
--source-timeout NAME=SECONDS now accepts up to 604800 seconds, seven days, where the ceiling was 600. The default stays thirty seconds, and a source given no timeout of its own behaves as before. Each adapter keeps its own limit: set it below the gateway's timeout, with time left for cleanup and reporting.
The gateway still retains nothing between calls. A caller that must wait through a long read keeps the wait, and the response, in its own process. The gateway stores no request it could replay and no commitment salt. docs/design/durable-operations.md states that boundary and what an interruption leaves uncertain.
The page walk reads its deadline as it passes over kids (#165, closing #161)
A page-tree node may name, among its kids, a node the walk already stands under, and the walk passes over each such kid. It read no deadline as it did. A node that named itself a million times was gone through with none read, and a deadline that passed there was recorded as pdf-malformed instead of timeout. The walk now reads the deadline every 4,096 kids it passes over, and docs/design/attachments.md step 4 says so.
#161 listed fourteen other places, in decoding and decryption, that observe the deadline late and record it all the same. They are accepted as they are, for the reasons given on the issue: every adapter that parses a document is a process the gateway ends at its source timeout, and the attachments note already says an operation between two checks runs to its end.
Review
#165 went through the gateway's cross-vendor review regime, in one round. #162 and #166 were each reviewed by a model of the drafting vendor's own, in a separate context, under an explicit maintainer exception recorded on the pull request. Neither is represented as a different-vendor review. The review of #162 rejected its first candidate, which was replaced. The review of #166 requested changes, which were made and rechecked before the merge. Every record and disposition is on the pull requests.
The frozen corpus is unchanged: 30 canon vectors and 41 store vectors, and gateway conform reports 0 disagreements on the tagged source.