Skip to content

Miscellaneous updates and fixes - #45

Merged
setrofim merged 11 commits into
mainfrom
setrofim/misc
Oct 9, 2026
Merged

setrofim merged 11 commits into
mainfrom
setrofim/misc

Conversation

@setrofim

@setrofim setrofim commented Oct 9, 2026 •

Copy link
Copy Markdown
Contributor

A number of additions and fixes to support work on github.com/veraison/ear.

  • add MustNewProfile()
  • implement TextMarshaler and TextUnmarshaler for IntOrString
  • handler empty input in Submod.UnmarshalJSON()
  • change NewNestedToken() to accept NestedTokenType rather than string as its type parameter
  • add int and uint conversions to IntOrStringFromAny()
  • add IntOrStringMapFromAny()
  • add NonceFromAny()
  • install a local golangci-lint and use that in the make target; update CI to do the same
  • update CI to align Go version with go.mod
  • add String() to Profile

Add MustNewProfile() a panicking version of NewProfile. This removes the
need for useless error checks when creating a profile form a known good
value.

Signed-off-by: setrofim <setrofim@gmail.com>
Implement text marshaling for IntOrString. This allows IntOrString to be
used as map keys when marshaling to/form JSON.

Signed-off-by: setrofim <setrofim@gmail.com>
Check that input text (after truncation) is at least one character long
before attempting to guess the format by examining the first character.

Stops panics on empty input.

Signed-off-by: setrofim <setrofim@gmail.com>
Change the type of the first parameter from string to NestedTokenType.
This is more natural as, in most cases, the type will be know at the
time of creation.

This also removes the need to parse the type out of the provided string.

Signed-off-by: setrofim <setrofim@gmail.com>
Comment thread nonce.go
Comment thread nonce.go

@yogeshbdeshpande yogeshbdeshpande left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

have left some comments, but in general looks good to me!

@yogeshbdeshpande yogeshbdeshpande left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

Comment thread int_or_string.go
Comment thread int_or_string.go Outdated
case int:
ret.val = t
case uint:
if t > math.MaxInt64 {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm, this will not work on a 32-bit platform

we need to wrap t (i.e., uint64(t))

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we care about 32 bit platforms? Outside of very small embedded systems I haven't seen one in over a decade.

(I've updated as you suggested, just seems a weird concern.)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we care about 32 bit platforms? Outside of very small embedded systems I haven't seen one in over a decade.

(I've updated as you suggested, just seems a weird concern.)

IIRC, Huawei research (Sampo, Vijay) were using veraison components on M-class via EmGo/TinyGo.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, really? I remember they experimented with it, but I didn't think those were successful.

Comment thread int_or_string.go
Comment on lines +218 to +225
func (o IntOrString) MarshalText() ([]byte, error) {
return []byte(o.String()), nil
}

func (o *IntOrString) UnmarshalText(data []byte) error {
*o = IntOrStringFromString(string(data))
return nil
}

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

these two do not roundrtip: string("1") becomes int(1). Worth documenting it (also, these are public methods and should have their doc strings).

@setrofim setrofim Oct 9, 2026 •

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They do. string("1") and int(1) both convert to IntOrString{1} (When given a string, IntOrString attempts strconv.Atoi() for precisely this reason: https://github.com/veraison/eat/blob/setrofim/misc/int_or_string.go#L70)

Regarding doc comments -- I thought that for interface implementations, the comments are on the interface, not the implementation? (e.g. we don't usually put doc comments on MarshalCBOR either).

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They do. string("1") and int(1) both convert to IntOrString{1} (When given a string, IntOrString attempts strconv.Atoi() for precisely this reason: https://github.com/veraison/eat/blob/setrofim/misc/int_or_string.go#L70)

oh, right! Sorry for the noise.

Regarding doc comments -- I thought that for interface implementations, the comments are on the interface, not the implementation? (e.g. we don't usually put doc comments on MarshalCBOR either).

It's a method exported by the package, so strictly speaking we should document it. Why not making it private then?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It needs to be public for the same reason as MarshalCBOR(), etc.

Comment thread nonce.go
Comment thread profile.go Outdated
Add the previously missing conversions for int and uint to
IntOrStringFromAny.

Additionally, update the error message for unknown inputs to not talk
about "unexpected algorithm", which does not necessarily make sense,
depending on the context in which the IntOString is used.

Signed-off-by: setrofim <setrofim@gmail.com>
Add a function to create a map[IntOrString]any from any input. While not
used in the library itself, it is useful for working with EATs
externally as they often define int keys for CBOR and string keys for
JSON (and CBOR could potentially have a mix of int and string keys).

Signed-off-by: setrofim <setrofim@gmail.com>
Add a function to convert any input into a Nonce. This is useful when
dealing with a generic unmarshaled claims (e.g. form a
map[IntOrString]any).

Signed-off-by: setrofim <setrofim@gmail.com>
Install a local version of golangci-lint into tools-bin/ and use that
when running "make lint". This ensures that we have a known version of
the linter that was built using the same Go version as the code base
being linted.

Additionally, upgrade the version used to v2.13.2, and fix up a couple
of new issues highlighted by the upgraded linter.

Finally, remove lint-extra target, as it is pretty much ignored anyway.

Signed-off-by: setrofim <setrofim@gmail.com>
Run lint via "make lint" which installs a known version locally, and
removes the need to install a pre-built version via GitHub actions.

Signed-off-by: setrofim <setrofim@gmail.com>
Update the Go version used in flows to 1.26 to align with the version
declared in go.mod.

Signed-off-by: setrofim <setrofim@gmail.com>
Add String() to Profile. Profile already has Get(), but that can be
awkward to use since you need to check the error. A lot of the time that
is unnecessary since you're comparing the string to a specific value;
besides the error can only occur when the profile is uninitialized.

Signed-off-by: setrofim <setrofim@gmail.com>

@thomas-fossati thomas-fossati left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks, 🚢 it!

@setrofim
setrofim merged commit 752feb0 into main Oct 9, 2026
6 checks passed
@setrofim
setrofim deleted the setrofim/misc branch October 9, 2026 14:45
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.

3 participants