-
Notifications
You must be signed in to change notification settings - Fork 275
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
New metadata API: spec_version attribute validation #1430
New metadata API: spec_version attribute validation #1430
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm approving, just commenting:
- referring to semver in error message is maybe a bit misleading (when we only accept a small but common subset of semver )
- I'm fine with being more strict than the spec when it's useful, I just don't quite get why we do that here
anyway, those are minor quibbles: LGTM, thanks
Yea, you are right, but if I wanted to be 100% correct, I will have to use more words and make this message longer...
I think it's better to be more conservative when we do checks than liberal and given that we will use almost the same amount of code if we check that the first element in the string is a number or all of them I decided the latter. |
@jku I realized that probably before merging we would want to create some tests actually testing |
We're spending time writing code that prevents future spec writers from using something like "2.0.0.beta1" without getting any benefits that I can see -- but it's fine let's move on. |
Oh I forgot: Did you actively decide not to verify the actual version number against version supported by the implementation (I may have missed the discussion)? Maybe we do what the old implementation did: raise if major version does not match the supported major version (which I think should probably be defined in |
a138869
to
08e8701
Compare
Great catch! |
08e8701
to
adca75f
Compare
34da1ff
to
69c4385
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm a bit grumpy about +19 lines of code for something like spec_version but I guess the comments are mostly suggestions -- I'm not seeing bugs or demanding changes.
The SPECIFICATION_VERSION issue I can live with as well, I just don't understand why we would want to do that.
56d011e
to
7bb8b4a
Compare
In issue theupdateframework#1418 in this comment: theupdateframework#1418 (comment) I summarized the discussion we had with the participants in this issue. In summary: no additional changes are needed for "version" validation considering there is "bump_version()" function for that. If we won't be adding "version" validation elsewhere we can keep it the way it is. Signed-off-by: Martin Vrachev <[email protected]>
7bb8b4a
to
26c2e8d
Compare
code looks great to me (thanks) but I have reservations on the comment, placement and value of SPECIFICATION_VERSION:
|
26c2e8d
to
24a39c2
Compare
Updated where I placed the |
According to point 2 in the semver specification: "A normal version number MUST take the form X.Y.Z where X, Y, and Z are non-negative integers...". See: https://semver.org/#spec-item-2 Also, even though version strings like "2.0.0-rc.2" or "1.0.0-beta" are valid strings in semantic versioning format, in TUF we never needed to add letters for our specification number. That's why I validate that: spec_version is a . separated string and when split it has a length of 3 and that each of the three elements is a number. The modules under the tuf/api folder in TUF are an alternative TUF implementation. That's why they should use their own constant for SPECIFICATION_VERSION in tuf/metadata/api. This time, I used a list for the SPECIFICATION_VERSION constant in order to retrieve major and minor versions easier. I use the SPECIFICATION_VERSION to check that the given spec_version is supported against the tuf code spec version. Signed-off-by: Martin Vrachev <[email protected]>
24a39c2
to
41afb1e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thank you
Fixes #1419
Description of the changes being introduced by the pull request:
Even though version strings like
2.0.0-rc.2
or1.0.0-beta
arevalid strings in semantic versioning format, in TUF we never needed
to add letters for our specification number.
That's why I validate that: spec_version is a
.
separated stringand when split it has a length of 3 and that each of the
three elements is a number.
Also, I remove one comment about the
version
validation place, because itseems irrelevant anymore.
Please verify and check that the pull request fulfills the following
requirements: