Skip to content

fix(template): change UpdateTemplateArg.KeyUsage to *int to match Command API#58

Open
spbsoluble wants to merge 1 commit into
v3from
fix/template-update-keyusage-int
Open

fix(template): change UpdateTemplateArg.KeyUsage to *int to match Command API#58
spbsoluble wants to merge 1 commit into
v3from
fix/template-update-keyusage-int

Conversation

@spbsoluble

Copy link
Copy Markdown
Collaborator

Summary

UpdateTemplateArg.KeyUsage is currently typed *bool in both v3/api/template_models.go and v2/api/template_models.go. Command's live API disagrees:

  • TemplateUpdateRequest.KeyUsage and TemplateRetrievalResponse.KeyUsage are both {"type":"integer","format":"int32"} per the v25.5 swagger — an int32 bitmask (e.g. 160 = digitalSignature|keyEncipherment).
  • GetTemplateResponse.KeyUsage in this repo is already typed int, so the get/update models disagree with each other on top of disagreeing with the server.
  • Sending a bool payload against a live v25.5 Command instance produces an HTTP 400: Unexpected character encountered while parsing value: t. Path 'KeyUsage'.

This makes the field unusable as-is for any caller trying to round-trip KeyUsage through a template update.

Change

  • v3/api/template_models.go: UpdateTemplateArg.KeyUsage *bool*int.
  • v2/api/template_models.go: same fix, for consistency (v2 is tagged/released independently of v3 and is not part of the v3.6.0 target for this change).
  • v3/api/template_test.go: adds TestUpdateTemplateArg_KeyUsage_SerializesAsInt, which fails to compile against the pre-fix *bool field and asserts the JSON payload sent to Command is a number, not a boolean.

This is a breaking type change, but the field was non-functional beforehand (any real use hit the 400 above), so there's no working caller to break. Targeted for v3.6.0.

Test plan

  • GOWORK=off go build ./... (v3 module)
  • GOWORK=off go vet ./... (v3 module)
  • GOWORK=off go test ./... (v3 module) — full suite passes, including the new regression test
  • GOWORK=off go build ./... (v2 module) — builds clean (pre-existing, unrelated go vet failure in v2/api/client_test.go confirmed present before this change too, via git stash)

…mand API

Command's TemplateUpdateRequest.KeyUsage and TemplateRetrievalResponse.KeyUsage
are both {"type":"integer","format":"int32"} per the v25.5 swagger — an int32
bitmask (e.g. 160 = digitalSignature|keyEncipherment). UpdateTemplateArg.KeyUsage
was typed *bool, which serializes as a JSON boolean and produces a live HTTP 400
from Command ("Unexpected character encountered while parsing value: t. Path
'KeyUsage'"), making the field unusable as-is.

GetTemplateResponse.KeyUsage was already int, so this also fixes the type
mismatch between the get and update models for the same field.

Also fixes the identical defect in v2/api/template_models.go for consistency;
v2 is tagged/released independently and is not part of this v3.6.0 change.

Adds TestUpdateTemplateArg_KeyUsage_SerializesAsInt to v3/api/template_test.go,
which fails to compile against the pre-fix *bool field and asserts the wire
payload is a JSON number.
spbsoluble added a commit to keyfactor-pub/terraform-provider-keyfactor that referenced this pull request Jul 22, 2026
buildTemplateRoleBindingUpdateArg never carried KeyUsage from GetTemplate
onto the UpdateTemplate request, so every role attach/detach silently
reset the template's KeyUsage bitmask to 0 on Command even though this
resource does not manage KeyUsage at all. Command's UpdateTemplate is a
full replacement (PR #180
context), so any omitted field is cleared server-side.

Pin keyfactor-go-client/v3 v3.6.0-rc.0 (Keyfactor/keyfactor-go-client#58),
which changes UpdateTemplateArg.KeyUsage from *bool to *int to match
Command's v25.5 wire format (int bitmask on both GET and PUT; a JSON
boolean is rejected with HTTP 400). Use the non-collapsing pointer
pattern already established in this function so a KeyUsage of 0 round-
trips instead of being dropped by omitempty.

TestUnitTemplateRoleBindingUpdatePreservesKeyUsage reproduces the wipe
end-to-end against a mock Command server (GET returns KeyUsage 160,
capture the PUT body) and fails on the unfixed code with the PUT body
carrying no KeyUsage field at all.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant