profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/erickt/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

cadencemarseille/rust-pcre 24

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.

brson/compiler-rt 0

Mirror of official compiler-rt git repository located at http://llvm.org/git/compiler-rt. Updated hourly.

issue commenttheupdateframework/taps

Discussion of TAP 14: Managing TUF Versions

If the root metadata format changes (for example Update reference POUF to use DSSE #143), a client on an older version may not be able to find the spec versions. It might be alright to limit future changes so that this field must be accessible.

Yeah, there's a bit of a bootstrapping issue that we need to work around to support this. For Fuchsia, I think I mentioned in a separate ticket we distribute our OS updates with Fuchsia, so a user could put a device running our initial version in a closet, and it still should be able to take an update when plugged in before the device has been End-of-Life-d. So we need them to be able to update to a client version gate, which can then be used to update to the next version gate, and etc until they're fully up to date. So whatever mechanism we chose it needs to support a gradual migration.

Delegated targets would have to change spec versions in sync with the top-level roles. In some implementations, these delegated targets are controlled by different entities, and so this would take some coordination. Major spec version changes should be rare, so this would only be an occasional annoyance.

I haven't actually worked with delegated targets yet, so I don't have much intuition with them yet. Maybe we could have an analogous spec version field in the targets metadata for them? This could allow the core metadata to migrate first, but allow delegated targets to take more time to migrate.

Metadata from different spec versions would need to be discoverable on the repository. If there is a snapshot metadata for both version 3 and version 4, how are these named?

By "version 3 and version 4", do you mean the spec versions for these files, or the metadata versions? Maybe we need another name for this. What if we used the terminology "epoch" or "tuf spec epoch" to avoid this ambiguity? I've seen this used elsewhere.

Anyway, presuming you are referring to tuf spec version / tuf spec epoch, I see this as something that always goes forward in time. We always want to use the latest supported tuf spec version / epoch version that's available. So I'd assume these paths would be 3.0.0/5.snapshot.json and 4.0.0/5.snapshot.json.


Also, coming over from #138, a repository migrating from one POUF to another can break clients, even if the semantics of the TUF spec stay the same. For example, switching from json to DSSE, and maybe down the road to the binary COSE format. Would it make sense to consider a repository version / epoch as well, or in replacement for supporting TUF spec version changes? Having this under repo control could allow for more radical changes like this.

One other small thing. If these subdirectories are only ever the major version, could we name them after the major version as "3/" rather than "3.0.0/"? That'd avoid the risk of a library using the full tuf spec version.

mnm678

comment created time in 11 days

issue commenttheupdateframework/taps

Discussion of TAP 14: Managing TUF Versions

If I’m reading TAP-14 correctly, it seems that repositories must now support browsing directories. Could we consider alternatives for this? There’s no canonical way for listing directories on a web server, and so most implementations just present a non-portable human readable interface.

Furthermore, even if there was a convention, these directories could be quite large, so it’d add a lot of overhead to the update process.

Instead, I can think of two alternatives. First, we could have a top-level file that lists all the metadata directories. But this has the downside of how do we evolve this file over time.

Second, the root metadata could contain a field for an array of the spec versions in the repo that it knows about that are greater than the current version.

This has a number of advantages. First, the client must know how to read this field, since it needs the ability to read the root metadata. Second, the field is signed, and less subject to attack. Third, we can skip an extra request. Forth, this allows an old client to update, even if we stop updating the old metadata.

To do the last one, presume we have a repo with metadata for versions 1 and 2. We marked the version 1 root as obsolete, and let the metadata expire. Included in the last transaction of version 1 is a new client that can read version 2.

Then, say we have a client that’s been offline for a while, and only knows how to read version 1. When it comes online, it updates to the latest root from spec version 1. Since the metadata is expired, typically the client would just error out at this point, but because the client can see the metadata is obsolete, it knows it’s stuck in this state. It could decide to instead use the latest expired in version 1 to update the client. Then the new client could be used to update to version 2 of the metadata.

mnm678

comment created time in 13 days

PullRequestReviewEvent

Pull request review commenttheupdateframework/taps

TAP for TUF developer key management

+* TAP:+* Title: Ephemeral identity verification using Sigstore's Fulcio for TUF developer key management+* Version: 0+* Last-Modified: 27/07/2021+* Author: Marina Moore, Joshua Lock, Asra Ali, Luke Hinds, Jussi Kukkonen, Trishank Kuppusamy, axel simon+* Type: Standardization+* Status: Draft+* Content-Type: markdown+* Created: 27/07/2021+* TUF-Version:++# Abstract+In order to achieve end-to-end software update security, TUF requires developers to sign updates with a private key. However, this has proven challenging for some implementers as developers then have to create, store, and secure these private keys in order to ensure they remain private. This TAP proposes using Sigstore’s Fulcio project to simplify developer key management by allowing developers to use existing accounts to verify their identity when signing updates. TUF targets roles may delegate to Fulcio identities instead of private keys, and these identities, and the corresponding certificates can be used for verification.++# Motivation+Developer key management has been a major concern for TUF adoptions, especially for projects with a small number of developers or limited resources. TUF currently requires that every targets metadata signer creates and manages a private key. However, many developers in large TUF adoptions, including PyPI, do not want the extra burden of protecting a private key for use in deployment.++Protecting a private key from loss or compromise is no simple matter. [Several](https://blog.npmjs.org/post/185397814280/plot-to-steal-cryptocurrency-foiled-by-the-npm) [attacks](https://jsoverson.medium.com/how-two-malicious-npm-packages-targeted-sabotaged-one-other-fed7199099c8) on software update systems have been achieved through the use of a compromised key, as securing private keys can be challenging and sometimes expensive (using hardware tokens such as Yubikeys etc), especially over a period of time.  ++This TAP proposes a way for developers to use their existing OpenID Connect (OIDC) accounts – such as an email account – to verify their identity, so that they do not have to manage any additional keys or passwords.++# Rationale+In a previous draft of [PEP 480](https://www.python.org/dev/peps/pep-0480/), the authors proposed using [MiniLock](https://www.minilock.io) - a tool which derives ed25519 keys from a user-chosen passphrase - to simplify developer key management. However, this requires developers to remember a new and additional passphrase for use when uploading packages. Furthermore, the MiniLock project is [no longer maintained](https://github.com/kaepora/miniLock).++In this TAP, we instead propose use of the sigstore project. Sigstore has a growing number of adoptions, and provides a simple mechanism for developers to verify their identity using short-lived keys and ad-hoc certificates issued on the basis of OIDC. Sigstore provides two services, [Fulcio](https://github.com/sigstore/fulcio) (a WebPKI) and [Rekor](https://github.com/sigstore/rekor) (a transparency log). With sigstore, long-term efforts to keep private keys secure are not necessary, as short-lived keys are only valid for a small window of time. Fulcio certificates and client generated signatures are published to a timestamped transparency log managed by Rekor so that verifiers can ensure that the certificates were valid at the time of the signature.

By using OIDC, does this mean we need to communicate with the server in order to verify they’re properly signed? That seems fine for certain use cases, but I believe this means we can’t use this key type for a client metadata backstop if we land #128.

mnm678

comment created time in 14 days

Pull request review commenttheupdateframework/taps

TAP-X / POUF-1: Remove signature wrapper from TUF spec, and update reference implementation to use DSSE

+* TAP: 17+* Title: Remove Signature Wrapper from the TUF Specification+* Version: 0+* Last-Modified: 22/06/2021+* Author: Aditya Sirish A Yelgundhalli, Marina Moore+* Type: Standardization+* Status: Draft+* Content-Type: markdown+* Created: 30/04/2021+* +TUF-Version:+* +Post-History:++# Abstract++This TUF Augmentation Proposal (TAP) proposes removing the definition of a+specific signature wrapper and key definitions, and instead defines certain+properties a wrapper must have. Further, it suggests POUF-1 as an example+implementors can refer to when choosing to generate TUF metadata.++# Specification++The TUF specification currently, as of June 2021, uses a custom signature+wrapper. At the time of authoring this document, the primary reference+implementation written in Python also generates TUF metadata using the same+signature wrapper.++However, TUF does not mandate the use of this signature wrapper, nor any+specific metaformat. Indeed, TAP-11, "Using POUFs for Interoperability" enables+adopters to make their own decisions for their implementations, and provides a+mechanism for them to document their decisions. POUF-1 is the POUF for the+official reference implementation, and it seems like the obvious choice for this+information to be specified.++Section 4.2 of the TUF specification, titled "File formats: general principles"+may be replaced by a description of the properties that any signature wrapper used+by a TUF implementation must provide. Some important properties:++* SHOULD include an authenticated payload type+* SHOULD avoid depending on canonicalization for security+* SHOULD NOT require the verifier to parse the payload before verifying+* SHOULD NOT require the inclusion of signing key algorithms in the signature+* MUST support the inclusion of multiple signatures in a file+* SHOULD support a hint indicating what signing key was used, i.e., a KEYID++The presence of an authenticated payload type can be valuable for a project like TUF,+with multiple implementations and derivatives. Indeed, every POUF that describes an+implementation MUST choose a unique payload type, ensuring that there is no confusion+about which implementation generated some piece of metadata.++# Motivation++TAP-11 introduced the concept of POUFs but the TUF specification continues to+specify example formats, namely those used by the reference implementation as+of June 2021. These definitions are essentially replicated in POUF-1, which is+meant to be the authoritative source for information about the reference+implementation. By replacing these definitions with *properties* that a wrapper+must possess, the specification can aid adopters with the development of their+implementations and the POUF can serve as an example. In this scenario, both+documents are serving the purpose originally envisioned for them.++Further, the examples used in the specification are from the old signature+wrapper that includes certain side effects:+* it requires canonicalization before signature verification+* it does not allow for distinguishing different implementations that may have slightly different formats, i.e., it's missing a payload type++# Rationale++Moving the signature wrapper details out of the specification, and instead+requiring adopters to refer to POUFs for examples ensures a clean separation+between implementation details and the TUF specification. Indeed, it also+ensures that the focus of the reader is on only the TUF primitives rather+than burdening them with the specifics of the signature wrapper.++# Security Analysis++Any implementations that build on the properties listed in this document+will have their security enhanced.++# Backwards Compatibility++No backwards incompatibility.

Yeah, we are quite interested in switching to DSSE, and we’d appreciate any guidance on making the transition. Our situation is complicated by us having to support products that don’t support DSSE need to use TUF to update to the latest version.

I’m guessing we will have to either use a tombstone repo which updates us to some new version that points at the new DSSE repo, or we start publishing the metadata in both formats, where the metadata files have different file extensions.

adityasaky

comment created time in 14 days

PullRequestReviewEvent

PR opened rust-lang/libc

Revert "fuchsia add getrandom equivalent zx_cprng_draw."

This reverts commit 5b8616e478d3f76cfd4bc94f9dd4499103c41d51.

I'm on the Fuchsia Rust team, and we would like this reverted for a few reasons. First, these functions are not actually exposed in our libc. Instead, it comes from our libzircon library. Second, we haven't solidified these APIs, nor have we committed to exactly which library to expose them from.

Instead, we've created https://crates.io/crates/fuchsia-cprng to expose this functionality. This lets us more easily track our downstream users, and help them update if we ever make a breaking change.

cc @devnexen and @anp

+0 -8

0 comment

2 changed files

pr created time in 21 days

create barncherickt/libc

branch : remove-cprng

created branch time in 21 days

fork erickt/libc

Raw bindings to platform APIs for Rust

https://rust-lang.github.io/libc/

fork in 21 days

push eventgoogle/argh

Leonardo Razovic

commit sha 1f86793fad050769bf6953078176056a1a7a5f82

Remove unneeded `clone`

view details

Leonardo Razovic

commit sha 1e71aa1e4b8a8b2dd0f106fe0206fb863ca9209f

Remove unneeded `into`

view details

push time in 22 days

PR merged google/argh

Remove unneeded `clone` and `into`

This PR aims to remove unneeded clone, removing unnecessary duplication of objects in memory and unneeded into, that uselessly convert to the same type.

+8 -8

0 comment

1 changed file

lrazovic

pr closed time in 22 days

PullRequestReviewEvent

created taggoogle/argh

tag0.1.6

Rust derive-based argument parsing optimized for code size

created time in 22 days

delete branch erickt/argh

delete branch : bump

delete time in 22 days

push eventgoogle/argh

Erick Tryzelaar

commit sha 4680f75a89b70f38510856113ecb4f64b4b37340

Prepping for release

view details

Erick Tryzelaar

commit sha 00a3542c894682487df9f126c88f8c8085d43225

Revert back to using license I didn't realize that `license-file` was for nonstandard licenses. Closes #101

view details

push time in 22 days

issue closedgoogle/argh

Why change from license to license-file?

I saw 329890897aac903864c6b3e1672d8ce32a3ef5c3 "Use license-file to point at license" and it strikes me as a step backward, or rather at least removing the license attribute does. According to the documentation (emphasis added):

If a package is using a nonstandard license, then the license-file field may be specified in lieu of the license field.

But this package is not using a nonstandard license. That doesn't seem to mean that we cannot use license-file instead, but doing so means that we have to verify that LICENSE contains a standard license, and in some cases consider any variation.

Can both license and license-file be used instead? And if not both, can the change be reverted so that we're not losing this important license information?

closed time in 22 days

ajorg-aws

PR merged google/argh

Prepping for release
+8 -8

0 comment

3 changed files

erickt

pr closed time in 22 days

push eventerickt/argh

Erick Tryzelaar

commit sha a9dab134f9df2edfd3145d31e4bbfd329902b1c8

Revert back to using license I didn't realize that `license-file` was for nonstandard licenses. Closes #101

view details

push time in 24 days

issue commentgoogle/argh

Why change from license to license-file?

Ah, thanks for the reference, I now see I misunderstood license-file. I'll revert back to license.

ajorg-aws

comment created time in 24 days

push eventgoogle/argh

Kafji

commit sha dcb261b4a6b9495b9c65ffdc87f0563d23db8e85

Move tests into argh package `cargo test` won't run the tests if it's located in the workspace root dir.

view details

Kafji

commit sha 617fb6ff202c55ed2c1e67b6ddc2d4a11bc4c62e

Make positional arg honor `arg_name`

view details

push time in 24 days

PR merged google/argh

Make positional arg honor arg_name

Closes #28


Question. How do I run the integration tests in ./tests? cargo test won't run them. I had to move it into argh package so cargo test runs them.

On related note, does this mean that the CI https://github.com/google/argh/blob/master/.github/workflows/rust.yml#L17 does not run those tests?

+25 -1

0 comment

2 changed files

kafji

pr closed time in 24 days

issue closedgoogle/argh

Suggestion: `#[argh(rename = "name")]`

Problem: Often, fields that are option members have long (descriptive) names that make sense in the source code, but are too long to type for cli options. The attribute short = 'x' can only take single chars, so that can't be used to shorten them.

Solution: Adding a way to rename cli option members using #[argh(rename = "name")]. Similar to #[serde(rename = "name")].

closed time in 24 days

Boscop
PullRequestReviewEvent

PR opened google/argh

Reviewers
Prepping for release
+5 -5

0 comment

3 changed files

pr created time in 24 days

create barncherickt/argh

branch : bump

created branch time in 24 days

PullRequestReviewEvent
PullRequestReviewEvent

pull request commentgoogle/argh

Use std::result::Result to avoid expanding to type aliases

Thanks!

otavio

comment created time in a month

push eventgoogle/argh

Otavio Salvador

commit sha e4ce5d2f3e1ce90e0a58165c86c4b20d7f3e3b50

Use std::result::Result to avoid expanding to type aliases Fixes: #97 Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>

view details

push time in a month

PR merged google/argh

Use std::result::Result to avoid expanding to type aliases

Fixes: #97 Signed-off-by: Otavio Salvador otavio@ossystems.com.br

+1 -1

2 comments

1 changed file

otavio

pr closed time in a month