<feed xmlns='http://www.w3.org/2005/Atom'>
<title>mirrors/arti.git/crates/tor-hsclient/src/pow, branch arti-v1.7.0</title>
<subtitle>mirror of https://gitlab.torproject.org/tpo/core/arti
</subtitle>
<id>http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.7.0</id>
<link rel='self' href='http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.7.0'/>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/'/>
<updated>2025-08-07T15:28:36Z</updated>
<entry>
<title>Switch Cargo.toml files to edition 2024.</title>
<updated>2025-08-07T15:28:36Z</updated>
<author>
<name>Nick Mathewson</name>
<email>nickm@torproject.org</email>
</author>
<published>2025-08-06T01:19:58Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=77b0de43b8c67cdb81befe0680a3df43b6ad37bc'/>
<id>urn:sha1:77b0de43b8c67cdb81befe0680a3df43b6ad37bc</id>
<content type='text'>
First, run

```
git grep -l "^edition =" |
    xargs perl -i -pe 's/^edition *=.*/edition = "2024"/;'
```

Second, manually verify that all Cargo.toml files have changed,
and nothing else has changed.

Third, run cargo fmt again.
</content>
</entry>
<entry>
<title>squash! Upgrade rand dependency to 0.9.</title>
<updated>2025-03-18T16:09:44Z</updated>
<author>
<name>Nick Mathewson</name>
<email>nickm@torproject.org</email>
</author>
<published>2025-03-18T13:01:31Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=2f8993c22c2b86010e4fd8b5169ef0ab83f8c754'/>
<id>urn:sha1:2f8993c22c2b86010e4fd8b5169ef0ab83f8c754</id>
<content type='text'>
- `rand::thread_rng()` has been deprecated and renamed to `rand::rng()`
</content>
</entry>
<entry>
<title>Always use full path to rand::thread_rng().</title>
<updated>2025-03-18T16:09:44Z</updated>
<author>
<name>Nick Mathewson</name>
<email>nickm@torproject.org</email>
</author>
<published>2025-03-18T13:00:23Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=30f27c7f8f8028f833ea7e84a034f2416afd447b'/>
<id>urn:sha1:30f27c7f8f8028f833ea7e84a034f2416afd447b</id>
<content type='text'>
This is partly for consistency, and partly to facilitate
a global search-and-replace.
</content>
</entry>
<entry>
<title>hs-pow: Use clamp for clarity.</title>
<updated>2024-10-09T16:05:21Z</updated>
<author>
<name>Wesley Aptekar-Cassels</name>
<email>me@wesleyac.com</email>
</author>
<published>2024-10-01T18:41:56Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=41fc5762a291595e0e23ef1d2ece4294fa52ef12'/>
<id>urn:sha1:41fc5762a291595e0e23ef1d2ece4294fa52ef12</id>
<content type='text'>
Instead of min/max pairs, we can use clamp. And since it's a little
clearer, let's go a bit further and use the same clamp construct with a
lower bound of zero in the other spot we had a min().

Co-authored-by: Micah Elizabeth Scott &lt;beth@torproject.org&gt;
</content>
</entry>
<entry>
<title>hs-pow: Use TimerangeBound for puzzle parameters.</title>
<updated>2024-10-09T16:05:21Z</updated>
<author>
<name>Wesley Aptekar-Cassels</name>
<email>me@wesleyac.com</email>
</author>
<published>2024-10-01T18:34:26Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=aaad814573f7b2fd635811ef4d758c63861fea3f'/>
<id>urn:sha1:aaad814573f7b2fd635811ef4d758c63861fea3f</id>
<content type='text'>
Co-authored-by: Micah Elizabeth Scott &lt;beth@torproject.org&gt;
</content>
</entry>
<entry>
<title>hs-pow: Effort type improvements.</title>
<updated>2024-10-09T16:05:21Z</updated>
<author>
<name>Wesley Aptekar-Cassels</name>
<email>me@wesleyac.com</email>
</author>
<published>2024-10-01T18:19:31Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=8cbc21152dc7bf57be1ecaf9fb7189427fcb908d'/>
<id>urn:sha1:8cbc21152dc7bf57be1ecaf9fb7189427fcb908d</id>
<content type='text'>
The Effort type didn't have any const constructor and we had to
disassemble it to do any arithmetic. This adds a const constructor and
int/float saturating arithmetic methods.

Co-authored-by: Micah Elizabeth Scott &lt;beth@torproject.org&gt;
</content>
</entry>
<entry>
<title>hs-pow: Refactor to prefer stub types rather than cfg sprawl.</title>
<updated>2024-10-09T16:05:15Z</updated>
<author>
<name>Wesley Aptekar-Cassels</name>
<email>me@wesleyac.com</email>
</author>
<published>2024-10-01T18:06:27Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=fd22ee0991dfa639059fd5e96e1e57916771aefb'/>
<id>urn:sha1:fd22ee0991dfa639059fd5e96e1e57916771aefb</id>
<content type='text'>
In this design, the thin multiplexing layer between PoW types is always
available when onion services are in use, but the specific pow schemes
(and their dependency libraries) are gated by crate features everywhere.
There are now no new cfg() gates.

When the pow-v1 scheme is disabled, we can parse `pow-params v1` lines
into an empty type (so clients know a PoW scheme exists that might be
supported if they were configured differently). We currently don't save
the contents of unknown hsdesc items.

On the relaycell side, the hs ext module already sets a strong precedent
for keeping unrecognized data as a byte vec, and it doesn't provide a
good way to signal soft parse errors like unrecognized optional
extensions. There, the `v1` type is completely optional, and services
lacking a pow scheme suggested by a client would see one of these
'unrecognized' blobs. This isn't necessarily helpful but it fits the
rest of the design.

Co-authored-by: Micah Elizabeth Scott &lt;beth@torproject.org&gt;
</content>
</entry>
<entry>
<title>tor-hspow: Big refactor, dissolve this crate</title>
<updated>2024-10-09T16:04:35Z</updated>
<author>
<name>Wesley Aptekar-Cassels</name>
<email>me@wesleyac.com</email>
</author>
<published>2024-09-30T18:50:16Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=5d878d3cc068572d3c14e478051ecc2361ef26b4'/>
<id>urn:sha1:5d878d3cc068572d3c14e478051ecc2361ef26b4</id>
<content type='text'>
My previous strategy here was to try and centralize hspow in one crate,
writing it like a self-contained feature. That introduced friction in
the data types, prompting the use of simplistic types at the netdoc/cell
layers and full-featured types in the optional modules.

This changes tactics, dissolving the low-level parts of tor-hspow into
tor-hscrypto and the high-level parts into hsclient/hsservice. Full
featured types are used everywhere now, but the tradeoff is that
compile-time configurability is a lot more pervasive. Anything that
knows about PoW types at all needs to be fully configured out. I took
this opportunity to try a more complete set of crate features, allowing
users to configure individual PoW schemes.

Co-authored-by: Micah Elizabeth Scott &lt;beth@torproject.org&gt;
</content>
</entry>
</feed>
