mirrors/arti.git/crates/arti/src/socks.rs, branch arti-v1.2.8mirror of https://gitlab.torproject.org/tpo/core/arti
http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.2.82024-09-24T20:55:25Zsocks users: copy the correct amount in our drain logic.2024-09-24T20:55:25ZNick Mathewsonnickm@torproject.org2024-09-24T20:55:25Zurn:sha1:dceeb82f7d1154894ab9c7c607d68f8335bb9615
When calling copy_within, we want to copy the amount of data that
we're keeping; previously, we were copying an extra `action.drain`
bytes, which could have led to a panic.
Spotted by Opara.
socks users: detect closed sockets.2024-09-24T20:35:07ZNick Mathewsonnickm@torproject.org2024-09-24T18:16:42Zurn:sha1:0c595818f713916d94b7b0e4062f953fad7c9799
Without this check, our socks code can enter an infinite loop
if a socket is closed at the wrong time.
Resolves TROVE-2024-011.
Fixes #1635.
Merge branch 'impl-prop-351' into 'main'2024-09-24T19:37:55ZNick Mathewsonnickm@torproject.org2024-09-24T19:37:55Zurn:sha1:f6121908ab223d5a7e539701e312285cb9b13de8
socks: Implement proposal 351.
See merge request tpo/core/arti!2401socks: Add a comment about interpreting legacy usernames.2024-09-24T18:30:34ZNick Mathewsonnickm@torproject.org2024-09-24T18:30:34Zurn:sha1:07a82fb3ebe0ce89ee6b875ee9e8fc2869556458Merge branch 'pessimistic' into 'main'2024-09-24T18:04:18ZNick Mathewsonnickm@torproject.org2024-09-24T18:04:18Zurn:sha1:53ecd607d208119b930465e58ab52f25860bb485
arti SOCKS proxy: Tear down connections when client sends optimistic data
See merge request tpo/core/arti!2443arti SOCKS proxy: Tear down connections when client sends optimistic data2024-09-24T17:12:16ZIan Jacksonijackson@chiark.greenend.org.uk2024-09-24T17:07:22Zurn:sha1:87e0109832559dec41a485b268579d58be0de278
We *do* want to support optimistic data, see
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2436#note_3081886
However, right now, Arti risks mis-framing bugs if clients do send
optimistic data, which would be quite serious.
Mitigates #1627 / TROVE-2024-010 by replacing the misframing bug with
connection failure.
It doesn't seem so easy to write a test case for this.
rtcompat: Rename TcpProvider to NetStreamProvider.2024-09-24T13:10:11ZNick Mathewsonnickm@torproject.org2024-09-19T11:55:22Zurn:sha1:8c2d84000e4d5ba74e7b6b4e9dac3fc700f618b5
(And similarly rename TcpListener to NetStreamListener,
along with their TcpStream/TcpListener associated types.)
These types are about to become generic over addresses,
and therefore shouldn't be named after TCP.
Renaming was done mostly with Rust Analyzer,
except for some macros that needed to be hand-edited.
(I'll revise the comments in the next commit;
this one is all about renaming.)
socks: cleanups in interpret_socks_auth2024-09-18T23:24:33ZNick Mathewsonnickm@torproject.org2024-09-18T23:24:33Zurn:sha1:34033b04e6f91f49bbcba3b9708302e5da85edb9
Introduce an enum, and use explicit `format_code @` syntax.
prop351: comment Suggestions from @diziet.2024-09-18T23:14:02ZNick Mathewsonnickm@torproject.org2024-09-18T23:14:02Zurn:sha1:f5febce7b8510aae78b92531e6742904ee463740Socks: isolate streams from different extended-socks formats2024-09-18T11:56:37ZNick Mathewsonnickm@torproject.org2024-09-18T11:56:37Zurn:sha1:7217bc8058cee81542608ed40f8a6389ca2bc018
(These streams would already be isolated by accident, since streams
with an RPC object are always on a client that's isolated from the
main client. But, as discussed on torspec!280, it's best to do this
sort of thing explicitly.)