<feed xmlns='http://www.w3.org/2005/Atom'>
<title>mirrors/arti.git/crates/tor-cell/semver.md, branch arti-v1.5.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.5.0</id>
<link rel='self' href='http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.5.0'/>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/'/>
<updated>2025-08-21T15:59:37Z</updated>
<entry>
<title>proto: Remove the AUTHORIZE as a parsable cell</title>
<updated>2025-08-21T15:59:37Z</updated>
<author>
<name>David Goulet</name>
<email>dgoulet@torproject.org</email>
</author>
<published>2025-08-21T14:52:35Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=eabd0c0bfe703337e338403949721ce57c87f32e'/>
<id>urn:sha1:eabd0c0bfe703337e338403949721ce57c87f32e</id>
<content type='text'>
The AUTHORIZE cell command is simply reserved but not defined. The tor
specification, at this point in time, is allowing such cell before the
handshake starts but it is very unclear on what ordering is allowed nor
how many can are allowed.

C-tor silents drop them like VPADDING and so clearly unused. Instead of
dealing with it, simply remove its support but keeping its reserved
number.

Signed-off-by: David Goulet &lt;dgoulet@torproject.org&gt;
</content>
</entry>
<entry>
<title>tor-hsservice: Change capping of PoW effort.</title>
<updated>2025-08-13T18:43:05Z</updated>
<author>
<name>Wesley Aptekar-Cassels</name>
<email>me@wesleyac.com</email>
</author>
<published>2025-08-13T18:20:11Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=8e9e5a2f6ff20360816896b971408e8bf1b5c7ea'/>
<id>urn:sha1:8e9e5a2f6ff20360816896b971408e8bf1b5c7ea</id>
<content type='text'>
This caps the PoW effort during sorting, rather than at intake.

This allows us to record efforts that are capped in our metrics
histogram while only recording metrics after the PoW solve has actually
been verified.
</content>
</entry>
<entry>
<title>Remove semver.md files, post-release.</title>
<updated>2025-08-05T18:12:52Z</updated>
<author>
<name>Ian Jackson</name>
<email>ijackson@chiark.greenend.org.uk</email>
</author>
<published>2025-08-05T18:12:52Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=ea4063c9cf01d40c15f0380607ae35b5f0d4ce5b'/>
<id>urn:sha1:ea4063c9cf01d40c15f0380607ae35b5f0d4ce5b</id>
<content type='text'>
</content>
</entry>
<entry>
<title>tor-cell: change `UnparsedRelayMsg::data_len`</title>
<updated>2025-07-15T06:04:44Z</updated>
<author>
<name>Steven Engler</name>
<email>opara@torproject.org</email>
</author>
<published>2025-07-15T03:50:51Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=d499af464198520e0b4115d624b1cf53929d0024'/>
<id>urn:sha1:d499af464198520e0b4115d624b1cf53929d0024</id>
<content type='text'>
It now performs some validation and can return a `Result`.

We perform validation here since different cell formats may have
different maximum data lengths in the future, and `UnparsedRelayMsg`
doesn't expose the cell format so it's difficult to perform this
validation at a higher layer.
</content>
</entry>
<entry>
<title>tor-cell: remove `flowctl-cc` feature and make XON/XOFF cells stable</title>
<updated>2025-07-15T05:33:18Z</updated>
<author>
<name>Steven Engler</name>
<email>opara@torproject.org</email>
</author>
<published>2025-07-15T05:27:21Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=676dbdb43f2a930b7dc89d2a6275338064fd37bf'/>
<id>urn:sha1:676dbdb43f2a930b7dc89d2a6275338064fd37bf</id>
<content type='text'>
I don't see any further changes being needed for these types, and it
simplifies a lot of future code in tor-proto that uses these types.
</content>
</entry>
<entry>
<title>release: Delete semver.md files after release.</title>
<updated>2025-06-05T13:45:22Z</updated>
<author>
<name>Alexander Hansen Færøy</name>
<email>ahf@torproject.org</email>
</author>
<published>2025-06-05T13:45:22Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=a59953da8d68cbf8ffdc8711e3fc5ec3bba77ae4'/>
<id>urn:sha1:a59953da8d68cbf8ffdc8711e3fc5ec3bba77ae4</id>
<content type='text'>
</content>
</entry>
<entry>
<title>cell,proto: Split request/response extensions into seprate types</title>
<updated>2025-05-07T12:44:59Z</updated>
<author>
<name>Nick Mathewson</name>
<email>nickm@torproject.org</email>
</author>
<published>2025-04-30T17:27:58Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=ff9c3478d2aac678e4ad27712fd65b1ce296d423'/>
<id>urn:sha1:ff9c3478d2aac678e4ad27712fd65b1ce296d423</id>
<content type='text'>
Implements part of proposal 358.
</content>
</entry>
<entry>
<title>Rename NtorV3Extension to CircRequestExt</title>
<updated>2025-05-07T12:41:39Z</updated>
<author>
<name>Nick Mathewson</name>
<email>nickm@torproject.org</email>
</author>
<published>2025-04-30T16:05:45Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=70aab0213f42b14ff8dfa02c22a2cf615709ed9c'/>
<id>urn:sha1:70aab0213f42b14ff8dfa02c22a2cf615709ed9c</id>
<content type='text'>
This type will, because of prop358, be shared by ntorv3,
hs-ntor, and probably other future handshakes.

There will also be a CircResponseExt type.
</content>
</entry>
<entry>
<title>proto, cell: Remove RelayCellFormatTrait.</title>
<updated>2025-05-06T22:34:17Z</updated>
<author>
<name>Nick Mathewson</name>
<email>nickm@torproject.org</email>
</author>
<published>2025-04-30T00:59:07Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=297aa8027f7528605fe5bf2097f3474d9ba3eef9'/>
<id>urn:sha1:297aa8027f7528605fe5bf2097f3474d9ba3eef9</id>
<content type='text'>
The purpose of the trait was to parameterize the tor1 cell crypto
on the different possible relay cell layouts.

It made sense to have this trait when we thought we would implement
the new cell layout for prop340 (packed-and-fragmented) well before
we implemented CGO.

But it now appears all but certain that CGO will land long before
we make any more headway on prop340.  Therefore,
it doesn't make sense to carry the ability to customize `tor1`
for other relay cell layouts.

Removing this trait saves a fair bit of complexity.
</content>
</entry>
<entry>
<title>proto: Use SendmeTag in place of CircTag</title>
<updated>2025-05-06T22:34:17Z</updated>
<author>
<name>Nick Mathewson</name>
<email>nickm@torproject.org</email>
</author>
<published>2025-04-29T23:20:06Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=44f4290934140cd8afdc09e03aeeadd88264b23b'/>
<id>urn:sha1:44f4290934140cd8afdc09e03aeeadd88264b23b</id>
<content type='text'>
This doesn't make much change yet, but does save us an allocation
when handling SENDMEs.
</content>
</entry>
</feed>
