The spec says they can be left out at times, but we might as well include them and bolt them down to be required and match in all cases. This would add a small amount of additional security during checks, but it would add additional security to the internals of the lib by preventing misusing the struct to not include fields when it should.

I can't think of a reason not to do this (other than saving bytes in transit). @trishankkarthik, any thoughts?

Right now we do some hackiness where everything is assumed to be JSON coming in. While this is always the case in TUF, it's still doesn't feel right. And it also might be less efficient. Use the Visitor and other jazz from serde.

I'm looking into tuf/rust-tuf for some update procedures.

For now I'm failing to create a minimal working example and I'm not sure if it's just me or if there is a bug in the documentation that needs fixing. rust-tuf's src/lib.rs contains an example with a function get_original_root() that simply is unimplemented!(). I'm trying to fill the gap here.

First, I have followed the TUF documentation to generate a directory structure to be served according to the documentation in https://github.com/theupdateframework/tuf/blob/develop/tuf/README.md. In a nutshell, the steps are:

1. Generate RSA keys (root, targets, snapshot, timestamp);
2. Create repository metadata;
3. Create the actual repository.

Step 1. is trivial, simply calling tuf.repository_tool.generate_and_write_rsa_keypair() for each key. Step 2. uses create_new_repository() and adds the keys to the repo. Step 3. walks the repository directory and signs files using add_targets().

The problem I am facing comes from the call to rust-tuf's tuf::interchange::JsonDataInterchange::from_reader(). Since the get_original_root() function in unimplemented!(), I had to adapt it. It's returning a File, so I let it return File::open("repository/metadata/root.json").unwrap() where the json file was created by step 3 above. The from_reader() call fails though with a deserialization error:

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Encoding("JSON: ErrorImpl { code: Message(\"missing field `key_id`\"), line: 7, column: 3 }")', src/libcore/result.rs:859

I checked the files generated by tuf.repository_tool, and none contains the string key_id. The rust-tuf struct Signature seems to have one such field and is Deserialize so maybe this is where the error comes from?

I might be loading the improper file in tuf::interchange::JsonDataInterchange::from_reader(), but then there is no file that contains the key_id field in tuf's generated files. Am I following the proper guide to initialize a repository (https://github.com/theupdateframework/tuf/blob/develop/tuf/README.md)?

Note that I'm using rust-tuf c3321bf1295be66df46dcfb0440df491f2cf583f (branch develop) and tuf 904fa9b8df8ab8c632a210a2b05fd741e366788a (branch develop).

Thanks!

Currently it recursively grabs everything to prevent future replays of old metadata in the event of a snapshot key compromise. This is going to be waaaaay too much metadata even in the simple static.rust-lang.org case because older targets would be relegated to an archive type delegation whichi would necessitate frequently updating many delegated roles.

This is bad for local storage and bad for lots of requests / network IO.

This adds an optional user-provided boxed closure to HttpRepository which can be triggered to customize an HTTP request before sending it.

Closes https://github.com/heartsucker/rust-tuf/issues/99

Right now there's just come cursory stuff, but since TUF is complex, all functions that deal with TUF things really need to explain what and why better. This lib tries to prevent someone from being able to do Bad Things, but I've probably lost perspective on what constitutes a simple mistake because I'm in this too deep. Thus. Way more docs.

In the event of bad metadata, the client needs to rebuild the chain back from scratch. Imagine this

Good keys: A -> B -> C --------------------> D
Bad keys:            | -> D' -> E' -> F'

Metadata/keys D could never be reached because the client can't hop from F' to D. Client need to know how to roll back and untrust metadata.

This is a minor simplification of Client::_fetch_target to factor out the interior lookup function in order to cut out on a number of variables being passed in as arguments.

This updates the dependencies the following dependencies to the latest version: derp, itoa, log, tempfile, lazy_static, maplit

The only remaining outdated dependencies are on hyper (which is going to be a doozy to update) and untrusted, which is blocked on ring 0.13's release.

This was partially covered by #32, but I don't think the current test case is good enough.

TODO

Case 1:

• 1.root.json has threshold 3 and keys 1, 2, and 3
• 2.root.json has threshold 3 and keys 4, 5, 6
• 2.root.json is signed with 1, 2, 4, 5, 6
• client aborts

Case 2:

• 1.root.json has threshold 3 and keys 1, 2, and 3
• 2.root.json has threshold 3 and keys 4, 5, 6
• 2.root.json is signed with 1, 2, 3, 5, 6
• client aborts

Case 3:

• 1.root.json has threshold 3 and keys 1, 2, and 3
• 2.root.json has threshold 3 and keys 1, 2, and 4
• 2.root.json is signed with 1, 2, 3
• client aborts

Case 4:

• 1.root.json has threshold 3 and keys 1, 2, and 3
• 2.root.json has threshold 3 and keys 1, 2, and 4
• 2.root.json is signed with 1, 2, 4
• client aborts

Case 5:

• 1.root.json has threshold 3 and keys 1, 2, and 3
• 2.root.json has threshold 2 and keys 3, 4, and 5
• 2.root.json is signed with 1, 2, 3, 4, 5
• client continues

This changes Repository to use interior mutability in order to store state. At the moment, EphemeralRepository is the only repository type that stores state. By switching over to internally using Arc<Mutex<...>>> to wrap the state, it allows repositories to be used concurrently across threads. This trait will be especially important as we transition over to using asynchronous io with Hyper 0.11+.

Another approach could be to wrap the repositories in Client with Arc<Mutex<...>>, but I'm worried that might lead to deadlocks with asynchronous use of the repositories.

From the TUF spec:

All of the formats described below include the ability to add more attribute-value fields to objects for backwards-compatible format changes. Implementers who encounter undefined attribute-value pairs in the format must include the data when calculating hashes or verifying signatures and must preserve the data when re-serializing.

This adjust the primary metadata structs to include an additional_fields member that collects any unknown top-level keys. Those fields are then available to users of the library as well as present when the struct is re-serialized to JSON.

While writing a delegation builder, I noticed that while we have a test for diamond delegations, it doesn't actually work. Consider this delegation tree:

 targets
 /     \
A       B
 \     /
    D

Where D is signed correctly by B, but not signed correctly by A.

Both Client::lookup_target_description and Client::target_description_with_start_time will visit:

• targets
• A
• D (error, A did not sign D. marking as visited)
• B
• skip D since it was already visited.

We need to update these delegations as visited only if we decided the delegation is trusted.

Description of issue or feature request:

Similar to go-tuf, we should create a security policy so that researchers can properly disclose security issues.

👋 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:

1. A 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.
2. The datetime parsing was overly strict relative to the spec, which only specifies ISO8601. Here it's adjusted to use a full RFC3339 parser that handles the slightly differing format that go-tuf can emit.
3. Allowing * in paths, which is legal according to the spec and used somewhat heavily when specifying delegations.
4. Adding a couple of 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

Hey, it seems there's a newer version of the TUF specification - v1.0.30

The version which theupdateframework/rust-tuf states it supports is - v1.0.29

The following is a comparison of what changed between the two versions - Compare v1.0.29 to v1.0.30

Please review the newer version and address the changes.