mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v0.0.3 2021-12-28T20:15:40Z 2021-12-28T20:15:40Z Daniel Eades danieleades@hotmail.com 2021-12-28T20:15:40Z urn:sha1:592642a9e6c1c03e525f8b452f4b97e6fd17ff9b 2021-12-07T17:00:40Z eta tor@eta.st 2021-12-02T11:44:29Z urn:sha1:b14c5f370eef0a4fc1d2504ce54de1a921472567 `tor-rtcompat`'s `TlsConnector` trait previously included a method to create a TLS-over-TCP connection, which implied creating a TCP stream inside that method. This commit changes that, and makes the function wrap a TCP stream, as returned from the runtime's `TcpProvider` trait implementation, instead. This means you can actually override `TcpProvider` and have it apply to *all* connections Arti makes, which is useful for issues like arti#235 and other cases where you want to have a custom TCP stream implementation. This required updating the mock TCP/TLS types in `tor-rtmock` slightly; due to the change in API, we now store whether a `LocalStream` should actually be a TLS stream inside the stream itself, and check this property on reads/writes in order to detect misuse. The fake TLS wrapper checks this property and removes it in order to "wrap" the stream, making reads and writes work again. 2021-12-06T20:11:03Z Nick Mathewson nickm@torproject.org 2021-12-06T20:01:29Z urn:sha1:31b385c5b20205e879a847a9331c30a37dc2e6f5 We want to only use TODO in the codebase for non-blockers, and open tickets for anything that is a bigger blocker than a TODO. These XXXXs seem like definite non-blockers to me. Part of arti#231. 2021-11-25T13:20:37Z Daniel Eades danieleades@hotmail.com 2021-11-25T13:14:05Z urn:sha1:db16d13df4779ac61005050dfe5ce05e3d5a1b5d 2021-11-18T08:07:48Z Trinity Pointard trinity.pointard@gmail.com 2021-11-18T08:07:48Z urn:sha1:03f8966f0d3a0ac4f73cfabd41d2e317a33a85b6 2021-10-29T12:39:04Z Nick Mathewson nickm@torproject.org 2021-10-29T12:39:04Z urn:sha1:1ee24ce6537373448d8fd5fb074768c6887cb90b Instead of putting a fully qualified name in the text, in most cases we should just use the short name of the type or function we're referring to. In other words, instead of saying [`crate::module::Foo`], we should typically say [`Foo`](crate::module::Foo). 2021-10-26T17:06:10Z Nick Mathewson nickm@torproject.org 2021-10-26T17:06:10Z urn:sha1:9a10d4ae5031db776a6b3f6cd0853317994796fe 2021-10-26T15:33:23Z eta tor@eta.st 2021-10-25T13:19:07Z urn:sha1:e8419abd2579960d59cfe418adc15cdccd20b154 Instead of racily advancing time forward, this commit attempts to rework how WaitFor works, such that it makes advances when all sleeper futures that have been created have been polled (by handing the MockSleepRuntime a Waker with which to wake up the WaitFor). The above described mechanics work well enough for the double timeout test, but fail in the presence of code that spawns asynchronous / background tasks that must make progress before time is advanced for the test to work properly. In order to deal with these cases, a set of APIs are introduced in order to block time from being advanced until some code has run, and a carveout added in order to permit small advances in time where required. (In some cases, code needed to be hacked up a bit in order to be made properly testable using these APIs; the `MockablePlan` trait included in here is somewhat unfortunate.) This should fix arti#149. 2021-10-09T20:53:13Z Nick Mathewson nickm@torproject.org 2021-10-09T20:49:32Z urn:sha1:af7c9d5a0b1bdcfba820160cf89d480efd27760e 2021-09-08T18:20:47Z Nick Mathewson nickm@torproject.org 2021-09-08T18:20:47Z urn:sha1:ab0c80de2ba210f189207c535db6454ef6d179c6 I'm alright with allowing cognitive-complexity violations in the tests.