profile
viewpoint

cloudera/livy 930

Livy is an open source REST interface for interacting with Apache Spark from anywhere

cadencemarseille/rust-pcre 22

Rust wrapper for libpcre

erickt/bonjour-forwarder 11

An example on how to have bonjour talk to zeromq

brson/llvm 7

Temporary fork of LLVM for Rust

erickt/celestia 4

Mirror of celestia

erickt/cargo-central 3

rust-lang.org maintained cargo repository

erickt/cchashmap 3

Rust implementation of the Cache Conscious HashMap

erickt/advisory-db 1

Security advisory database for Rust crates published through crates.io

erickt/bstr 1

A string type for Rust that is not required to be valid UTF-8.

brson/clang 0

Mirror of official clang git repository located at http://llvm.org/git/clang. Updated hourly.

PR opened heartsucker/rust-tuf

Add a RepoBuilder test repo builder

This adds a helper library repo_builder::RepoBuilder, which allows tests to more easily create a test repository.

+368 -335

0 comment

4 changed files

pr created time in an hour

create barncherickt/rust-tuf

branch : repo-builder

created branch time in an hour

push eventerickt/rust-tuf

Erick Tryzelaar

commit sha 1f9794641e5f7a076c51403b18ce4ee0a8a4f065

Add a RepoBuilder test repo builder This adds a helper library repo_builder::RepoBuilder, which allows tests to more easily create a test repository. Change-Id: I390dcb4621e6366366af710e71ad17383f1ce0db

view details

Erick Tryzelaar

commit sha b8d4138aa7b0fe61d26c8a9f33a2ab0b1aacf31a

Client::update should fail if we can't write metadata Previously, `Client::update` would warn, but ultimately ignore, if we failed to persist metadata to the local store. This doesn't play well with trying to use TUF offline. Consider the case where a client is doing an update for some new targets file. If we do an update, but we run out of space before writing the new targets file. If we reboot the device and lose our connection to the repository, we can no longer validate the old timestamp file. This patch changes the client to error when this happens. This would allow a user of `tuf::Client` to handle this error (like clearing some files from local storage before re-trying the update). If a user instead wants the old behavior, they could initialize a client with a local repository that only warns if an error occurs. Test: This adds a test case where where the client will err out if we fail to write an update. Change-Id: I31ffa2fc98353a16e73adeec6eb8da729784db92

view details

push time in an hour

push eventerickt/rust-tuf

Erick Tryzelaar

commit sha 9cb6f9dc95187b84aac0ad45456c9da74e2e514d

Add a RepoMaker test repo builder This adds a helper library repo_maker::RepoMaker, which allows tests to more easily create a test repository. Change-Id: I390dcb4621e6366366af710e71ad17383f1ce0db

view details

Erick Tryzelaar

commit sha ca953c0ff7d53a4e1b05322330f9dd8210b74174

Client::update should fail if we can't write metadata Previously, `Client::update` would warn, but ultimately ignore, if we failed to persist metadata to the local store. This doesn't play well with trying to use TUF offline. Consider the case where a client is doing an update for some new targets file. If we do an update, but we run out of space before writing the new targets file. If we reboot the device and lose our connection to the repository, we can no longer validate the old timestamp file. This patch changes the client to error when this happens. This would allow a user of `tuf::Client` to handle this error (like clearing some files from local storage before re-trying the update). If a user instead wants the old behavior, they could initialize a client with a local repository that only warns if an error occurs. Test: This adds a test case where where the client will err out if we fail to write an update. Change-Id: I31ffa2fc98353a16e73adeec6eb8da729784db92

view details

push time in 2 hours

push eventerickt/rust-tuf

Erick Tryzelaar

commit sha 55e6314f49a53db7fd29b24d6fbf316d76d97fe8

Change update_root to follow TUF-1.0.9 section 5.1 This switches Client::update_root to follow TUF-1.0.9 section 5.1 to update the root metadata. It now will fetch root N+1 until it receives a not-found error. Change-Id: I79147f64575ae8c1aa3fa418990d44e11a7d506b

view details

Erick Tryzelaar

commit sha 027efa5aef909084db6ffd027897884d8aee3833

Address comments, add more testing This adds a new test-only `TrackRepository` wrapper type, which allows most interactions with repository storage and providers to be captured and checked to make sure they are correct during testing. Note: This removes the `versioned_init` tests, since it is now redundant with the `chain_update_root` tests. Change-Id: I14ca6764a4f29cdc42afcd7b701e655bc10a9f2a

view details

Erick Tryzelaar

commit sha a5ea2c9650da10dee6bbbae6bcfe3540844a2115

Address comments * Fix a comment since TrackRepository only tracks metadata changes. * Error rather than panic if root version is 2^32 or above. * Add a fixme(#306) to add a limit on the number of root metadata fetch. Change-Id: I8adef8261108ee45630c407738372fb37e93c3b4

view details

Erick Tryzelaar

commit sha cf460811d79f98d8fe67ec2f44851d61c6151a5a

Merge pull request #302 from erickt/update-root Change update_root to follow TUF-1.0.9 section 5.1

view details

Erick Tryzelaar

commit sha 112e56db21eab8b0798f9b4f62ea0e8ece34f272

Add a RepoMaker test repo builder This adds a helper library repo_maker::RepoMaker, which allows tests to more easily create a test repository. Change-Id: I390dcb4621e6366366af710e71ad17383f1ce0db

view details

Erick Tryzelaar

commit sha 073db7283d56cbc3990fe37a50002c26f23732dd

Client::update should fail if we can't write metadata Previously, `Client::update` would warn, but ultimately ignore, if we failed to persist metadata to the local store. This doesn't play well with trying to use TUF offline. Consider the case where a client is doing an update for some new targets file. If we do an update, but we run out of space before writing the new targets file. If we reboot the device and lose our connection to the repository, we can no longer validate the old timestamp file. This patch changes the client to error when this happens. This would allow a user of `tuf::Client` to handle this error (like clearing some files from local storage before re-trying the update). If a user instead wants the old behavior, they could initialize a client with a local repository that only warns if an error occurs. Test: This adds a test case where where the client will err out if we fail to write an update. Change-Id: I31ffa2fc98353a16e73adeec6eb8da729784db92

view details

push time in 2 hours

push eventheartsucker/rust-tuf

Erick Tryzelaar

commit sha 55e6314f49a53db7fd29b24d6fbf316d76d97fe8

Change update_root to follow TUF-1.0.9 section 5.1 This switches Client::update_root to follow TUF-1.0.9 section 5.1 to update the root metadata. It now will fetch root N+1 until it receives a not-found error. Change-Id: I79147f64575ae8c1aa3fa418990d44e11a7d506b

view details

Erick Tryzelaar

commit sha 027efa5aef909084db6ffd027897884d8aee3833

Address comments, add more testing This adds a new test-only `TrackRepository` wrapper type, which allows most interactions with repository storage and providers to be captured and checked to make sure they are correct during testing. Note: This removes the `versioned_init` tests, since it is now redundant with the `chain_update_root` tests. Change-Id: I14ca6764a4f29cdc42afcd7b701e655bc10a9f2a

view details

Erick Tryzelaar

commit sha a5ea2c9650da10dee6bbbae6bcfe3540844a2115

Address comments * Fix a comment since TrackRepository only tracks metadata changes. * Error rather than panic if root version is 2^32 or above. * Add a fixme(#306) to add a limit on the number of root metadata fetch. Change-Id: I8adef8261108ee45630c407738372fb37e93c3b4

view details

Erick Tryzelaar

commit sha cf460811d79f98d8fe67ec2f44851d61c6151a5a

Merge pull request #302 from erickt/update-root Change update_root to follow TUF-1.0.9 section 5.1

view details

push time in 3 hours

PR merged heartsucker/rust-tuf

Change update_root to follow TUF-1.0.9 section 5.1

This switches Client::update_root to follow TUF-1.0.9 section 5.1 to update the root metadata. It now will fetch root N+1 until it receives a not-found error.

Test: This behavior is checked by the current tests. We could add a new test that makes sure we don't fetch root.json, but I'm not sure we get much value from a test like that.

+437 -435

0 comment

4 changed files

erickt

pr closed time in 3 hours

push eventerickt/rust-tuf

Erick Tryzelaar

commit sha a5ea2c9650da10dee6bbbae6bcfe3540844a2115

Address comments * Fix a comment since TrackRepository only tracks metadata changes. * Error rather than panic if root version is 2^32 or above. * Add a fixme(#306) to add a limit on the number of root metadata fetch. Change-Id: I8adef8261108ee45630c407738372fb37e93c3b4

view details

push time in 4 hours

Pull request review commentheartsucker/rust-tuf

Change update_root to follow TUF-1.0.9 section 5.1

 impl<D: DataInterchange> Tuf<D> {             //     discard it, abort the update cycle, and report the rollback attack. On the next             //     update cycle, begin at step 0 and version N of the root metadata file. -            // Next, make sure the new root has a higher version than the old root.-            if new_root.version() == trusted_root.version() {-                info!(-                    "Attempted to update root to new metadata with the same version. \-                     Refusing to update."-                );-                return Ok(false);-            } else if new_root.version() < trusted_root.version() {+            let next_root_version = trusted_root+                .version()+                .checked_add(1)+                .expect("root version should be less than max u32");

Sure, I'll switch. We'd never trip over this in practice though because the new root would fail to deserialize a 2^32 value into a u32.

We could bump the version numbers up to a u64 are worthwhile, but consider the case where it only took 1 millisecond to create or fetch a root metadata. Trying to generate or fetch (2^32-1) - N would still take approximately 50 days. Repositories and clients should instead have separate monitoring in place to catch runaway processes like that.

erickt

comment created time in 4 hours

PullRequestReviewEvent

Pull request review commentheartsucker/rust-tuf

Change update_root to follow TUF-1.0.9 section 5.1

+use {+    crate::{+        crypto::{HashAlgorithm, HashValue},+        interchange::DataInterchange,+        metadata::{MetadataPath, MetadataVersion, TargetDescription, TargetPath},+        repository::{RepositoryProvider, RepositoryStorage},+        Result,+    },+    futures_io::AsyncRead,+    futures_util::{+        future::{BoxFuture, FutureExt},+        io::{AsyncReadExt, Cursor},+    },+    parking_lot::Mutex,+    std::sync::Arc,+};++#[derive(Debug, PartialEq)]+pub(crate) enum Track {+    Store {+        path: MetadataPath,+        version: MetadataVersion,+        metadata: String,+    },+    FetchFound {+        path: MetadataPath,+        version: MetadataVersion,+        metadata: String,+    },+    FetchErr(MetadataPath, MetadataVersion),+}++impl Track {+    pub(crate) fn store<T>(meta_path: &MetadataPath, version: &MetadataVersion, metadata: T) -> Self+    where+        T: Into<Vec<u8>>,+    {+        Track::Store {+            path: meta_path.clone(),+            version: version.clone(),+            metadata: String::from_utf8(metadata.into()).unwrap(),+        }+    }++    pub(crate) fn fetch_found<T>(+        meta_path: &MetadataPath,+        version: &MetadataVersion,+        metadata: T,+    ) -> Self+    where+        T: Into<Vec<u8>>,+    {+        Track::FetchFound {+            path: meta_path.clone(),+            version: version.clone(),+            metadata: String::from_utf8(metadata.into()).unwrap(),+        }+    }+}++/// Helper Repository wrapper that tracks all the fetches and stores for testing purposes.

Fixed, thanks.

erickt

comment created time in 5 hours

PullRequestReviewEvent

Pull request review commentheartsucker/rust-tuf

Change update_root to follow TUF-1.0.9 section 5.1

 where     async fn update_root(&mut self) -> Result<bool> {         let root_path = MetadataPath::from_role(&Role::Root); -        // We don't follow the TUF-1.0.9 §5.1 on how to update the root metadata. It states:-        //-        // TUF-1.0.9 §5.1.2:-        //-        //     Try downloading version N+1 of the root metadata file, up to some W number of-        //     bytes (because the size is unknown). The value for W is set by the authors of-        //     the application using TUF. For example, W may be tens of kilobytes. The filename-        //     used to download the root metadata file is of the fixed form-        //     VERSION_NUMBER.FILENAME.EXT (e.g., 42.root.json). If this file is not available,-        //     or we have downloaded more than Y number of root metadata files (because the-        //     exact number is as yet unknown), then go to step 5.1.9. The value for Y is set-        //     by the authors of the application using TUF. For example, Y may be 2^10.-        //-        // Instead, we fetch the latest available metadata (lets call the current version N and the-        // latest version N+M), then we re-fetch all the metadata in betwee N and N+M.-        //-        // FIXME(#292): Consider rewriting this logic to follow the spec. By following the spec, we-        // avoid the issue of having to use metadata (in order to extract the metadata version-        // number) before we've verified it was signed correctly.-        let raw_latest_root = self-            .remote-            .fetch_metadata(-                &root_path,-                &MetadataVersion::None,-                self.config.max_root_length,-                None,-            )-            .await?;+        let mut updated = false; -        // Root metadata is signed by its own keys, but we should only trust it if it is also-        // signed by the previous root metadata, which we can't check without knowing what version-        // this root metadata claims to be.-        let latest_version = {-            // FIXME(#292): See the note above.-            let latest_root = raw_latest_root.parse_untrusted()?;-            latest_root.parse_version_untrusted()?-        };--        if latest_version < self.tuf.trusted_root().version() {-            return Err(Error::VerificationFailure(format!(-                "Latest root version is lower than current root version: {} < {}",-                latest_version,-                self.tuf.trusted_root().version()-            )));-        } else if latest_version == self.tuf.trusted_root().version() {-            return Ok(false);-        }--        let err_msg = "TUF claimed no update occurred when one should have. \-                       This is a programming error. Please report this as a bug.";+        loop {+            /////////////////////////////////////////+            // TUF-1.0.9 §5.1.2:+            //+            //     Try downloading version N+1 of the root metadata file, up to some W number of+            //     bytes (because the size is unknown). The value for W is set by the authors of+            //     the application using TUF. For example, W may be tens of kilobytes. The filename+            //     used to download the root metadata file is of the fixed form+            //     VERSION_NUMBER.FILENAME.EXT (e.g., 42.root.json). If this file is not available,+            //     or we have downloaded more than Y number of root metadata files (because the

Oops, good catch. I filed #306 and added a FIXME to track that.

erickt

comment created time in 5 hours

PullRequestReviewEvent

issue openedheartsucker/rust-tuf

Consider adding an upper bound on the number of root metadata we'll fetch in Client::update_root

TUF-1.0.9 §5.1.2 states:

Try downloading version N+1 of the root metadata file, up to some W number of
bytes (because the size is unknown). The value for W is set by the authors of
the application using TUF. For example, W may be tens of kilobytes. The filename
used to download the root metadata file is of the fixed form
VERSION_NUMBER.FILENAME.EXT (e.g., 42.root.json). If this file is not available,
or we have downloaded more than Y number of root metadata files (because the
exact number is as yet unknown), then go to step 5.1.9. The value for Y is set
by the authors of the application using TUF. For example, Y may be 2^10.

We do not have an upper bound on the number of root metadata we'll fetch. This means that an attacker that's stolen the root keys could cause a client to fall into an infinite loop (but if an attacker has stolen the root keys, the client probably has worse problems to worry about).

created time in 5 hours

PullRequestReviewEvent

PR opened heartsucker/rust-tuf

Remove MetadataVersion::Hash

TUF no longer supports prefixing metadata paths by a hash, so this removes support for them.

Closes #254

+14 -7

0 comment

2 changed files

pr created time in 7 hours

create barncherickt/rust-tuf

branch : remove-version-hash

created branch time in 7 hours

Pull request review commentheartsucker/rust-tuf

Change update_root to follow TUF-1.0.9 section 5.1

 where     async fn update_root(&mut self) -> Result<bool> {         let root_path = MetadataPath::from_role(&Role::Root); -        // We don't follow the TUF-1.0.9 §5.1 on how to update the root metadata. It states:-        //-        // TUF-1.0.9 §5.1.2:-        //-        //     Try downloading version N+1 of the root metadata file, up to some W number of-        //     bytes (because the size is unknown). The value for W is set by the authors of-        //     the application using TUF. For example, W may be tens of kilobytes. The filename-        //     used to download the root metadata file is of the fixed form-        //     VERSION_NUMBER.FILENAME.EXT (e.g., 42.root.json). If this file is not available,-        //     or we have downloaded more than Y number of root metadata files (because the-        //     exact number is as yet unknown), then go to step 5.1.9. The value for Y is set-        //     by the authors of the application using TUF. For example, Y may be 2^10.-        //-        // Instead, we fetch the latest available metadata (lets call the current version N and the-        // latest version N+M), then we re-fetch all the metadata in betwee N and N+M.-        //-        // FIXME(#292): Consider rewriting this logic to follow the spec. By following the spec, we-        // avoid the issue of having to use metadata (in order to extract the metadata version-        // number) before we've verified it was signed correctly.-        let raw_latest_root = self-            .remote-            .fetch_metadata(-                &root_path,-                &MetadataVersion::None,-                self.config.max_root_length,-                None,-            )-            .await?;+        let mut updated = false; -        // Root metadata is signed by its own keys, but we should only trust it if it is also-        // signed by the previous root metadata, which we can't check without knowing what version-        // this root metadata claims to be.-        let latest_version = {-            // FIXME(#292): See the note above.-            let latest_root = raw_latest_root.parse_untrusted()?;-            latest_root.parse_version_untrusted()?-        };--        if latest_version < self.tuf.trusted_root().version() {-            return Err(Error::VerificationFailure(format!(-                "Latest root version is lower than current root version: {} < {}",-                latest_version,-                self.tuf.trusted_root().version()-            )));-        } else if latest_version == self.tuf.trusted_root().version() {-            return Ok(false);-        }--        let err_msg = "TUF claimed no update occurred when one should have. \-                       This is a programming error. Please report this as a bug.";+        loop {+            /////////////////////////////////////////+            // TUF-1.0.9 §5.1.2:+            //+            //     Try downloading version N+1 of the root metadata file, up to some W number of+            //     bytes (because the size is unknown). The value for W is set by the authors of+            //     the application using TUF. For example, W may be tens of kilobytes. The filename+            //     used to download the root metadata file is of the fixed form+            //     VERSION_NUMBER.FILENAME.EXT (e.g., 42.root.json). If this file is not available,+            //     or we have downloaded more than Y number of root metadata files (because the

No, Y in our case is self.config.max_root_length down on line 484. By default it's 1 MiB.

erickt

comment created time in a day

Pull request review commentheartsucker/rust-tuf

Change update_root to follow TUF-1.0.9 section 5.1

 where     async fn update_root(&mut self) -> Result<bool> {         let root_path = MetadataPath::from_role(&Role::Root); -        // We don't follow the TUF-1.0.9 §5.1 on how to update the root metadata. It states:-        //-        // TUF-1.0.9 §5.1.2:-        //-        //     Try downloading version N+1 of the root metadata file, up to some W number of-        //     bytes (because the size is unknown). The value for W is set by the authors of-        //     the application using TUF. For example, W may be tens of kilobytes. The filename-        //     used to download the root metadata file is of the fixed form-        //     VERSION_NUMBER.FILENAME.EXT (e.g., 42.root.json). If this file is not available,-        //     or we have downloaded more than Y number of root metadata files (because the-        //     exact number is as yet unknown), then go to step 5.1.9. The value for Y is set-        //     by the authors of the application using TUF. For example, Y may be 2^10.-        //-        // Instead, we fetch the latest available metadata (lets call the current version N and the-        // latest version N+M), then we re-fetch all the metadata in betwee N and N+M.-        //-        // FIXME(#292): Consider rewriting this logic to follow the spec. By following the spec, we-        // avoid the issue of having to use metadata (in order to extract the metadata version-        // number) before we've verified it was signed correctly.-        let raw_latest_root = self-            .remote-            .fetch_metadata(-                &root_path,-                &MetadataVersion::None,-                self.config.max_root_length,-                None,-            )-            .await?;+        let mut updated = false; -        // Root metadata is signed by its own keys, but we should only trust it if it is also-        // signed by the previous root metadata, which we can't check without knowing what version-        // this root metadata claims to be.-        let latest_version = {-            // FIXME(#292): See the note above.-            let latest_root = raw_latest_root.parse_untrusted()?;-            latest_root.parse_version_untrusted()?-        };--        if latest_version < self.tuf.trusted_root().version() {-            return Err(Error::VerificationFailure(format!(-                "Latest root version is lower than current root version: {} < {}",-                latest_version,-                self.tuf.trusted_root().version()-            )));-        } else if latest_version == self.tuf.trusted_root().version() {-            return Ok(false);-        }--        let err_msg = "TUF claimed no update occurred when one should have. \-                       This is a programming error. Please report this as a bug.";+        loop {+            /////////////////////////////////////////+            // TUF-1.0.9 §5.1.2:+            //+            //     Try downloading version N+1 of the root metadata file, up to some W number of+            //     bytes (because the size is unknown). The value for W is set by the authors of+            //     the application using TUF. For example, W may be tens of kilobytes. The filename+            //     used to download the root metadata file is of the fixed form+            //     VERSION_NUMBER.FILENAME.EXT (e.g., 42.root.json). If this file is not available,+            //     or we have downloaded more than Y number of root metadata files (because the+            //     exact number is as yet unknown), then go to step 5.1.9. The value for Y is set+            //     by the authors of the application using TUF. For example, Y may be 2^10.++            let next_version = MetadataVersion::Number(self.tuf.trusted_root().version() + 1);+            let res = self+                .remote+                .fetch_metadata(&root_path, &next_version, self.config.max_root_length, None)+                .await; -        for i in (self.tuf.trusted_root().version() + 1)..latest_version {-            let version = MetadataVersion::Number(i);+            let raw_signed_root = match res {+                Ok(raw_signed_root) => raw_signed_root,+                Err(Error::NotFound) => {+                    break;+                }+                Err(err) => {+                    return Err(err);+                }+            }; -            // FIXME(#292): See the note above.-            let raw_signed_root = self-                .remote-                .fetch_metadata(&root_path, &version, self.config.max_root_length, None)-                .await?;+            updated = true;              if !self.tuf.update_root(&raw_signed_root)? {

Yeah this was weird. I fixed that in another patch I'm working on, I'll pull it back here.

erickt

comment created time in a day

PullRequestReviewEvent
PullRequestReviewEvent

push eventerickt/rust-tuf

Erick Tryzelaar

commit sha 027efa5aef909084db6ffd027897884d8aee3833

Address comments, add more testing This adds a new test-only `TrackRepository` wrapper type, which allows most interactions with repository storage and providers to be captured and checked to make sure they are correct during testing. Note: This removes the `versioned_init` tests, since it is now redundant with the `chain_update_root` tests. Change-Id: I14ca6764a4f29cdc42afcd7b701e655bc10a9f2a

view details

push time in a day

PR opened heartsucker/rust-tuf

Client::update should fail if we can't write metadata

Previously, Client::update would warn, but ultimately ignore, if we failed to persist metadata to the local store. This doesn't play well with trying to use TUF offline.

Consider the case where a client is doing an update for some new targets file. If we do an update, but we run out of space before writing the new targets file. If we reboot the device and lose our connection to the repository, we can no longer validate the old timestamp file.

This patch changes the client to error when this happens. This would allow a user of tuf::Client to handle this error (like clearing some files from local storage before re-trying the update). If a user instead wants the old behavior, they could initialize a client with a local repository that only warns if an error occurs.

Test: This adds a test case where where the client will err out if we fail to write an update.

+201 -46

0 comment

1 changed file

pr created time in a day

push eventerickt/rust-tuf

Erick Tryzelaar

commit sha 7925a0ade50d81552be8add49e86fbc763d422ca

Client::update should fail if we can't write metadata Previously, `Client::update` would warn, but ultimately ignore, if we failed to persist metadata to the local store. This doesn't play well with trying to use TUF offline. Consider the case where a client is doing an update for some new targets file. If we do an update, but we run out of space before writing the new targets file. If we reboot the device and lose our connection to the repository, we can no longer validate the old timestamp file. This patch changes the client to error when this happens. This would allow a user of `tuf::Client` to handle this error (like clearing some files from local storage before re-trying the update). If a user instead wants the old behavior, they could initialize a client with a local repository that only warns if an error occurs. Test: This adds a test case where where the client will err out if we fail to write an update. Change-Id: I31ffa2fc98353a16e73adeec6eb8da729784db92

view details

push time in a day

create barncherickt/rust-tuf

branch : fail

created branch time in a day

PR opened heartsucker/rust-tuf

Extend tests to check all the tuf::Client constructors

This makes sure that all the tuf::Client tests go through the test_versioned_inits.

+66 -24

0 comment

1 changed file

pr created time in 2 days

create barncherickt/rust-tuf

branch : contructors

created branch time in 2 days

PR opened heartsucker/rust-tuf

Change update_root to follow TUF-1.0.9 section 5.1

This switches Client::update_root to follow TUF-1.0.9 section 5.1 to update the root metadata. It now will fetch root N+1 until it receives a not-found error.

Test: This behavior is checked by the current tests. We could add a new test that makes sure we don't fetch root.json, but I'm not sure we get much value from a test like that.

+33 -80

0 comment

1 changed file

pr created time in 2 days

create barncherickt/rust-tuf

branch : update-root

created branch time in 2 days

issue commenttheupdateframework/taps

Allowing TAPs that are licensed with MIT or Apache 2.0?

@JustinCappos: Good morning! Has there been any word from Chris A?

erickt

comment created time in 5 days

push eventerickt/tuf-specification

Erick Tryzelaar

commit sha 7a43bd6f120377a4cfab0c65698c8f7c1819ccd1

More definitions, and calling out examples

view details

push time in 5 days

issue openedtabatkins/bikeshed

Difficult to click on an example link on Chrome 86 with default CSS

I'm finding the hitbox for getting an example on Chrome 86 to be quite tiny with the default CSS. For example, for https://tabatkins.github.io/bikeshed/#example-e79df413, it seems the hitbox is approximately 2 pixels wide. In comparison, it looks like whatwg style has this rule:

a.self-link::before {
    content: "¶";
}

You can see this in use here: https://url.spec.whatwg.org/#example-12672b6a. Would it be worthwhile adding something like that in the default CSS?

created time in 6 days

push eventerickt/tuf-specification

Erick Tryzelaar

commit sha 974c1089bb040a4b07799b36af2db11619b25dfc

Add definitions for section 4.2

view details

Erick Tryzelaar

commit sha bcfb1e9585ee13e47271e87efe4ebb3402bef0d7

Add definitions to root.json format

view details

push time in 8 days

delete branch erickt/rust-tuf

delete branch : persist

delete time in 8 days

push eventheartsucker/rust-tuf

Erick Tryzelaar

commit sha 331d96624a93dc1326cba794c7670d1df3c1c8c2

Persist unversioned metadata to local store The TUF-1.0.9 spec states that the metadata should be written to non-volatile storage as an unversioned path after verification. This also keeps the extension where we also persist the versioned root metadata. This allows a client to be initialized first from an trusted root metadata (which could be stored in read-only storage), then load metadata from the local store, and finally then the remote metadata. Change-Id: Id62685db069b65e094666c97464583df4c2a1163

view details

Erick Tryzelaar

commit sha de626769c207ce84624277d811ba2af5c4dc733a

Fix typo Change-Id: I81d1718a78e752b8db4fac1da36127fb009dc8ee

view details

Erick Tryzelaar

commit sha 74af84d0bf26eea5beca1c049d2d3c8b03b1c680

Merge remote-tracking branch 'remotes/origin/upstream/develop' into persist Change-Id: I0dfff9a79215ade0a7793958fb1e2644e2c1df9d

view details

Erick Tryzelaar

commit sha ad3cba03f0b5bfd5c3aca67a6364ec5c25bc7134

Address comments Change-Id: I6a301385cf9cee8ef525f2dfc385df16195ed466

view details

Erick Tryzelaar

commit sha bb39420da8c082126c9ae71d33afa01114991a29

Address the rest of the comments Change-Id: I8ac912fb46c66966358b3ee236a6b7d5979f6afc

view details

Erick Tryzelaar

commit sha 36d5fbd35c3cc5b369de4d68adf855a40374afc7

Merge pull request #300 from erickt/persist Persist unversioned metadata to local store

view details

push time in 8 days

PR merged heartsucker/rust-tuf

Persist unversioned metadata to local store

The TUF-1.0.9 spec states that the metadata should be written to non-volatile storage as an unversioned path after verification.

+188 -25

0 comment

2 changed files

erickt

pr closed time in 8 days

push eventerickt/rust-tuf

Erick Tryzelaar

commit sha bb39420da8c082126c9ae71d33afa01114991a29

Address the rest of the comments Change-Id: I8ac912fb46c66966358b3ee236a6b7d5979f6afc

view details

push time in 8 days

Pull request review commentheartsucker/rust-tuf

Persist unversioned metadata to local store

 where                 .update_delegation(&targets_role, delegation.role(), &raw_signed_meta)             {                 Ok(_) => {+                    /////////////////////////////////////////+                    // TUF-1.0.9 §5.2.4:+                    //+                    //     Persist timestamp metadata. The client MUST write the file to+                    //     non-volatile storage as FILENAME.EXT (e.g. timestamp.json).+

good catch, thanks.

erickt

comment created time in 8 days

PullRequestReviewEvent

push eventerickt/tuf-specification

Erick Tryzelaar

commit sha 1bee014d2047d0d92237452335b980ccce1fa866

Fix warnings

view details

Erick Tryzelaar

commit sha 8d867bf165ddb52f37d7a6ae6b269574826bb616

re-indent, format codeblocks, and use definition lists

view details

push time in 10 days

Pull request review commentheartsucker/rust-tuf

Persist unversioned metadata to local store

 where         // Only store the metadata after we have validated it.         if fetched {             client-                .store_metadata(&root_path, &root_version, &raw_root)+                .store_metadata(&root_path, &MetadataVersion::None, &raw_root)

I'll remove this change. I think we'd only run into this if we called Client::with_trusted_root_keys with MetadataVersion::None. We probably should make that impossible though. I don't think it's safe to assume we can always trust that the initial trusted keys have always signed the latest root metadata.

erickt

comment created time in 10 days

Pull request review commentheartsucker/rust-tuf

Persist unversioned metadata to local store

 where             )             .await?; -        if let Some(updated_timestamp) = self.tuf.update_timestamp(&raw_signed_timestamp)? {-            let latest_version = MetadataVersion::Number(updated_timestamp.version());-            self.store_metadata(&timestamp_path, &latest_version, &raw_signed_timestamp)-                .await;+        if self.tuf.update_timestamp(&raw_signed_timestamp)?.is_some() {+            /////////////////////////////////////////+            // TUF-1.0.9 §5.2.4:+            //+            //     Persist timestamp metadata. The client MUST write the file to non-volatile+            //     storage as FILENAME.EXT (e.g. timestamp.json).++            self.store_metadata(+                &timestamp_path,+                &MetadataVersion::None,

While technically it's a breaking change, it's safe because tuf::Client doesn't actually use the local cache of the timestamp metadata. In fact, the only time we actually use the local store is in Client::with_trusted_root_keys, when we fetch the initial trusted root. There's no other place that reads from the store, other than tests.

It's possible someone could be relying on the side effect of these files being written out to local storage, but I'm not aware of anyone else actually using rust-tuf, so this should be safe.

erickt

comment created time in 10 days

Pull request review commentheartsucker/rust-tuf

Persist unversioned metadata to local store

 where                 return Err(Error::Programming(err_msg.into()));             } +            /////////////////////////////////////////+            // TUF-1.0.9 §5.1.7:+            //+            //     Persist root metadata. The client MUST write the file to non-volatile storage as+            //     FILENAME.EXT (e.g. root.json).++            self.store_metadata(&root_path, &MetadataVersion::None, &raw_signed_root)+                .await;++            // FIXME: This isn't a part of the spec, but we also store the versioned metadata. This+            // allows us to initialize a repository from the local metadata.

Sure, I'll switch to calling this a "NOTE". I used "FIXME" since I wanted to eventually get this updated in the spec (see https://github.com/theupdateframework/specification/issues/108).

erickt

comment created time in 10 days

Pull request review commentheartsucker/rust-tuf

Persist unversioned metadata to local store

 where         for i in (self.tuf.trusted_root().version() + 1)..latest_version {             let version = MetadataVersion::Number(i); +            /////////////////////////////////////////+            // TUF-1.0.9 §5.1.2:+            //+            //     Try downloading version N+1 of the root metadata file, up to some W number of+            //     bytes (because the size is unknown). The value for W is set by the authors of+            //     the application using TUF. For example, W may be tens of kilobytes. The filename+            //     used to download the root metadata file is of the fixed form+            //     VERSION_NUMBER.FILENAME.EXT (e.g., 42.root.json). If this file is not available,+            //     or we have downloaded more than Y number of root metadata files (because the+            //     exact number is as yet unknown), then go to step 5.1.9. The value for Y is set+            //     by the authors of the application using TUF. For example, Y may be 2^10.

Sure, I can add a reference to https://github.com/heartsucker/rust-tuf/issues/292 here.

erickt

comment created time in 11 days

Pull request review commentheartsucker/rust-tuf

Persist unversioned metadata to local store

 where                 return Err(Error::Programming(err_msg.into()));             } +            /////////////////////////////////////////+            // TUF-1.0.9 §5.1.7:+            //+            //     Persist root metadata. The client MUST write the file to non-volatile storage as+            //     FILENAME.EXT (e.g. root.json).++            self.store_metadata(&root_path, &MetadataVersion::None, &raw_signed_root)+                .await;++            // FIXME: This isn't a part of the spec, but we also store the versioned metadata. This+            // allows us to initialize a repository from the local metadata.             self.store_metadata(&root_path, &version, &raw_signed_root)                 .await;++            /////////////////////////////////////////+            // TUF-1.0.9 §5.1.8:+            //+            //     Repeat steps 5.1.1 to 5.1.8.         }          if !self.tuf.update_root(&raw_latest_root)? {             error!("{}", err_msg);             return Err(Error::Programming(err_msg.into()));         } -        let latest_version = MetadataVersion::Number(latest_version);+        /////////////////////////////////////////+        // TUF-1.0.9 §5.1.7:+        //+        //     Persist root metadata. The client MUST write the file to non-volatile storage as+        //     FILENAME.EXT (e.g. root.json). -        self.store_metadata(&root_path, &latest_version, &raw_latest_root)-            .await;         self.store_metadata(&root_path, &MetadataVersion::None, &raw_latest_root)             .await; +        // FIXME: This isn't a part of the spec, but we also store the versioned metadata. This+        // allows us to initialize a repository from the local metadata.+        self.store_metadata(+            &root_path,+            &MetadataVersion::Number(latest_version),+            &raw_latest_root,+        )+        .await;++        /////////////////////////////////////////+        // TUF-1.0.9 §5.1.9:+        //+        //     Check for a freeze attack. The latest known time MUST be lower than the expiration+        //     timestamp in the trusted root metadata file (version N). If the trusted root+        //     metadata file has expired, abort the update cycle, report the potential freeze+        //     attack. On the next update cycle, begin at step 5.0 and version N of the root+        //     metadata file.++        // FIXME: we should move this logic into TUF to make it easier to review we implement the+        // TUF spec.

I'll rephrase this comment. We're checking the timestamp/snapshot/targets metadata for expiration in tuf::Tuf, I'd eventually like to move the root metadata expiration check into tuf::Tuf in order to reduce code duplication, and make it easier to audit rust-tuf's implementation of the spec, but I didn't want to go that far in this PR.

erickt

comment created time in 10 days

PullRequestReviewEvent
PullRequestReviewEvent

push eventerickt/rust-tuf

Erick Tryzelaar

commit sha ad3cba03f0b5bfd5c3aca67a6364ec5c25bc7134

Address comments Change-Id: I6a301385cf9cee8ef525f2dfc385df16195ed466

view details

push time in 10 days

push eventerickt/tuf-specification

Erick Tryzelaar

commit sha e00b2fc565c9ac2950a8c6ce54412b61c57f9a98

prep bikeshed

view details

Erick Tryzelaar

commit sha fe48bbb3c27c5d8f287d37aa20a4ae06f18010e2

experiment with github actions

view details

push time in 11 days

push eventerickt/tuf-specification

Erick Tryzelaar

commit sha 9f1e73a6d1ee35d6efa43e394a7e3a4c68f5e05b

Fix a typo in section 5.3.1 It looks like an extra newline and bullet point was accidentally introduced in section 5.3.1. This removes it, and re-wraps the section.

view details

Erick Tryzelaar

commit sha a985ea9ea4a35f73bffd6727dcb07aba34380798

Fix a misspelling of snapshot

view details

Justin Cappos

commit sha 9b1ad53d068a9d00055c54ea014dc65dda75dc20

Merge pull request #26 from erickt/patch-3 Fix a misspelling of snapshot

view details

Justin Cappos

commit sha f5a6f00a2a5d8c4b05e24bbe5de718aa09da167c

Merge pull request #25 from erickt/patch-1 Fix a typo in section 5.3.1

view details

Hannes Mehnert

commit sha 2b4e18472fe25d5b57f36f6fa50104967c8faeaa

minor: fix sentence

view details

Sebastien Awwad

commit sha 86ca2d4df85b9a6ea6985b8ae74f091f1ee4eadb

Merge pull request #29 from hannesm/minor minor: fix sentence

view details

Justin Cappos

commit sha 99dbf9af48c9d8c3cc78ce1b8d185df10aa8c503

Removing (Draft)

view details

Nguyen Quang Huy

commit sha a2d9d90166908f340faa7acef66a85dd51be67c1

Remove some duplicated words Remove some duplicated words in tuf-spec.md

view details

lukpueh

commit sha e69916da337cb858d349a889ae15148cd1821c35

Merge pull request #34 from huynq0911/fix_duplicated_word Remove some duplicated words

view details

Justin Cappos

commit sha 1a6f2b73c315da49455f1ce2447199b14eb9a59a

Slightly clarifying provenance / early history... It's odd to fix this so late in the project's lifecycle, but the spec should probably be a bit more accurate in describing the history of TUF and Thandy. Jake and Roger visited UW (while Justin S. and Justin C. were there) and the brainstorming discussions we had there laid the groundwork for Thandy, which Nick, Jake, Roger, and possibly others I am unaware of designed. The Thandy authors then reached out to Justin S. and Justin C. to examine Thandy. The creation of TUF (by Justin S. and Justin C.) came from looking at issues with Thandy where we thought security could be improved (e.g., the lack of a snapshot role). We also tried to build TUF as a library so that others did not need to do a design like Thandy in order to have a secure updater. Note, this is my recollection of events and memory is not perfect. If someone else has a different recollection about any of my "facts" above, please let me know and I can adjust or annotate what is written.

view details

Justin Cappos

commit sha 30625204c8d97021bbac20281363fa0486c5e68e

Update README.rst

view details

Erick Tryzelaar

commit sha daae73130d4ce447c55b5f7b466a0da1d70997bb

0.9 timestamp example was missing "version" The 0.9 tuf spec in section 4.6 mentions that "version" is included in the signed portion of timestamp.json, but was missing from the example file. This adds it. Feel free to reject this patch if you want to leave 0.9 as a historical document.

view details

Justin Cappos

commit sha 215c56996fbe7e4de8afcabef1c9dbec07670f9e

Merge pull request #37 from erickt/patch-4 0.9 timestamp example was missing "version"

view details

Erick Tryzelaar

commit sha 454d4b75080c2c7905d103f06d3ab0fc0802c10f

Recommend against leading path separators In https://github.com/theupdateframework/tuf/pull/679, the python tuf project forbade leading path separators due to surprising behavior joining target and delegated paths, since Python in particular has the following surprising behavior: ``` >>> os.path.join("/foo", "/bar") '/bar' ``` This PR updates the spec to recommend against using leading path separators in targets.json, and removes their use from the examples. Does this change look acceptable, and is "should not" be the correct phrase, or can this be the more strict "must not"?

view details

Sebastien Awwad

commit sha 28250513c270a8effaedd539e8d2c4d5cce50a70

PR revision: minor: typo fixes Signed-off-by: Sebastien Awwad <sebastien.awwad@gmail.com>

view details

Sebastien Awwad

commit sha 0c42560472848fc7a45066a4991e1867f038cd6f

In 0.9, fix history notes on early TUF (clone's Justin's edits) Apply the edits made on notes about the early history of TUF in the 1.0 spec to the 0.9 version of the specification as well. Signed-off-by: Sebastien Awwad <sebastien.awwad@gmail.com>

view details

Sebastien Awwad

commit sha 094800da17b4dff8ae23ecb0b817bbc9394b3d5a

Merge pull request #35 from theupdateframework/JustinCappos-TUF-history Slightly clarifying provenance / early history...

view details

Radu M

commit sha 091e1160e68f5bff1c74cf217f595b1a71eec092

Fix typo in detailed workflows

view details

Justin Cappos

commit sha bc97d9660bb6b9234fa3d41140978344ce698b84

Merge pull request #44 from radu-matei/patch-1 Fix typo in detailed workflows

view details

Trishank K Kuppusamy

commit sha 7cf7de02132ff398f51287d4098151367d3bc5e7

Limit on the # of root metadata files downloaded

view details

push time in 11 days

push eventerickt/tuf-specification

Erick Tryzelaar

commit sha d93abbc27b4300170cbc0487f1c3b54c3484e531

experiment with github actions

view details

push time in 11 days

push eventerickt/specification

Erick Tryzelaar

commit sha 52ff8b82f126dd404aec8599e2a9da610352a623

experiment with github actions

view details

push time in 11 days

PR closed theupdateframework/specification

Bs
+3616 -326

0 comment

4 changed files

erickt

pr closed time in 11 days

PR opened theupdateframework/specification

Bs
+3616 -326

0 comment

4 changed files

pr created time in 11 days

PR closed theupdateframework/specification

Bs
+3616 -326

0 comment

4 changed files

erickt

pr closed time in 11 days

PR opened theupdateframework/specification

Bs
+3616 -326

0 comment

4 changed files

pr created time in 11 days

push eventerickt/specification

Erick Tryzelaar

commit sha 6e8e4721a4985a8f6c0ef5f21884dde46e0c6341

experiment with github actions

view details

push time in 11 days

push eventerickt/specification

Erick Tryzelaar

commit sha cf302d40b92a6853dc0726a341385e71e4ced1d5

experiment with github actions

view details

push time in 11 days

Pull request review commentheartsucker/rust-tuf

Persist unversioned metadata to local store

 where         // Only store the metadata after we have validated it.         if fetched {             client-                .store_metadata(&root_path, &root_version, &raw_root)+                .store_metadata(&root_path, &MetadataVersion::None, &raw_root)                 .await; -            // FIXME: should we also store the root as `MetadataVersion::None`?+            // FIXME: This isn't a part of the spec, but we also store the versioned metadata. This+            // allows us to initialize a repository from the local emtadata.

Fixed, thanks.

erickt

comment created time in 12 days

PullRequestReviewEvent

push eventerickt/rust-tuf

Erick Tryzelaar

commit sha a13f829e8bf2b777759ccaaf3a8386a0991fe3c4

Cite TUF spec, move timestamp expiry check to end. This adds direct citations of the TUF-1.0.5 spec in the `Tuf` client to make it easier for reviewers to directly see how each code block implements the spec, or how we diverge from it. It makes one minor code change. Previously the timestamp expiration was performed after signature verification. This moves the expiration check to be the last check to match the spec. Change-Id: I4125ff4d2e40abdbb177c03665d591b5c90e1794

view details

heartsucker

commit sha 7f332eb516cb0d9c8ad25833fd6328b208c29ee4

Merge pull request #299 from erickt/cite Cite TUF spec, move timestamp expiry check to end.

view details

Erick Tryzelaar

commit sha de626769c207ce84624277d811ba2af5c4dc733a

Fix typo Change-Id: I81d1718a78e752b8db4fac1da36127fb009dc8ee

view details

Erick Tryzelaar

commit sha 74af84d0bf26eea5beca1c049d2d3c8b03b1c680

Merge remote-tracking branch 'remotes/origin/upstream/develop' into persist Change-Id: I0dfff9a79215ade0a7793958fb1e2644e2c1df9d

view details

push time in 12 days

delete branch erickt/argh

delete branch : parse-errors

delete time in 12 days

push eventgoogle/argh

Erick Tryzelaar

commit sha c728c85810957bbf70e0b3287dc4e3c12a4fff5f

Fix quoting in errors when parsing arguments This closes quotes in error messages when parsing arguments. Test: Added tests to make sure the error message when parsing arguments is as expected, as well as added a test to check parsing options. Closes #52

view details

Erick Tryzelaar

commit sha d6abe829614e2475ac23ad8378f23e14f9207023

Merge pull request #64 from erickt/parse-errors Fix quoting in errors when parsing arguments

view details

push time in 12 days

PR merged google/argh

Fix quoting in errors when parsing arguments

This closes quotes in error messages when parsing arguments.

Test: Added tests to make sure the error message when parsing arguments is as expected, as well as added a test to check parsing options.

Closes #52

+42 -1

0 comment

2 changed files

erickt

pr closed time in 12 days

issue closedgoogle/argh

A single quote is missing in the "Error parsing positional argument" message

I tried:

#[derive(argh::FromArgs)]
#[argh(description = "...")]
struct Args {
    #[argh(positional)]
    n: usize,
}

When I ran cargo run invalid-argument, it printed:

Error parsing positional argument 'n' with value 'invalid-argument: invalid digit found in string

A single quote was missing. It should be Error parsing positional argument 'n' with value 'invalid-argument': invalid digit found in string, just like error messages for non-positional arguments: https://github.com/google/argh/blob/8d9a82f46634a4dd2600872f93e449cf23eb5299/src/lib.rs#L429 Corresponding source code: https://github.com/google/argh/blob/8d9a82f46634a4dd2600872f93e449cf23eb5299/src/lib.rs#L448 A single quote should be inserted after arg.

closed time in 12 days

hyd-dev

delete branch erickt/argh

delete branch : remove-lock

delete time in 12 days

push eventgoogle/argh

Erick Tryzelaar

commit sha e91274f26b8c26b44180c74221beb585963c790c

Remove lockfile Closes #55

view details

Erick Tryzelaar

commit sha 14fc76dc2e91957b970a58231e53f09d9601a6c6

Merge pull request #66 from erickt/remove-lock Remove lockfile

view details

push time in 12 days

PR merged google/argh

Remove lockfile

Closes #55

+0 -76

0 comment

1 changed file

erickt

pr closed time in 12 days

issue closedgoogle/argh

Add `Cargo.lock` to `.gitignore`

It is recommended not to track Cargo.lock in Rust libraries, and to track it for binaries only. argh is a library. Shouldn't we add it to .gitignore ?

closed time in 12 days

victordeleau

PR opened google/argh

Remove lockfile

Closes #55

+0 -76

0 comment

1 changed file

pr created time in 12 days

push eventerickt/argh

Erick Tryzelaar

commit sha e91274f26b8c26b44180c74221beb585963c790c

Remove lockfile Closes #55

view details

push time in 12 days

create barncherickt/argh

branch : remove-lock

created branch time in 12 days

delete branch erickt/rust-tuf

delete branch : cite

delete time in 12 days

issue commenttheupdateframework/specification

Rewriting the workflow to call out to sub-sections

I've started experimenting with the tool bikeshed, which is the tool whatwg and a few other standards committees use for their specs. I made some slight format changes to the TUF spec in order to make bikeshed happy, which renders out here. I haven't tried playing with any more of the advanced features of bikeshed yet though, but it certainly seems like an interesting tool.

erickt

comment created time in 12 days

push eventerickt/specification

Erick Tryzelaar

commit sha df24d0852cf66ec2243cc2deae996e5c27069361

change headers

view details

push time in 12 days

create barncherickt/specification

branch : bs

created branch time in 12 days

Pull request review commentgoogle/argh

Expose HelpMessage and allow for custom help switches

 impl<T: SubCommand> SubCommands for T {     const COMMANDS: &'static [&'static CommandInfo] = &[T::COMMAND]; } +/// A `HelpMessage` implementation that provides a help/usage message corresponding+/// to the type's `FromArgs` implementation.+pub trait HelpMessage: FromArgs {

Why an additional trait instead of adding a method to FromArgs?

msrd0

comment created time in 13 days

PullRequestReviewEvent
PullRequestReviewEvent

pull request commentgoogle/argh

Use command base name not full path.

@mboetger would you be able to add some tests for this?

mboetger

comment created time in 13 days

PullRequestReviewEvent

Pull request review commentgoogle/argh

Expose HelpMessage and allow for custom help switches

 pub struct TypeAttrs {     pub is_subcommand: Option<syn::Ident>,     pub name: Option<syn::LitStr>,     pub description: Option<Description>,+	pub disable_help: Option<syn::LitBool>,

Stylistically, I think flipping this to "enable_help" reads a bit better. That avoids devs having to mentally parse expressions like if !disable_help { ... }.

msrd0

comment created time in 13 days

PullRequestReviewEvent
PullRequestReviewEvent

PR opened google/argh

Fix quoting in errors when parsing arguments

This closes quotes in error messages when parsing arguments.

Test: Added tests to make sure the error message when parsing arguments is as expected, as well as added a test to check parsing options.

Closes #52

+42 -1

0 comment

2 changed files

pr created time in 13 days

create barncherickt/argh

branch : parse-errors

created branch time in 13 days

fork erickt/argh

Rust derive-based argument parsing optimized for code size

fork in 13 days

pull request commentgoogle/argh

prevent duplicate long names

This looks good, but it needs a test.

benbrittain

comment created time in 13 days

created taggoogle/argh

tag0.1.3

Rust derive-based argument parsing optimized for code size

created time in 13 days

push eventgoogle/argh

Eli Lipsitz

commit sha 2517d3fdb27e9b60ea2aaa62d5e6b1b60ccb8749

Run rustfmt to fix a pre-existing formatting issue

view details

Eli Lipsitz

commit sha 9022148be937fb6a590b665765200fd0acfe4591

Add support for option delimiter "--" Following the Fuchsia CLI Tool Rubric (https://fuchsia.dev/fuchsia-src/concepts/api/cli#option_delimiter), this adds support for "--", which denotes the end of the options list. All arguments that come after this point will be treated as positional, even if they begin with "-". Closes #58. Closes #59.

view details

Erick Tryzelaar

commit sha f3da6ae16c87537bec6a2a6571568cc2a0b47653

Merge pull request #60 from elipsitz/support-option-delimiter Add support for option delimiter "--"

view details

push time in 13 days

PR merged google/argh

Add support for option delimiter "--"

Following the Fuchsia CLI Tool Rubric (https://fuchsia.dev/fuchsia-src/concepts/api/cli#option_delimiter), this adds support for "--", which denotes the end of the options list. All arguments that come after this point will be treated as positional, even if they begin with "-".

Closes #58. Closes #59.

+30 -9

1 comment

2 changed files

elipsitz

pr closed time in 13 days

issue closedgoogle/argh

Support option delimiter in argh

Two dashes ('--') will indicate the end of argument options. All subsequent values are given to the tool as-is. For example, with "Usage: foo [-a] <file>", the command line "foo -- -a" may interpret -a as a file name rather than a switch. Further, "foo -a -- -a" enables the switch -a (the first -a, before the --) and passes the literal text -a (the second -a).

This option is supported in various tools. Would be useful to support here too.

closed time in 13 days

ankurmittal

issue closedgoogle/argh

Interleaved positional arguments and switches/options are parsed in unexpected ways

I have a command that ends up running another program with some CLI arguments. I have a struct like:

#[derive(Debug, FromArgs)]
struct Args {
    #[argh(switch, short = 'v')]
    verbose: bool,

    #[argh(positional)]
    program: String,

    #[argh(positional)]
    args: Vec<String>,
}

argh allows options and switches to be parsed even after position arguments are found, which leads the following behavior:

Examples

Correct

-v program arg1 arg2 arg3 is parsed as {verbose: true, program: "program", args: ["arg1", "arg2", "arg3"]}

Not correct

program --option-for-the-program doesn't parse, because --option-for-the-program isn't a valid argument for Args.

I would expect it to parse as {verbose: false, program: "program", args: ["--option-for-the-program"]}.

Not correct

program arg1 arg2 -v arg3 bizarrely parses as {verbose: true, program: "Program", args: ["arg1", "arg2", "arg3"]}.

I would expect it to parse args as ["arg1", "arg2", "-v", "arg3"].

Not correct

Similar to above, program arg1 arg2 -p arg3 fails to parse because -p is treated as a switch for the top level command.

Fix

A fix for all of this would be to stop parsing options/switches once we hit a positional argument, and definitely don't allow options/switches to come in the middle of a Vec positional argument.

The issue with this fix is that some people might want to run their commands like tar my_dir/ -f output.tar instead of tar -f output.tar my_dir/ -- this would break that.

One could definitely argue that my use case is weird and not particularly suited for argh. However, consider a more reasonable (albeit slightly contrived) example:

#[derive(Debug, FromArgs)]
/// Sums some numbers.
struct Sum {
    /// the numbers
    #[argh(positional)]
    numbers: Vec<i64>,
}

This returns the correct results for sum 1 2 3 4 5, but breaks if you give it sum 4 7 -8 3 5 (erroring with "Unrecognized argument: -8"), because of the same issue.

closed time in 13 days

elipsitz
PullRequestReviewEvent

push eventerickt/rust-tuf

Erick Tryzelaar

commit sha 331d96624a93dc1326cba794c7670d1df3c1c8c2

Persist unversioned metadata to local store The TUF-1.0.9 spec states that the metadata should be written to non-volatile storage as an unversioned path after verification. This also keeps the extension where we also persist the versioned root metadata. This allows a client to be initialized first from an trusted root metadata (which could be stored in read-only storage), then load metadata from the local store, and finally then the remote metadata. Change-Id: Id62685db069b65e094666c97464583df4c2a1163

view details

push time in 14 days

issue commenttheupdateframework/taps

Allowing TAPs that are licensed with MIT or Apache 2.0?

@trishankatdatadog I don't currently have approval to submit changes under Open Publication License, but I do with MIT or Apache 2.0. It would be convenient for me to avoid having to seek approval from work. Also pre-approved are creative commons licenses like CC-By if that's more appropriate.

erickt

comment created time in 14 days

issue openedheartsucker/rust-tuf

Client should initialize itself from the local metadata

While Client persists metadata to the local store, the only time it actually tries to use it is when we try to fetch the initial trusted root metadata. We should change the Client to initialize itself with the rest of the local metadata.

created time in 15 days

issue commenttheupdateframework/taps

Allowing TAPs that are licensed with MIT or Apache 2.0?

  1. Unfortunately I am not qualified to answer on the pros and cons of dual licensing. Does CNCF has resources to help answer that kind of question?
  2. For my purposes, I wouldn't needed the change to be retroactive. I would just prefer to use one or the other to post new TAPs.
erickt

comment created time in 15 days

issue commenttheupdateframework/taps

Allowing TAPs that are licensed with MIT or Apache 2.0?

Note that Rust dual licenses their RFCs with MIT and Apache 2.0, and Swift and Kubernetes license their extensions with Apache 2.0.

erickt

comment created time in 15 days

more