mirrors/arti.git/crates/arti/src/socks.rs, branch tor-circmgr-v0.18.1 mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=tor-circmgr-v0.18.1 2023-10-25T14:03:08Z handle_socks_conn: update parameter name in doc comment 2023-10-25T14:03:08Z Jim Newsome jnewsome@torproject.org 2023-10-19T21:08:31Z urn:sha1:9480119ef6248181c4087ca1fb2ac7d8e39cb46a Treat only EAFNOSUPPORT as a warning 2023-09-26T08:16:39Z Jani Monoses jani.monoses@gmail.com 2023-09-26T08:16:39Z urn:sha1:97ab5ae9b544131c2b607d1d9175b3a458556e6d Handle address already in use 2023-09-22T16:26:45Z Jani Monoses jani.monoses@gmail.com 2023-09-22T16:26:45Z urn:sha1:03c5a13ad4ed9e7820c7a4a26db6368fef3129e2 arti, tor-config: Allow listening on generic addresses for SOCKS and DNS. 2023-09-22T16:19:40Z Jani Monoses jani.monoses@gmail.com 2023-09-20T07:33:04Z urn:sha1:d7f5a2b024226c8dbff5b2a01ad1a6c8615ee33a Throughout: Use *_report!() macros for reporting Errors. 2023-07-07T17:00:21Z Nick Mathewson nickm@torproject.org 2023-07-07T13:54:27Z urn:sha1:25c6fe61e4cf230210dffdac2d3c281fcb31c5a9 I identified the cases to replace by searching for the string `.report()`. There are a few that I didn't change: * A couple of cases that used anyhow::Error, * One case that reported two Errors. * Two cases in `tor_hsclient::err` that just did `error!("Bug: {}")`. I have also not audited the cases in `tor-hsclient` where we're using `tor_error::Report` manually. Nonetheless, closes #949. Remove onion service descriptor-related errorkinds. 2023-06-22T17:11:06Z Nick Mathewson nickm@torproject.org 2023-06-22T17:11:06Z urn:sha1:33bfa7c7a86035342b09920cbf4c85e83889bb46 These have been subsumed by other errorkinds, mostly OnionServiceProtocolViolation and TorProtocolViolation. In particular please review the change in tor-hsclient closely; I am not sure about the new errorkinds for the error there. arti: Resolve TODO HS items related to extended SOCKS5 errors 2023-06-22T15:05:57Z Nick Mathewson nickm@torproject.org 2023-06-22T15:05:57Z urn:sha1:57b1e36667023d86cad36ddc846256abad602a9b This takes an approach discussed in #736: Instead of trying to distinguish INTRO/REND failures perfectly, we instead map our existing ErrorKinds as best we can, in respect to the fact that this distinction is not super important in practice. Closes #736 New ErrorKind for invalid onion addresses 2023-06-22T14:57:08Z Nick Mathewson nickm@torproject.org 2023-06-22T14:51:52Z urn:sha1:967cae6cede19e7911ea2bed5f8e6f571c72d0b2 Use this to emit HS_BAD_ADDRESS as appropriate. Remove ErrorKind::OnionService{Intro,Rend}Failed 2023-06-22T14:56:23Z Nick Mathewson nickm@torproject.org 2023-06-22T14:37:26Z urn:sha1:1a9e5b8463b3c0a10e558d67201499fea09d492b These errors are orthogonal to our actual error kinds. See discussion on #736. Generate correct ErrorKinds for hsdesc decryption failures. 2023-06-21T14:22:42Z Nick Mathewson nickm@torproject.org 2023-06-21T14:17:43Z urn:sha1:dd944bc7874f6adc39814ac32e67ba7ccbd15394 Part of #736