<feed xmlns='http://www.w3.org/2005/Atom'>
<title>mirrors/arti.git/crates/tor-hsclient, branch arti-v1.4.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.4.0</id>
<link rel='self' href='http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.4.0'/>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/'/>
<updated>2025-02-06T18:17:34Z</updated>
<entry>
<title>Version bumps to 0.27.0</title>
<updated>2025-02-06T18:17:34Z</updated>
<author>
<name>Ian Jackson</name>
<email>ijackson@chiark.greenend.org.uk</email>
</author>
<published>2025-02-06T18:13:25Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=e590ba4d522b44ffc7adc0eea463309df2de12f3'/>
<id>urn:sha1:e590ba4d522b44ffc7adc0eea463309df2de12f3</id>
<content type='text'>
See Release.md.

maint/list_crates | grep -P '^tor-|^arti-' | xargs -n1 nailing-cargo -Eu set-version --bump minor -p

This completes the version bumps.

The report of changed crates, before I started the release work, is:

$ maint/changed_crates -v "arti-v$LAST_VERSION"
     oneshot-fused-workaround: No change.
     slotmap-careful: No change.
     test-temp-dir: No change.
     fslock-guard: No change.
     hashx: No change.
     equix: No change.
     tor-basic-utils: No change.
     caret: No change.
fs-mistrust
     safelog: No change.
     retry-error: No change.
tor-error
     tor-general-addr: No change.
     tor-geoip: No change.
tor-rtcompat
tor-rtmock
tor-async-utils
tor-config
tor-config-path
tor-rpc-connect
     tor-log-ratelim: No change.
tor-rpcbase
     tor-memquota: No change.
tor-units
     tor-llcrypto: No change.
     tor-protover: No change.
tor-bytes
     tor-checkable: No change.
tor-cert
tor-key-forge
     tor-hscrypto: No change.
     tor-socksproto: No change.
     tor-linkspec: No change.
     tor-cell: No change.
tor-proto
     tor-netdoc: No change.
     tor-consdiff: No change.
tor-netdir
     tor-relay-selection: No change.
tor-persist
tor-chanmgr
     tor-ptmgr: No change.
     tor-guardmgr: No change.
tor-circmgr
     tor-dirclient: No change.
     tor-dirmgr: No change.
tor-keymgr
tor-hsclient
tor-hsservice
     tor-hsrproxy: No change.
tor-relay-crypto
arti-client
arti-relay
arti-rpcserver
arti
arti-rpc-client-core
$
</content>
</entry>
<entry>
<title>proto: Remove ConversationInHandler</title>
<updated>2025-02-04T16:08:43Z</updated>
<author>
<name>David Goulet</name>
<email>dgoulet@torproject.org</email>
</author>
<published>2025-01-30T18:44:52Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=5a9b05e38881e3d227b929b0a2103e9d552cbf71'/>
<id>urn:sha1:5a9b05e38881e3d227b929b0a2103e9d552cbf71</id>
<content type='text'>
It is unused but most importantly it allows any RELAY cell to be sent
from anywhere in the code which is really not desirable because it is
skipping congestion control.

It also allows us to remove the `control_tx` from the reactor which is
one less channel to track/understand/think about.

This opens up the door to all sorts of problems especially side channel
that can be exploited if we are not careful.

We can always bring this back if we need it but for now, it is unused
and allows us to remove the `CtrlMsg::SendRelayCell` control message.

No code behavior change.

Signed-off-by: David Goulet &lt;dgoulet@torproject.org&gt;
</content>
</entry>
<entry>
<title>tor-proto: Rewrite circuit reactor run_once() loop to use select!.</title>
<updated>2025-01-29T14:34:58Z</updated>
<author>
<name>Gabriela Moldovan</name>
<email>gabi@torproject.org</email>
</author>
<published>2025-01-28T15:09:33Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=2eb09f4f925569e08cc54b69d4062a53d01bdfe1'/>
<id>urn:sha1:2eb09f4f925569e08cc54b69d4062a53d01bdfe1</id>
<content type='text'>
This rewrites the circuit reactor main loop to use `select_biased!` to poll
multiple futures simultaneously.

The new `run_once()`, like the old, first waits for an initial
`CtrlMsg::Create`. Then, it uses a `select_biased!` to poll the
`chan_sender` sink and shutdown channel for readiness.

When the channel sink is ready, we poll the `control` and `input`
channels like before, as well as the new `ready_streams` `Stream`
(`ready_streams` is a `futures::Stream` that replaces the previous
`send_outbound()` function).

Most of the implementation remains unchanged, except the `handle_input`,
`handle_cell` and `handle_control` functions no longer send anything on
the `chan_sender` channel. Instead, they may do some (synchronous)
processing, and send instructions for the remaining work that needs to
be done (for example, for writing the cell to the `chan_sender`
channel). These instructions are handled at the end of `run_once()`,
and are encoded in the `RunOnceCmdInner` enum.

What this change does **not** do:
  * the control channel *still* bypasses congestion control. We could
    fix this by making the various reactor functions send the
    `RunOnceCmdInner` commands to `run_once()` via a channel
    (instead of returning them). This would enable the reactor to stop
    reading the commands (except for handle `Sendme`, which would be
    handled separately) if it's blocked on congestion control.
</content>
</entry>
<entry>
<title>circmgr: Remove the CircParameters build .expect()</title>
<updated>2025-01-16T14:16:01Z</updated>
<author>
<name>David Goulet</name>
<email>dgoulet@torproject.org</email>
</author>
<published>2025-01-15T15:46:15Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=ea59eb5a2137a06dbe66f3034d247ff502d9232d'/>
<id>urn:sha1:ea59eb5a2137a06dbe66f3034d247ff502d9232d</id>
<content type='text'>
Instead, return an error and make all call site handle it.

Signed-off-by: David Goulet &lt;dgoulet@torproject.org&gt;
</content>
</entry>
<entry>
<title>circ: Specialize the circparams from netparams function</title>
<updated>2025-01-16T14:16:01Z</updated>
<author>
<name>David Goulet</name>
<email>dgoulet@torproject.org</email>
</author>
<published>2025-01-15T14:41:07Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=9e7f59968f7ed07d18b152d6730efa43fc15ae33'/>
<id>urn:sha1:9e7f59968f7ed07d18b152d6730efa43fc15ae33</id>
<content type='text'>
Congestion control parameters have specific values depending on the
circuit type. Instead of using a CircuitType, which is removed in this
commit, specialize the function in this case onion and exit.

This allows us to get rid of CircuitType and solely use TargetCircUsage
instead.

At this commit, we use .expect() on the Builder. Future commit will
remove this to return a Result in case of failure. Worth noting that we
don't expect one.

Signed-off-by: David Goulet &lt;dgoulet@torproject.org&gt;
</content>
</entry>
<entry>
<title>circmgr: Modify CircParameters for congestion control</title>
<updated>2025-01-16T14:16:01Z</updated>
<author>
<name>David Goulet</name>
<email>dgoulet@torproject.org</email>
</author>
<published>2024-04-30T14:35:21Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=5917b347fc726a23a83cc4251082acd6962218e8'/>
<id>urn:sha1:5917b347fc726a23a83cc4251082acd6962218e8</id>
<content type='text'>
The congestion control parameters are created from the consensus
parameters (netparams) and then put into the CircParameters object that
is then passed down the tor-proto crate.

Because different parameters are selected depending on the circuit type
(onion vs exit vs sbws), a CircuitType enum is introduced for the sole
purpose of being used to select the right parameters.

Related #534

Signed-off-by: David Goulet &lt;dgoulet@torproject.org&gt;
</content>
</entry>
<entry>
<title>Bump versions of internal arti crates for Arti 1.3.2</title>
<updated>2025-01-07T16:01:41Z</updated>
<author>
<name>Nick Mathewson</name>
<email>nickm@torproject.org</email>
</author>
<published>2025-01-07T14:46:55Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=8f4297f5e2712213910b50ced205c7b5aa0619b5'/>
<id>urn:sha1:8f4297f5e2712213910b50ced205c7b5aa0619b5</id>
<content type='text'>
The affected crates follow our regular versioning.
They all get bumped to 0.26.0.

Done with

```
for crate in $(./maint/list_crates |grep  '^arti-\|tor-' ); do
    cargo set-version --bump minor -p $crate;
done
```
</content>
</entry>
<entry>
<title>clippy: deny `mod_module_files`</title>
<updated>2025-01-06T23:09:41Z</updated>
<author>
<name>Steven Engler</name>
<email>opara@torproject.org</email>
</author>
<published>2025-01-06T23:02:49Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=252a3a803b2db65792db5bd51dee8950d8557e0d'/>
<id>urn:sha1:252a3a803b2db65792db5bd51dee8950d8557e0d</id>
<content type='text'>
Denies 'mod.rs' files for consistency.

https://rust-lang.github.io/rust-clippy/master/index.html#mod_module_files
</content>
</entry>
<entry>
<title>Upgrade to itertools 0.14.0</title>
<updated>2025-01-06T13:10:39Z</updated>
<author>
<name>Nick Mathewson</name>
<email>nickm@torproject.org</email>
</author>
<published>2025-01-06T13:10:39Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=a7f3cacea1eb5657ee1fee6d49594b1a58841519'/>
<id>urn:sha1:a7f3cacea1eb5657ee1fee6d49594b1a58841519</id>
<content type='text'>
</content>
</entry>
<entry>
<title>add_warnings, *: Allow clippy::needless_lifetimes</title>
<updated>2024-12-03T14:27:26Z</updated>
<author>
<name>Nick Mathewson</name>
<email>nickm@torproject.org</email>
</author>
<published>2024-12-03T14:15:50Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=64cc3f2ed3eea0b7c5cc89ae07cbdadfdc1646fb'/>
<id>urn:sha1:64cc3f2ed3eea0b7c5cc89ae07cbdadfdc1646fb</id>
<content type='text'>
In 1.83, this warning triggers on many of our crates.
We're thinking of fixing them all, but for now,
we're going to disable the warning.

This is part of #1765.
</content>
</entry>
</feed>
