mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.2.8 2024-09-25T14:37:18Z 2024-09-25T14:37:18Z Nick Mathewson nickm@torproject.org 2024-09-25T14:37:18Z urn:sha1:6a12c2ba8515226a772d5f4a81930bf42d67535a The `derive_more` crate broke backward compatibility with this version, so this change involved quite a few manual fixups. With luck, they'll keep compatibility for some while in the future. 2024-09-24T13:45:21Z Wesley Aptekar-Cassels me@wesleyac.com 2024-09-16T16:35:37Z urn:sha1:e6f0b59e595f5ab5bd8d58d3c6aab8dface9a851 This will allow for testing, as the CircuitBuilder can be replaced with a mocked version. This did require moving some of what was in the CircuitBuilder impl into the AbstractCircuitBuilder type, since Drop implementations can't be specialized, but that's fine, as we'll probably be doing more of that in the future anyways. 2024-09-16T14:57:33Z Wesley Aptekar-Cassels me@wesleyac.com 2024-09-12T21:26:58Z urn:sha1:39f599a4bc966e648045b710e434718496dbf13d This tests that when requesting preemptive circuits, they are not given out when a insufficient number of circuits are in the CircList, but that they are given out once the required number of circuits has been reached. 2024-09-16T14:57:33Z Wesley Aptekar-Cassels me@wesleyac.com 2024-09-11T17:36:31Z urn:sha1:a7d7933ffe86dd0f85f58f219860cd3e576aafdf AbstractSpec and FakeSpec actually make testing more difficult, since they prevent using FakeBuilder in code that relies on the concrete TargetCircUsage and SupportedCircUsage types. Removing them means FakeBuilder can be used in more places, and also means that the test code is closer to the real code, since TargetCircUsage and SupportedCircUsage are now exercised directly in more tests. This did require making one change to a test, which I think was previously testing behaviour that was true for FakeSpec but not for the real code: The mgr::test::isolated test previously asserted that, in the case where three circuits were requested, two with isolation and one without, the non-isolated circuit would be shared with one of the isolated circuits. This was allowed by the FakeSpec::supports function. However, in the actual code, the path is as follows: * AbstractCircMgr::get_or_launch * AbstractCircMgr::prepare_action * CircList::find_open * AbstractSpec::find_supported * abstract_spec_find_supported * OpenEntry::supports * SupportedCircUsage::supports * StreamIsolation::compatible_same_type StreamIsolation::compatible_same_type checks owner_type, which is always zero for non-isolated streams and always non-zero for isolated streams, meaning that a isolated stream will never be compatible with a non-isolated stream. The seems like desirable behaviour, so I simply modified the test to make four connections, two isolated and two not, and checked that the isolated streams never share any circuits, and that the two non-isolated streams use the same circuit. As far as I can tell, this is the intended behaviour in the existing code. 2024-09-09T17:26:37Z Gabriela Moldovan gabi@torproject.org 2024-09-05T15:42:08Z urn:sha1:b2b75302ab095bccdc7ccecb627e4648a3ae9419 This allows us to set SRVs for example (needed because by default, the test `NetDir` is built from a consensus that doesn't contain any SRVs). 2024-09-03T08:09:02Z Dimitris Apostolou dimitris.apostolou@icloud.com 2024-09-03T08:09:02Z urn:sha1:676f913463b7d84f34dd6101b99d03ef79cf57ad 2024-08-28T14:27:46Z Jim Newsome jnewsome@torproject.org 2024-08-22T19:20:36Z urn:sha1:46f7f01092e6ac55e3e958dc3a2228b1d36e26a1 Having this in the `tor-async-utils` crate prevents us from doing both of the following without introducing a circular dependency: * using it in `tor-rtmock` (which we currently do, particularly in tests). * using `tor-rtmock` to test things in `tor-async-utils`. We don't do this yet, but it is generally sensible to do so. In particular we want to move the `stream_peak` module there, which is currently tested with `tor-rtmock`. Moving this into its own crate avoids this circular dependency. 2024-08-15T17:54:58Z Steven Engler smengler3@gmail.com 2024-08-15T15:35:49Z urn:sha1:4af7ab716019c85a0373fd82ee22daab3c74a0ce 2024-08-15T17:54:58Z Steven Engler smengler3@gmail.com 2024-08-15T15:32:46Z urn:sha1:e03a2b6cc1f9ee07404c6ac0cd736fc4eba86a99 2024-08-13T18:44:24Z Steven Engler smengler3@gmail.com 2024-08-13T18:10:10Z urn:sha1:e0b7f6582283e8cdb721b2df23e99257e4191eb0 The `path::exitpath::test::by_ports` test sometimes failed now that the test is using a `GuardMgr` since `select_guard`, when given a chosen exit, only ensures that the guard and chosen exit are not in the same family. It does not ensure that the guard and exit do not share an extended family. This commit relaxes an assertion in the test. ```text thread 'path::exitpath::test::by_ports' panicked at crates/tor-circmgr/src/path/exitpath.rs:295:9: assertion failed: r1.can_share_circuit(r3, subnet_config) ``` This "chosen exit" functionality isn't actually being used anywhere (`ExitPathBuilderInner::ChosenExit` is only ever constructed in tests).