0.6 prerelease… | Dstack-TEE/dstack

Comece pelos itens não marcados do SDK e da API versionada nesta checklist e, em seguida, leia docs/guest-api-v1.md, docs/guest-api-v0.md e o trabalho aberto em #1124. Revise as tarefas restantes de release do SDK e de documentação por SDK, os nomes opacos dos campos JSON e as representações de bytes do protobuf. Considera-se concluído quando os SDKs alterados forem lançados como 0.6.0, o schema v1 estiver corrigido e a documentação de referência tiver sido regenerada.

Objective

Ship dstack 0.6 with a stable, versioned guest-agent API and consistent Go, JavaScript/TypeScript, Python, and Rust SDKs. Existing 0.5.x clients must continue to work against a 0.6 agent.

Compatibility

Keep the unversioned API fully compatible with 0.5.x, verified with v0.5.10 generated clients and SDKs. — #1121 runs the released SDK suites against the current agent in CI. The pinned tags are v0.5.8 and v0.5.11, not v0.5.10: v0.5.10:sdk and v0.5.11:sdk are the same tree object, so running both bought nothing. Note the limit — old JSON clients ignore unknown keys, so this job catches breaking changes to the frozen surface but not additive ones; the shape freeze in frozen_surface is what covers additions.
Keep GetQuote unchanged: the v0.5 response fields and semantics remain the complete contract. Cross-platform attestation is exposed through Attest, not GetQuote.
Keep GetKey wire- and behavior-compatible. Publish a normative specification for path, purpose, supported algorithms, defaults, output encoding, and signature-chain verification. — spec in #1123 (docs/guest-api-v0.md), byte-level: HKDF salt, what enters the KDF vs only the claim, both chain-link preimages, all three signing modes, and the hazard that algorithm does not domain-separate.
Make EmitEvent return 404 with informative error message (deprecated method)
Unknown algorithms must be rejected.

Attestation

Make Attest the single API for platform and GPU attestation

SDKs

Release all changed SDKs as 0.6.0 and apply semantic versioning consistently.
Expose the same TlsKeyOptions fields and defaults in every SDK. usage_server_auth defaults to true; remove the unused path option. — #1120
Represent the TLS private key as PEM and provide an explicit toPkcs8Der() conversion. Remove ambiguous byte-conversion APIs. — resolved differently, deliberately. The ambiguous accessor is gone from v1 (#1120) and no toPkcs8Der() replaced it: v1 returns PEM and nothing else. The accessor existed to feed the key into the blockchain adapters, v1 has no chain-flavored surface, and DER is one standard-library call away for anyone who wants it. v0 keeps the accessor, because the adapters are v0-typed and that surface is frozen. Reopen this if a v1 caller turns up who needs DER from the SDK itself.
Represent protobuf byte fields as bytes in Rust, not hex strings. — #1124 (open), and in every SDK rather than Rust alone: eleven response fields plus report_data, with the decode_* helpers deleted. The JSON wire is unchanged.
Make all SDKs report non-2xx responses consistently, including the server error and HTTP status. — #1120, pinned by tests in #1120 that assert the exact status an image without nvattest answers.
Regenerate and review the protobuf, HTTP, and SDK reference documentation. — v1 and v0 both have written specs now (docs/guest-api-v1.md, docs/guest-api-v0.md) and sdk/curl/api.md was corrected, but the per-SDK reference docs have not been regenerated.

Versioned API (future)

Introduce the long-term API under a versioned URL/service namespace such as /prpc/v1/... and protobuf package dstack.guest.v1. API selection must not depend on request headers. — #1116; selection is by URL path alone.
Use *Request and *Response consistently for new messages. Keep the method name Attest.
Give opaque JSON fields explicit *_json names in v1, or use typed messages where the schema is stable. — not done. InfoResponse still carries app_compose, vm_config and key_provider_info as bare string fields whose comments say they are JSON documents passed through unparsed. v1 is unreleased, so this is still cheap to change.

Signing (future)

Provide Sign with an explicit key specification containing path, purpose, and algorithm. — v1 has no Sign; the frozen v0 Sign is now specified in docs/guest-api-v0.md.
Add GetSigningKey to return the corresponding public key and certification chain without signing a message. — v1 GetKey returns public_key and signature_chain alongside the key, which covers the use case but not as a separate method.
Provide signature verification as SDK functionality rather than an agent RPC. — #1110. v0's Verify RPC is still served for 0.5.x clients and is documented as frozen.
Specify the exact Ed25519 and secp256k1 message and prehashed modes. — done for the frozen v0 surface in #1123, including secp256k1_prehashed requiring the caller to supply the digest. v1 has no signing surface to specify.

0.6 prerelease checklist: stabilize guest-agent API and SDKs

Avaliação

Direção de pesquisa

Descrição

Objective

Compatibility

Attestation

SDKs

Versioned API (future)

Signing (future)

Preparar o ambiente

Primeiros passos

Mais de Dstack-TEE/dstack

Issues semelhantes

0.6 prerelease checklist: stabilize guest-agent API and SDKs

Algo errado?

Avaliação

Direção de pesquisa

Descrição

Objective

Compatibility

Attestation

SDKs

Versioned API (future)

Signing (future)

Preparar o ambiente

Primeiros passos

Mais de Dstack-TEE/dstack

Algo errado?

Algo errado?

Algo errado?

Algo errado?

Algo errado?

Issues semelhantes

Algo errado?

Algo errado?

Algo errado?

Algo errado?

Algo errado?

Receba novas issues na sua caixa de entrada