-
Notifications
You must be signed in to change notification settings - Fork 106
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
spec_version compliance #206
Comments
Unfortunately, this might break compatibility with Rust implementations of TUF (awslabs/tough and rust-tuf), needs double-checking... |
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 |
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 |
Just for the record php-tuf failed to validate go-tuf spec_version because of this. tuf-python generated 1.0.0... |
Any progress on this topic? |
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. |
Thanks for the pull request hopefully this get merged. |
Closing since the code base changed and the new one doesn't have this issue anymore. Thanks for raising this! 👍 |
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
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" (theupdateframework/python-tuf#1751) but I thought I should mention this here as well.
The text was updated successfully, but these errors were encountered: