mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.4.0 2025-02-07T10:47:05Z 2025-02-07T10:47:05Z Ian Jackson ijackson@chiark.greenend.org.uk 2025-02-06T18:24:38Z urn:sha1:d69fe98f10d469028e1cbbd3dff4eabd3ba3d816 Fixes #1841. 2025-02-06T18:17:34Z Ian Jackson ijackson@chiark.greenend.org.uk 2025-02-06T18:13:25Z urn:sha1:e590ba4d522b44ffc7adc0eea463309df2de12f3 See Release.md. maint/list_crates | grep -P '^tor-|^arti-' | xargs -n1 nailing-cargo -Eu set-version --bump minor -p This completes the version bumps. The report of changed crates, before I started the release work, is: $ maint/changed_crates -v "arti-v$LAST_VERSION" oneshot-fused-workaround: No change. slotmap-careful: No change. test-temp-dir: No change. fslock-guard: No change. hashx: No change. equix: No change. tor-basic-utils: No change. caret: No change. fs-mistrust safelog: No change. retry-error: No change. tor-error tor-general-addr: No change. tor-geoip: No change. tor-rtcompat tor-rtmock tor-async-utils tor-config tor-config-path tor-rpc-connect tor-log-ratelim: No change. tor-rpcbase tor-memquota: No change. tor-units tor-llcrypto: No change. tor-protover: No change. tor-bytes tor-checkable: No change. tor-cert tor-key-forge tor-hscrypto: No change. tor-socksproto: No change. tor-linkspec: No change. tor-cell: No change. tor-proto tor-netdoc: No change. tor-consdiff: No change. tor-netdir tor-relay-selection: No change. tor-persist tor-chanmgr tor-ptmgr: No change. tor-guardmgr: No change. tor-circmgr tor-dirclient: No change. tor-dirmgr: No change. tor-keymgr tor-hsclient tor-hsservice tor-hsrproxy: No change. tor-relay-crypto arti-client arti-relay arti-rpcserver arti arti-rpc-client-core $ 2025-02-06T18:17:34Z Ian Jackson ijackson@chiark.greenend.org.uk 2025-02-06T18:07:00Z urn:sha1:760400b3de12c5de121b6a7027a29ec78297c863 There are new features. cargo set-version --offline --bump minor -p fs-mistrust Actually, I have discovered by diffing that some methods now take `&self` where previously they took `self`. This will need a further bump to the fs-mistrust version and a fix to the changelog. I will do that. Filed blocker ticket #1841 for it. 2025-01-30T15:08:17Z Nick Mathewson nickm@torproject.org 2025-01-30T15:03:04Z urn:sha1:fcb10040764db7204b637713b4166c4f57235257 Our documentation had dated to an older version of our RPC stream code, where all streams were automatically optimistic. But as explained, our use of "optimistic"ness in RPC stream code is now purely internal, to make it possible to get an DataStreamCtrl. This isn't user-visible in our rpc_conn_open_stream code. Closes #1583 2025-01-15T13:49:17Z Gabriela Moldovan gabi@torproject.org 2025-01-08T11:06:59Z urn:sha1:267235969df65d975b5deb01c342e1073d4c3847 Needed for cases where we wrap an object that implements `StreamOps` in an external type, thereby losing access to the `StreamOps` functionality. For example, during the channel handshake, we `.split()` the stream that implements `StreamOps`, which leaves us with a `SplitSink` and a `SplitStream`, neither of which implement `StreamOps`. Getting a handle to the underlying object that implements `StreamOps` (for example, a file handle) *before* the stream is `.split()` enables us to use `StreamOps` to manipulate the underlying split stream. This commit also introduces a special `UnsupportedStreamOpsHandle`, which is a type that implements `StreamOps`, but always returns an error. This type is meant to simplify error handling and usage, and is meant to be used in cases where `StreamOps` is not supported. TODO: the name of this type is pretty confusing (it's very similar to `UnsupportedStreamOp`, which is an error type), and should probably be renamed to something else (`NoOpStreamOpsHandle`, `BrokenStreamOpsHandle`, `DummyStreamOpsHandle` come to mind...). Note: this changes the `StreamOps` trait to be slightly different from what I originally envisioned in !2660 and #1769 2025-01-07T16:01:41Z Nick Mathewson nickm@torproject.org 2025-01-07T14:46:55Z urn:sha1:8f4297f5e2712213910b50ced205c7b5aa0619b5 The affected crates follow our regular versioning. They all get bumped to 0.26.0. Done with ``` for crate in $(./maint/list_crates |grep '^arti-\|tor-' ); do cargo set-version --bump minor -p $crate; done ``` 2025-01-07T14:04:53Z Nick Mathewson nickm@torproject.org 2025-01-07T14:04:53Z urn:sha1:5d0bbc76dc44ff98b5f32c69168b07246e65afa7 clippy: deny `mod_module_files` See merge request tpo/core/arti!2689 2025-01-06T23:09:41Z Steven Engler opara@torproject.org 2025-01-06T23:02:49Z urn:sha1:252a3a803b2db65792db5bd51dee8950d8557e0d Denies 'mod.rs' files for consistency. https://rust-lang.github.io/rust-clippy/master/index.html#mod_module_files 2025-01-06T20:36:37Z Dimitris Apostolou dimitris.apostolou@icloud.com 2024-12-25T20:48:02Z urn:sha1:4acfc23b70c51d2637d0274943a82d1c94dec050 2024-12-10T10:34:48Z Gabriela Moldovan gabi@torproject.org 2024-12-09T11:45:54Z urn:sha1:6b9a51a08dea8b987a017c1abbf87ba6bcb54d88