fix: [processor/signingprocessor] scalar type collision

[hilmarf]

Description

PutInt("k", 123) and PutStr("k", "123") produced identical canonical JSON, so one signature covered both values. Each scalar type is now wrapped in a single-key object keyed by type name (matching OTLP/JSON conventions), making every type distinct.

Existing signatures are invalidated by this change, but the component is in development state.

SeverityNumber and SeverityText are no longer included in the signed payload; the audit logging spec marks them as SHOULD NOT.

Link to tracking issue

follow up on: #50884

Testing

added new TestScalarTypeCollision

Documentation

README.md updated

Authorship

• I, a human, wrote this pull request description myself.

[hilmarf]

@surpradhan what do you think? That should close the scalar collision gap, right? It's a follower of #50884

[surpradhan]

Yes @hilmarf, that closes it. I ran the pairs against the branch and they all separate now:

int 123 / str "123"        distinct
int -5  / str "-5"         distinct
bytes 0xDEAD / str "3q0="  distinct
int 123 / double 123.0     distinct
[int 7] / [str "7"]        distinct

One non-blocking note : TestScalarTypeCollision covers the four scalar pairs but not negatives or containers. PutInt(-5) vs PutStr("-5"), and a slice of int 7 vs a slice of str "7", would pin the recursion path, which is where I would expect a future refactor to regress it.

[opentelemetry-pr-dashboard]

Pull request dashboard status

Waiting on reviewers · refreshed 2026-09-11 07:01 UTC

Review the latest changes.

Status above doesn't look right?

• Just replied or pushed? Anything around or after the refresh time above may not be picked up yet — give it a few minutes.
• Anything look wrong? Report it with what you expected; it helps us improve the dashboard.

[hilmarf]

One non-blocking note : TestScalarTypeCollision covers the four scalar pairs but not negatives or containers. PutInt(-5) vs PutStr("-5"), and a slice of int 7 vs a slice of str "7", would pin the recursion path, which is where I would expect a future refactor to regress it.

addressed in 7408cf7

[hilmarf]

@surpradhan other edge cases I should cover? If not, please approve the PR. Thanks a lot for your valuable inputs. It's good to have someone else, being familiar with the pitfalls of canonization.

[surpradhan]

@hilmarf, I just ran them plus a few more, it looks right.

One pair left: -0.0 and +0.0 both come out as {"doubleValue":0}, so they share a signature. That's RFC 8785 doing what Appendix B says rather than the library misbehaving, so you may well decide if it isn't worth chasing. It's just the last colliding pair I can find.

Approving. Enjoyed poking at this one.