-
Notifications
You must be signed in to change notification settings - Fork 32
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
Tweaks to better interop with go-tuf #377
base: develop
Are you sure you want to change the base?
Conversation
Signed-off-by: Luke Steensen <[email protected]>
Signed-off-by: Luke Steensen <[email protected]>
Signed-off-by: Luke Steensen <[email protected]>
Signed-off-by: Luke Steensen <[email protected]>
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.
Hello! Great patch, thanks! Beyond my comments, it looks like there's some test failures from us changing the spec_version
. It also might be time to update our golden test files from python-tuf and go-tuf.
--
And sorry that I keep putting out beta versions without cutting a formal release. I think with my delegation fix, and fleshing out the builder more I'm almost ready to commit to not breaking the API. I was tracking that work in #355. One thing to note though I'm not super confident in our delegation support. We aren't currently using it, so outside of the tests here we don't have a lot of real world use cases. For example, I just found that we were using the wrong field name last week in #373. I'd love any help trying to harden that.
Signed-off-by: Luke Steensen <[email protected]>
Signed-off-by: Luke Steensen <[email protected]>
Signed-off-by: Luke Steensen <[email protected]>
Thanks! I've updated the lib tests, so those should now be passing, but left the interop tests since I'm not sure of the best procedure for generating new fixtures. As far as testing delegation support, I'll see if some of our TUF experts can have a look and give some feedback. I'm pretty sure we use them at Datadog, but my team is still pretty new to TUF. |
First, nice work!
Second, yes, we do use delegations for full verification. I recommend taking a look at how go-tuf or python-tuf does it. |
Interesting, it seems that |
If so, would you help us to create a new issue there? Thanks! |
BTW, we don't have keyid_hash_algorithms in the metadata here, do we? |
Signed-off-by: Luke Steensen <[email protected]>
I've added one more commit here to add a catch-all |
Signed-off-by: Luke Steensen <[email protected]>
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.
IDK Rust, but the ideas therein seems good enough to me 👍🏽
It looks like we also got some test failures. I'd also like the |
FYI I did find a bug in rust-tuf's delegation #381. |
In theupdateframework#377, @lukesteensen noticed that we created metadata with the wrong spec version. We used `1.0`, but the proper form is `1.0.0`. Unfortunately landing this fix will be non-trivial, since old versions of rust-tuf will error out if the spec version is not `1.0`. As a stopgap, this patch changes rust-tuf to allow either a spec version of `1.0` or `1.0.0` so that we can switch to the proper schem once all the old clients have upgraded, or we come up with another way to gracefully perform this migration.
I just realized that switching our metadata generation to building metadata with the spec_version of As a stopgap, I factored out some of your fix in #386 to make sure new clients will at least be able to support the proper format once we start producing it. |
This extracts @lukesteensen's RFC 3339 timestamp parser from theupdateframework#377. This allows rust-tuf to interoperate better with other TUF implementations, which might include things like microseconds, or not be in the UTC timezone.
From theupdateframework#377, the [TUF spec] allows for paths to contain `*`. According to @lukesteensen, this is routinely used in delegations. Note though this does not attempt to implement delegation path globs. That will be implemented in theupdateframework#388. [TUF spec]: https://theupdateframework.github.io/specification/latest/#targetpath
In #377, @lukesteensen noticed that we created metadata with the wrong spec version. We used `1.0`, but the proper form is `1.0.0`. Unfortunately landing this fix will be non-trivial, since old versions of rust-tuf will error out if the spec version is not `1.0`. As a stopgap, this patch changes rust-tuf to allow either a spec version of `1.0` or `1.0.0` so that we can switch to the proper schem once all the old clients have upgraded, or we come up with another way to gracefully perform this migration.
This extracts @lukesteensen's RFC 3339 timestamp parser from theupdateframework#377. This allows rust-tuf to interoperate better with other TUF implementations, which might include things like microseconds, or not be in the UTC timezone.
This extracts @lukesteensen's RFC 3339 timestamp parser from #377. This allows rust-tuf to interoperate better with other TUF implementations, which might include things like microseconds, or not be in the UTC timezone.
From theupdateframework#377, the [TUF spec] allows for paths to contain `*`. According to @lukesteensen, this is routinely used in delegations. Note though this does not attempt to implement delegation path globs. That will be implemented in theupdateframework#388. [TUF spec]: https://theupdateframework.github.io/specification/latest/#targetpath
From #377, the [TUF spec] allows for paths to contain `*`. According to @lukesteensen, this is routinely used in delegations. Note though this does not attempt to implement delegation path globs. That will be implemented in #388. [TUF spec]: https://theupdateframework.github.io/specification/latest/#targetpath
@erickt Thanks so much for taking most of these across the line! Apologies for the radio silence, I had a couple weeks of travel there and some conflicting work priorities. It seems like the |
Yeah, although I saw and landed a patch that removed a number of unnecessary trait bounds. It might be that inheriting |
👋 I've been working on integrating the Vector project with Datadog's TUF/Uptane implementation, and this PR contains the handful of tweaks I've had to make to get everything interoperating happily:
spec_version
of"1.0"
is not actually valid according to SemVer. It should probably be"1.0.0"
everywhere, but I've kept a check for the old value so that it continues to work with existing metadata.*
in paths, which is legal according to the spec and used somewhat heavily when specifying delegations.Send
bounds, which isn't related to interop but made the library easier to use.The
spec_version
change does seem to break the interop tests, but I wanted to make sure we want to move forward with the change before doing the work of regenerating the test data.If any these seem undesirable or warrant more discussion, I'd be happy to split them into separate PRs.
/cc @Zenithar @cedricvanrompay-datadog