See #2091 for full context, as well as a fixing (but backwards-incompatible) patch. I'm filing this as a separate issue so that it can be tracked for Rekor's v2 series 🙂
TL;DR:
Rekor uses an OpenAPI spec written in Swagger 2.0
The OpenAPI spec currently includes a LogEntry.body definition with type: object, which doesn't reflect the actual type of body in practice (in practice it's actually a base64 string, i.e. type: string)
This would have caused problems in the Go code except that Go generates type: object as interface, meaning that the mis-typing was silently ignored and is now baked into the public API for Rekor.
As such, changing LogEntry.body to type: string can't be done until Rekor v2.
Alternatives considered:
Fixing it now: this can't be done, since it incurs backwards-incompatible changes to the generated Go clients. These changes are mostly trivial (going from interface.(string) to using string directly), but are still incompatible and therefore must wait until v2.
See #2091 for full context, as well as a fixing (but backwards-incompatible) patch. I'm filing this as a separate issue so that it can be tracked for Rekor's v2 series 🙂
TL;DR:
LogEntry.bodydefinition withtype: object, which doesn't reflect the actual type ofbodyin practice (in practice it's actually a base64 string, i.e.type: string)type: objectasinterface, meaning that the mis-typing was silently ignored and is now baked into the public API for Rekor.LogEntry.bodytotype: stringcan't be done until Rekor v2.Alternatives considered:
interface.(string)to usingstringdirectly), but are still incompatible and therefore must wait until v2.oneOfin the OpenAPI definition: this doesn't work, since the current OpenAPI spec used is Swagger 2.0, which does not supportoneOf. This could be fixed by upgrading from Swagger 2.0 to OpenAPI 3.0 (https://github.com/sigstore/rekor/issues/1729), but this is itself blocked by go-swagger's intentional lack of support for OAPI 3.0 (https://github.com/go-swagger/go-swagger/issues/1122)