<feed xmlns='http://www.w3.org/2005/Atom'>
<title>mirrors/arti.git/Cargo.lock, branch arti-v1.1.7</title>
<subtitle>mirror of https://gitlab.torproject.org/tpo/core/arti
</subtitle>
<id>http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.1.7</id>
<link rel='self' href='http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.1.7'/>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/'/>
<updated>2023-08-01T15:03:56Z</updated>
<entry>
<title>Bump patchlevel versions of crates with trivial changes</title>
<updated>2023-08-01T15:03:56Z</updated>
<author>
<name>Nick Mathewson</name>
<email>nickm@torproject.org</email>
</author>
<published>2023-08-01T15:01:13Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=5cc3fe162944aff8efb975ac966f0e91b6908281'/>
<id>urn:sha1:5cc3fe162944aff8efb975ac966f0e91b6908281</id>
<content type='text'>
These crates have had trivial changes only: typically,
changes to documentation or to clippy warnings.  There's no
good reason to update which version of them other crates depend on,
so we only bump _their_ patchlevels.

```
tor-async-utils
caret
safelog
tor-events
tor-units
tor-rtcompat
tor-rpcbase
tor-llcrypto
tor-protover
tor-bytes
tor-hscrypto
tor-socksproto
tor-cert
tor-cell
tor-consdiff
tor-congestion
arti-rpcserver
arti-testing
arti-bench
arti-config
arti-hyper
```
</content>
</entry>
<entry>
<title>Increment patchlevel versions of crates with minor changes</title>
<updated>2023-08-01T14:57:55Z</updated>
<author>
<name>Nick Mathewson</name>
<email>nickm@torproject.org</email>
</author>
<published>2023-08-01T14:57:55Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=3acdf102c705314aec63679e97240bb7d981d1c8'/>
<id>urn:sha1:3acdf102c705314aec63679e97240bb7d981d1c8</id>
<content type='text'>
These crates are at version 0.x.y, so we don't need to distinguish
new-feature changes from other changes:

```
tor-basic-utils
fs-mistrust
tor-error
tor-geoip
tor-checkable
tor-linkspec
tor-netdoc
tor-netdir
tor-persist
tor-ptmgr
tor-hsservice
```

This crate has a breaking change, but only when the semver-breaking
feature `experimental-api` is enabled:

```
tor-config
```

This crate is at version 1.x.y, but has no new public APIs, and
therefore does not need a minor version bump:

```
arti
```
</content>
</entry>
<entry>
<title>Update minor versions on crates that have had breaking changes</title>
<updated>2023-08-01T14:51:25Z</updated>
<author>
<name>Nick Mathewson</name>
<email>nickm@torproject.org</email>
</author>
<published>2023-08-01T14:51:25Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=6f2ae5960393b64c1d7615d2d523e050d3bebe5a'/>
<id>urn:sha1:6f2ae5960393b64c1d7615d2d523e050d3bebe5a</id>
<content type='text'>
These crates had first-order breaking changes:

```
retry-error
tor-keymgr
tor-proto
tor-hsclient
tor-rtmock
```

Additionally, these broke because they re-exposed RetryError:

```
tor-circmgr
```

Additionally, these broke because they may re-expose something from
tor-proto:

```
    arti-client
    tor-chanmgr
    tor-dirclient
    tor-dirmgr
    tor-guardmgr
```

Additionally, these broke for other fiddly reasons:

`tor-ptmgr` implements traits from tor-chanmgr, which has a breaking
change above.

`arti-hyper` exposes types from arti-client in its API.
</content>
</entry>
<entry>
<title>Run cargo update in preparation for a release.</title>
<updated>2023-08-01T12:10:44Z</updated>
<author>
<name>Nick Mathewson</name>
<email>nickm@torproject.org</email>
</author>
<published>2023-08-01T12:10:44Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=f37915587e54b7fc8fda3188840ff39afccc39b4'/>
<id>urn:sha1:f37915587e54b7fc8fda3188840ff39afccc39b4</id>
<content type='text'>
</content>
</entry>
<entry>
<title>hashx: use RngCore for HashX's internal PRNG</title>
<updated>2023-07-27T14:20:14Z</updated>
<author>
<name>Micah Elizabeth Scott</name>
<email>beth@torproject.org</email>
</author>
<published>2023-07-18T20:44:28Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=d17c12b152269a011e1dfdf0abfd0c0a8616aee4'/>
<id>urn:sha1:d17c12b152269a011e1dfdf0abfd0c0a8616aee4</id>
<content type='text'>
This refactors the random number generator used within HashX's program
generator so that it uses the rand::RngCore trait. The basic SipHash
powered u64 generator now implements RngCore, while a buffer layer
wraps this and provides u8 and u32 values as needed by the generator.

Some of this new RngCore layer is now exposed to the hashx crate's
public API. The intent is to allow external code to test, benchmark, or
fuzz the program generator by supplying its own random number stream.

Benchmarks show a small but confusing performance improvement
associated with this patch. About a 2% improvement in generation.
This could be due to the Rng changes. No change in compiled hash
execution performance. Even though this patch only touches program
generation, benchmarks show a 4% speedup in interpreted execution.
This seems most likely explained by instruction cache effects,
but I'm not sure.

Signed-off-by: Micah Elizabeth Scott &lt;beth@torproject.org&gt;
</content>
</entry>
<entry>
<title>Start implementing Proposal 327</title>
<updated>2023-07-27T14:20:14Z</updated>
<author>
<name>Micah Elizabeth Scott</name>
<email>beth@torproject.org</email>
</author>
<published>2023-06-28T22:15:17Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=e7aa1d6b6251102f9b2b0e382ad2a1f7b5b47ee5'/>
<id>urn:sha1:e7aa1d6b6251102f9b2b0e382ad2a1f7b5b47ee5</id>
<content type='text'>
This adds a new tor-hspow crate with the first layers of support in
place for onion service client puzzles as described in Proposal 327.

The API here is experimental, and it's currently only implementing
the self-contained parts of the client puzzle. So, it can verify and
solve puzzles, but it has no event loop integration or nonce replay
tracking or prioritization code yet. These things seem like they would
eventually live in the same crate.

Signed-off-by: Micah Elizabeth Scott &lt;beth@torproject.org&gt;
</content>
</entry>
<entry>
<title>Reimplement Equi-X in Rust</title>
<updated>2023-07-27T14:20:14Z</updated>
<author>
<name>Micah Elizabeth Scott</name>
<email>beth@torproject.org</email>
</author>
<published>2023-06-28T22:08:29Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=16c9bdf1785516fc57589786a1a7f250c486e131'/>
<id>urn:sha1:16c9bdf1785516fc57589786a1a7f250c486e131</id>
<content type='text'>
This is a new pure Rust implementation of the Equi-X algorithm
designed by tevador for Tor's onion service proof of work puzzle v1.

Equi-X is an asymmetric puzzle algorithm based on Equihash, with
N=60, K=3, the XOR replaced with modular addition, a 16-bit index
space, and HashX as the inner hash function.

Signed-off-by: Micah Elizabeth Scott &lt;beth@torproject.org&gt;
</content>
</entry>
<entry>
<title>Reimplement HashX in Rust</title>
<updated>2023-07-27T14:20:06Z</updated>
<author>
<name>Micah Elizabeth Scott</name>
<email>beth@torproject.org</email>
</author>
<published>2023-06-28T21:59:46Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=a8756f2bce9f0dba8e445baae82aab90aa9ad096'/>
<id>urn:sha1:a8756f2bce9f0dba8e445baae82aab90aa9ad096</id>
<content type='text'>
This is a new pure Rust implementation of the HashX algorithm
designed by tevador for Tor's onion service proof of work puzzle v1.

HashX is a lightweight family of randomly generated hash functions.
A seed, via blake2 and siphash, drives a program generation model
which randomly selects opcodes and registers while following some
constraints that avoid timing stalls or insufficient hash mixing.

The execution of these hash funcions can be done using a pure Rust
interpreter, or about 20x faster using a very simple just in time
compiler based on the dynasm assembler crate. This has been
implemented for x86_64 and aarch64.

Signed-off-by: Micah Elizabeth Scott &lt;beth@torproject.org&gt;
</content>
</entry>
<entry>
<title>keymgr: Add KeyMgr::generate() for generating new keys.</title>
<updated>2023-07-24T12:17:31Z</updated>
<author>
<name>Gabriela Moldovan</name>
<email>gabi@torproject.org</email>
</author>
<published>2023-07-24T10:56:18Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=f96298a791f696012c572a1df8396eea46d43266'/>
<id>urn:sha1:f96298a791f696012c572a1df8396eea46d43266</id>
<content type='text'>
</content>
</entry>
<entry>
<title>keymgr: Add function for generating EncodableKeys.</title>
<updated>2023-07-24T12:17:23Z</updated>
<author>
<name>Gabriela Moldovan</name>
<email>gabi@torproject.org</email>
</author>
<published>2023-07-24T11:01:59Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=9c326ced816ab4bf9e3e7380f5caa6a6cb05a784'/>
<id>urn:sha1:9c326ced816ab4bf9e3e7380f5caa6a6cb05a784</id>
<content type='text'>
</content>
</entry>
</feed>
