spec_version compliance

[jku]

data/types.go sets the default specVersion value to "1.0".

I think strictly speaking this is not compliant with the spec which states that "format follows semver". Semver says

version number MUST take the form X.Y.Z where X, Y, and Z are non-negative integers

So I think it should be "1.0.28" (or "1.0.0" or whatever the highest known supported version is) instead of "1.0".

I'm mostly bringing this up because currently metadata generated with go-tuf is incompatible with python-tuf ngclient. python-tuf might end up supporting "X.Y" (https://github.com/theupdateframework/python-tuf/issues/1751) but I thought I should mention this here as well.

[trishankatdatadog]

Unfortunately, this might break compatibility with Rust implementations of TUF (awslabs/tough and rust-tuf), needs double-checking...

[jku]

For the record, I'm not suggesting go-tuf should necessarily reject "X.Y" in existing metadata, I'm suggesting go-tuf probably should not create new metadata with "X.Y": this seems not specification compliant.

AWS tough seems to be fine with X.Y.Z but based on a quick look the other rust implementation has chosen to only accept spec_version: "1.0" (so not just X.Y but exact version match) during deserialization. This seems like a decision (conscious or not) that should not prevent others from using spec_version as intended. A bug report on rust-tuf might be in order?

[trishankatdatadog]

Yes, I don't think we can close this issue until we can make sure that go-tuf/python-tuf/rust-tuf can interoperate with each other with this change

[HLeithner]

Just for the record php-tuf failed to validate go-tuf spec_version because of this. tuf-python generated 1.0.0...

[HLeithner]

Any progress on this topic?

[rdimitrov]

I've opened a PR fixing the initial values for metadata roles 👍 I also did not find a place where go-tuf actually acts differently(i.e. rejects something) based on the spec_version field. Nevertheless, it's good to note that if there's an implementation that depends on a non-spec compliant versioning it may be affected by this change. We should decide whether this is something we want to support/encourage or not.

[HLeithner]

Thanks for the pull request hopefully this get merged.

[rdimitrov]

Closing since the code base changed and the new one doesn't have this issue anymore.

Thanks for raising this! 👍

cc: @HLeithner @LadySolveig