profile
viewpoint

cloudera/livy 911

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

cadencemarseille/rust-pcre 18

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/couchrest 2

A RESTful CouchDB client based on Heroku's RestClient and Couch.js

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.

PR opened golang/crypto

ssh: mux.onePacket shouldn't err out on msgs to unknown channels

rfc4254 section 5.4 states that channel request messages sent to an unrecognized channel should be replied with a SSH_MSG_CHANNEL_FAILURE, rather than erring out and closing the mux. This can occur with servers like openssh-portable, which can begin to close a channel and also use that channel for keepalives before it has received a closed response from the client.

Fixes golang/go#38908

Change-Id: Id68b77e16b2889d3a21d505ed8018f9f457e067a

+218 -1

0 comment

2 changed files

pr created time in 20 days

create barncherickt/crypto

branch : unknown-channels

created branch time in 20 days

issue openedgolang/go

x/crypto/ssh: mux.onePacket shouldn't err if it receives a message to a closed channel

<!-- Please answer these questions before submitting your issue. Thanks! For questions please use one of our forums: https://github.com/golang/go/wiki/Questions -->

What version of Go are you using (go version)?

<pre> $ go version go version go1.14.2 darwin/amd64 </pre>

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

<details><summary><code>go env</code> Output</summary><br><pre> $ go env GO111MODULE="" GOARCH="amd64" GOBIN="" GOCACHE="/Users/etryzelaar/Library/Caches/go-build" GOENV="/Users/etryzelaar/Library/Application Support/go/env" GOEXE="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="darwin" GOINSECURE="" GONOPROXY="" GONOSUMDB="" GOOS="darwin" GOPATH="/Users/etryzelaar/go" GOPRIVATE="" GOPROXY="https://proxy.golang.org,direct" GOROOT="/Users/etryzelaar/homebrew/Cellar/go/1.14.2_1/libexec" GOSUMDB="sum.golang.org" GOTMPDIR="" GOTOOLDIR="/Users/etryzelaar/homebrew/Cellar/go/1.14.2_1/libexec/pkg/tool/darwin_amd64" GCCGO="gccgo" AR="ar" CC="clang" CXX="clang++" CGO_ENABLED="1" GOMOD="/Users/etryzelaar/fuchsia/third_party/golibs/golang.org/x/crypto/go.mod" CGO_CFLAGS="-g -O2" CGO_CPPFLAGS="" CGO_CXXFLAGS="-g -O2" CGO_FFLAGS="-g -O2" CGO_LDFLAGS="-g -O2" PKG_CONFIG="pkg-config" GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/8v/nyxy8zwd67324slpw9kqb_nh00j4g8/T/go-build942647229=/tmp/go-build -gno-record-gcc-switches -fno-common" </pre></details>

What did you do?

<!-- If possible, provide a recipe for reproducing the error. A complete runnable program is good. A link on play.golang.org is best. -->

openssh-portable implements the server-sent keepalives by first trying to send a no-op message on some open channel, before falling back to a global request if no channels are open. We have observed that it's possible for the server to emit a keepalive on a channel it has started to close. This can cause x/crypto/ssh/mux.go to err out. Here's what happens:

<pre> openssh-portable server golang.org/x/crypto/ssh client | | send close channel 1 ---------------> recv close channel 1 | | | + ----- send close channel 1 | | | | | mark channel 1 as closed | | | send keepalive on channel 1 - | ----> recv keepalive on channel 1 | | | recv close channel 1 <--------+ error out, invalid channel 1 |
mark channel 1 as closed
</pre>

This can happen because openssh-portable doesn't remove a channel from the open channel list until it has sent and received the SSH_MSG_CHANNEL_CLOSE message. If things are arranged just right, openssh-portable can send the SSH_MSG_CHANNEL_CLOSE, then the keepalive timer can trigger sending a SSH_MSG_CHANNEL_REQUEST before it has received a SSH_MSG_CHANNEL_CLOSE. From x/crypto/ssh's perspective, it has received and sent the closed messages, so it closes the channel, then receives a message to that closed channel.

While I think it would be nice if openssh-portable removed a partially closed channel from consideration for keepalives, rfc4254 section 5.3 suggests that it only needs to consider it closed if it's sent and received the closed messages. Furthermore, rfc4254 section 5.4 suggests that unrecognized requests should be replied with a SSH_MSG_CHANNEL_FAILURE:

If 'want reply' is FALSE, no response will be sent to the request. Otherwise, the recipient responds with either SSH_MSG_CHANNEL_SUCCESS, SSH_MSG_CHANNEL_FAILURE, or request-specific continuation messages. If the request is not recognized or is not supported for the channel, SSH_MSG_CHANNEL_FAILURE is returned.

What did you expect to see?

mux.go should send back a failure message and continue processing requests and responses.

What did you see instead?

mux.go errs out, which results in ssh.Client closing with an EOF.

created time in 20 days

fork erickt/crypto

[mirror] Go supplementary cryptography libraries

https://godoc.org/golang.org/x/crypto

fork in 20 days

PR opened heartsucker/rust-tuf

Add RepoBuilder metadata generator, and tests

This is a stack of a few patches. First, it introduces RepoBuilder, a helper builder that takes away some of the boilerplate for writing metadata. It's not complete though, so I've left it private and only exposed to tests. It needs the following fixed before I think we should expose it:

  • Fetch and validate the old metadata before basing new metadata off of it.
  • Don't overwrite metadata that already exists.
  • Auto-increment the version numbers.
  • Optionally allow the timestamp version number to be generated off of the current UTC time, to ease working with test repositories.
  • Merge targets and delegates.
  • Come up with a better way to handle delegation metadata.
  • Add documentation and examples.
  • Make a proper error for when repo_builder::sign is given an empty vec of private keys.

In addition, it adds and extends a of tests to use it, and finally, I found and fixed a bug that prevented delegated target descriptions from being fetched. I added a test for this as well to make sure it keeps working.

+508 -347

0 comment

3 changed files

pr created time in a month

create barncherickt/rust-tuf

branch : ver

created branch time in a month

pull request commentheartsucker/rust-tuf

Add functions to get current trusted versions of metadata.

There isn't a convenient test to bootstrap this on, so I'm going to land it now, and add a better test for this in a new PR.

wittrock

comment created time in a month

push eventheartsucker/rust-tuf

John Wittrock

commit sha 6a0824dd1427da4090980ae5c8f1b4729312a102

Add functions to get current trusted versions of metadata. Will be useful for debugging client behavior.

view details

Erick Tryzelaar

commit sha 8c97b8d5e2ccfa017b062980329dd152973119f1

Merge pull request #285 from wittrock/develop Add functions to get current trusted versions of metadata.

view details

push time in a month

PR merged heartsucker/rust-tuf

Add functions to get current trusted versions of metadata.

Will be useful for debugging client behavior.

+32 -1

0 comment

2 changed files

wittrock

pr closed time in a month

Pull request review commentheartsucker/rust-tuf

Add functions to get current trusted versions of metadata.

 mod test {         assert_eq!(client.update().await, Ok(true));         assert_eq!(client.tuf.root().version(), 2); +        assert_eq!(client.root_version(), 2);+        assert_eq!(client.timestamp_version(), Some(1));+        assert_eq!(client.snapshot_version(), Some(1));+        assert_eq!(client.targets_version(), Some(1));+        assert_eq!(client.delegations_version(&snapshot_path), None);

Can you add a test to check delegations_version returns a value?

wittrock

comment created time in a month

issue commenttheupdateframework/specification

Canonical JSON may not be valid JSON

I recently learned of another attempt at a canonicalization scheme in the draft IETF spec rundgren-json-canonicalization-scheme. It doesn't have the same issue where strings may contain invalid JSON characters. It's probably a drop-in replacement for most TUF implementations, which I think don't actually allow for invalid JSON characters.

daurnimator

comment created time in 2 months

Pull request review commenttheupdateframework/taps

Add TAP for keyid flexibility

+* TAP: TBD+* Title: Improving keyid flexibility+* Version: 1.0.0+* Last-Modified: 19-03-2020+* Author: Marina Moore+* Status: Draft+* Content-Type: markdown+* Created: 18-03-2020+* TUF-Version: 1.1.0+* Post-History: <dates of postings to the TUF mailing list>++# Abstract++Keyids are used in TUF metadata as shorthand references to identify keys. They+are used in place of keys in metadata to assign keys to roles and to identify+them in signature headers. The TUF specification requires that every keyid used+in TUF metadata be calculated using a SHA2-256 hash of the public key it+represents. This algorithm is used elsewhere in the TUF specification and so+provides an existing method for calculating unique keyids. Yet, such a rigid+requirement does not allow for the deprecation of SHA2-256. A security flaw in+SHA2-256 may be discovered, so TUF implementers may choose to deprecate this+algorithm. If SHA2-256 is deprecated in TUF, it should no longer be used to+calculate keyids. Therefore TUF should allow more flexibility in how keyids are+determined. To this end, this TAP proposes a change to the TUF specification+that would remove the requirement that all keyids be calculated using SHA2-256.+Instead, the specification will allow metadata owners to use any method for+calculating keyids as long as each one is unique within the metadata file in+which it is defined to ensure a fast lookup of trusted signing keys. This+change will allow for the deprecation of SHA2-256 and will give metadata owners+flexibility in how they determine keyids.+++# Motivation++Currently, the TUF specification requires that keyids must be the SHA2-256 hash+of the public key they represent. This algorithm ensures that keyids are unique+within a metadata file (and indeed, throughout the implementation) and creates a+short, space-saving representation. SHA2-256 also offers a number of secure+hashing properties, though these are not necessary for these purposes. In this+case SHA2-256 is simply a way to calculate a unique identifier employing an+algorithm that is already in use by the system.++The specification sets the following requirements for keyid calculation:+1. The KEYID of a key is the hexdigest of the SHA2-256 hash of the canonical JSON form of the key.+2. Clients MUST calculate each KEYID to verify this is correct for the associated key.+3. Clients MUST ensure that for any KEYID only one unique key has that KEYID.++## Problems with this requirement+Mandating that keyids be calculated using SHA2-256 has created a number of issues+for some implementations, such as:+* Lack of consistency in implementations that use other hash algorithms for+  calculating file hashes and would prefer not to introduce SHA2-256 for this one+  instance. For example, the PEP 458 implementation (https://python.zulipchat.com/#narrow/stream/223926-pep458-implementation)+  will use the BLAKE2 hashing algorithm throughout the implementation.+* Incompatibility with some smart cards and PGP implementations that have their+  own way of calculating keyids.+* Inability to adapt if SHA2-256 should be deprecated. In such a case, metadata+  owners may decide that maintaining a deprecated algorithm for use in keyid+  calculation does not make sense.+* Space concerns may require even shorter hashes than those SHA2-256 can generate,+  such as an index.+In these and other cases, TUF should provide a metadata file owner with the+flexibility to use keyids that are not calculated using SHA2-256.++# Rationale++TUF uses keyids as shorthand references to identify which keys are trusted to+sign each metadata file. As they eliminate the need to list the full key every+time, they take up less space in metadata signatures than the actual signing+key, reducing bandwidth usage and download times.++The most important quality of keyids used in TUF is their uniqueness. To be+effective identifiers, all keyids defined within a metadata file must be unique.+For example, a root file that delegates trust to root, snapshot, timestamp, and+top-level targets should provide unique keyids for each key trusted to sign+metadata for these roles. By doing so, a client may check metadata signatures+in O(1) time by looking up the proper key for verification.++Failing to provide unique keyids can have consequences for both functionality+and security. These are a few attacks that are possible when keyids are not unique:+* **Invalid Signature Verification**: A client may lookup the wrong key to use+  in signature verification leading to an invalid signature verification error,+  even if the signature used the correct key.+* **Keyid collision**: If root metadata listed the same keyid K for different+  snapshot and root keys, an attacker with access to the snapshot key would also+  be able to sign valid root metadata. Using the snapshot key to sign root+  metadata, the attacker could then list the signature in the header with K. A+  client verifying the signature of this root metadata file, would use K to+  lookup a key trusted to sign root, and would find the snapshot key and+  continue the update with the malicious root metadata. To prevent this+  privilege escalation attack, metadata file owners should ensure that+  every keyid is associated with a single key in each metadata file.+One attack that does not need to be considered is a hash collision. Though an+attacker who is able to exploit a hash collision against the function used to+calculate the keyid will be able to identify another key that hashes to the+value of the keyid, the client will only use a key that is listed in the+metadata. The attacker would not be able to put a malicious key into the+metadata without the metadata signing key, so a hash collision cannot be used+to maliciously sign files.++# Specification++With just a few minor changes to the current TUF specification process, we can+remove the requirement that keyids must be calculated using SHA2-256. First, the+specification wording should be updated to allow the metadata owner to calculate+keyids using any method that produces a unique identifier within the metadata+file. This means replacing requirements 1 and 2 above with a description of+required keyid properties, ie “The KEYID is an identifier for the key that is+determined by the metadata owner and MUST be unique within the root or+delegating targets metadata file.” Once this keyid is determined by the metadata+owner using their chosen method, it will be listed in the delegating metadata+file and in all signatures that use the corresponding key. When parsing metadata+signatures, the client would use the keyid(s) listed in the signature header to+find the key(s) that are trusted for that role in the delegating metadata. This+should be described in the specification by replacing requirement 3 above with+“Clients MUST use the keyids from the delegating role to look up trusted signing+keys to verify signatures.” All metadata definitions would remain the same, but+the client’s verification process would track keyids within each metadata file+instead of globally.++In order for TUF clients to adhere to these specification changes, they may have+to change the way they store and process keyids. Clients will use the keyids+from a metadata file only for all delegations defined in that metadata file. So+if a targets metadata file T delegates to A and B, the client should verify the+signatures of A and B using the trusted keyids in from T. When verifying+signatures, clients should try all signatures that match their trusted keyid(s).+If T trusts keyid K to sign A’s metadata, the client should check all+signatures in A that list a keyid of K. This means that if another metadata file+M delegates to A, it would be able to use the same keyid with a different key.+Once the signatures for A and B have been checked, the client no longer needs to+store the keyid mapping listed in T. During the preorder depth-first search of+targets metadata, the keyids from each targets metadata file should be used in+only that stage of the depth-first search.++These changes to the specification would allow the repository to use any scheme+to determine keyids without needing to communicate it to clients. By making this+scheme independent of the client implementation, root and targets metadata may+use different methods to determine keyids, especially if they are managed by+different people (ie TAP 5). In addition, the repository may update the scheme+at any time to deprecate a hash algorithm or change to a different keyid+calculation method.++## Keyid Deprecation+With the proposed specification changes, the method used to determine keyids+is not only more flexible, but it may be deprecated using the following process+for each key D and keyid K in the root or delegating targets metadata file:+* The owner of the metadata file determines a new keyid L for D using the new method.+* In the next version of the metadata file, the metadata owner replaces K with L+  in the keyid definition for D.+* Any files previously signed by D should list L as the keyid instead of K.+  These files do not need to be resigned as only the signature header will be updated.+Once this process is complete, the metadata owner is using a new method to+determine the keyids used by that metadata file.++As keyid deprecation is executed, it is important that keyids within each+metadata file remain unique. Metadata owners should only publish metadata that+contains a unique keyid to key mapping.++## Implications for complex delegation trees

You touch upon this in the specification, but it might be helpful to also include an example here for the case where the targets metadata file A delegates to C using the key D and the keyid K, as well as another targets metadata B delegates to C using the key E and the keyid K. From what I understand, this should result in C being signed with:

{
    "sigs": [
        {
             "keyid": "K",
             "sig": "1234..."
        },
        {
             "keyid": "K",
             "sig": "abcd..."
        },
        ...
    ],
    ...
}

Both signatures will be checked if the delegation search ever ends up at A or B.

mnm678

comment created time in 2 months

Pull request review commenttheupdateframework/taps

Add TAP for keyid flexibility

+* TAP: TBD+* Title: Improving keyid flexibility+* Version: 1.0.0+* Last-Modified: 19-03-2020+* Author: Marina Moore+* Status: Draft+* Content-Type: markdown+* Created: 18-03-2020+* TUF-Version: 1.1.0+* Post-History: <dates of postings to the TUF mailing list>++# Abstract++Keyids are used in TUF metadata as shorthand references to identify keys. They+are used in place of keys in metadata to assign keys to roles and to identify+them in signature headers. The TUF specification requires that every keyid used+in TUF metadata be calculated using a SHA2-256 hash of the public key it+represents. This algorithm is used elsewhere in the TUF specification and so+provides an existing method for calculating unique keyids. Yet, such a rigid+requirement does not allow for the deprecation of SHA2-256. A security flaw in+SHA2-256 may be discovered, so TUF implementers may choose to deprecate this+algorithm. If SHA2-256 is deprecated in TUF, it should no longer be used to+calculate keyids. Therefore TUF should allow more flexibility in how keyids are+determined. To this end, this TAP proposes a change to the TUF specification+that would remove the requirement that all keyids be calculated using SHA2-256.+Instead, the specification will allow metadata owners to use any method for+calculating keyids as long as each one is unique within the metadata file in+which it is defined to ensure a fast lookup of trusted signing keys. This+change will allow for the deprecation of SHA2-256 and will give metadata owners+flexibility in how they determine keyids.+++# Motivation++Currently, the TUF specification requires that keyids must be the SHA2-256 hash+of the public key they represent. This algorithm ensures that keyids are unique+within a metadata file (and indeed, throughout the implementation) and creates a+short, space-saving representation. SHA2-256 also offers a number of secure+hashing properties, though these are not necessary for these purposes. In this+case SHA2-256 is simply a way to calculate a unique identifier employing an+algorithm that is already in use by the system.++The specification sets the following requirements for keyid calculation:+1. The KEYID of a key is the hexdigest of the SHA2-256 hash of the canonical JSON form of the key.+2. Clients MUST calculate each KEYID to verify this is correct for the associated key.+3. Clients MUST ensure that for any KEYID only one unique key has that KEYID.++## Problems with this requirement+Mandating that keyids be calculated using SHA2-256 has created a number of issues+for some implementations, such as:+* Lack of consistency in implementations that use other hash algorithms for+  calculating file hashes and would prefer not to introduce SHA2-256 for this one+  instance. For example, the PEP 458 implementation (https://python.zulipchat.com/#narrow/stream/223926-pep458-implementation)+  will use the BLAKE2 hashing algorithm throughout the implementation.+* Incompatibility with some smart cards and PGP implementations that have their+  own way of calculating keyids.+* Inability to adapt if SHA2-256 should be deprecated. In such a case, metadata+  owners may decide that maintaining a deprecated algorithm for use in keyid+  calculation does not make sense.+* Space concerns may require even shorter hashes than those SHA2-256 can generate,+  such as an index.+In these and other cases, TUF should provide a metadata file owner with the+flexibility to use keyids that are not calculated using SHA2-256.++# Rationale++TUF uses keyids as shorthand references to identify which keys are trusted to+sign each metadata file. As they eliminate the need to list the full key every+time, they take up less space in metadata signatures than the actual signing+key, reducing bandwidth usage and download times.++The most important quality of keyids used in TUF is their uniqueness. To be+effective identifiers, all keyids defined within a metadata file must be unique.+For example, a root file that delegates trust to root, snapshot, timestamp, and+top-level targets should provide unique keyids for each key trusted to sign+metadata for these roles. By doing so, a client may check metadata signatures+in O(1) time by looking up the proper key for verification.++Failing to provide unique keyids can have consequences for both functionality+and security. These are a few attacks that are possible when keyids are not unique:+* **Invalid Signature Verification**: A client may lookup the wrong key to use+  in signature verification leading to an invalid signature verification error,+  even if the signature used the correct key.+* **Keyid collision**: If root metadata listed the same keyid K for different+  snapshot and root keys, an attacker with access to the snapshot key would also+  be able to sign valid root metadata. Using the snapshot key to sign root+  metadata, the attacker could then list the signature in the header with K. A+  client verifying the signature of this root metadata file, would use K to+  lookup a key trusted to sign root, and would find the snapshot key and+  continue the update with the malicious root metadata. To prevent this+  privilege escalation attack, metadata file owners should ensure that+  every keyid is associated with a single key in each metadata file.+One attack that does not need to be considered is a hash collision. Though an+attacker who is able to exploit a hash collision against the function used to+calculate the keyid will be able to identify another key that hashes to the+value of the keyid, the client will only use a key that is listed in the+metadata. The attacker would not be able to put a malicious key into the+metadata without the metadata signing key, so a hash collision cannot be used+to maliciously sign files.++# Specification++With just a few minor changes to the current TUF specification process, we can+remove the requirement that keyids must be calculated using SHA2-256. First, the+specification wording should be updated to allow the metadata owner to calculate+keyids using any method that produces a unique identifier within the metadata+file. This means replacing requirements 1 and 2 above with a description of+required keyid properties, ie “The KEYID is an identifier for the key that is+determined by the metadata owner and MUST be unique within the root or+delegating targets metadata file.” Once this keyid is determined by the metadata

The KEYID is an identifier for the key that is determined by the metadata owner and MUST be unique within the root or delegating targets metadata file.

Now that there wouldn't be a cryptographically derived keyid for each key, it's now possible to list the same key multiple times, each with a different keyid. Can we instead impose another rule that the key must also be unique? Without this rule, an attacker could duplicate a signature to reduce the effective threshold of keys needed to validate the metadata. We do this in go-tuf and rust-tuf to avoid double counting keys due to our (temporary) support of python-tuf's keyid_hash_algorithms field.

mnm678

comment created time in 2 months

PR opened heartsucker/rust-tuf

Switch to using the serde derive feature

The serde docs now recommend using the derive feature over using serde_derive.

+13 -14

0 comment

7 changed files

pr created time in 2 months

create barncherickt/rust-tuf

branch : serde-derive

created branch time in 2 months

push eventheartsucker/rust-tuf

Yu Shan

commit sha 1f80ec14d3171246568048c69af65ecb028e909e

Deduplicate signatures with the same key_id. We should only verify one signature for one key_id, otherwise an attacker owning one key could simply duplicate one valid signature and thus increasing the number of signatures that are valid. This bypass the limitation of threshold. Tested: Unit tests.

view details

Yu Shan

commit sha 5fc3cf303ec9259c3d3982ff08c1d2ee4a31ff86

Add verification for key ID. TUF spec requires client to check key ID calculation. Due to backward compatibility, instead of giving error when an incorrect key ID is found, we simply ignore that key. Tested: Unit tests.

view details

Erick Tryzelaar

commit sha 62431b1d4dc45fef8c63d900b9b668af5fc33faf

Merge pull request #283 from aabbaabb/develop Deduplicate signatures with the same key_id.

view details

push time in 3 months

PR merged heartsucker/rust-tuf

Deduplicate signatures with the same key_id.

We should only verify one signature for one key_id, otherwise an attacker owning one key could simply duplicate one valid signature and thus increasing the number of signatures that are valid. This bypass the limitation of threshold.

Tested: Unit tests.

+58 -4

0 comment

2 changed files

aabbaabb

pr closed time in 3 months

more