mirrors/arti.git/crates/tor-cell/src/relaycell/hs, branch arti-v1.1.2 mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.1.2 2023-02-16T14:00:07Z Mark a quoted block as text, so doctest ignores it. 2023-02-16T14:00:07Z Nick Mathewson nickm@torproject.org 2023-02-16T14:00:07Z urn:sha1:c4b451ffa64b6feec66a56740e62d0c98792e3f7 Add a TODO about combining several macros and patterns 2023-02-16T13:25:12Z Nick Mathewson nickm@torproject.org 2023-02-16T13:25:12Z urn:sha1:14417dc0981c6a1eec5adce826d1847794e1c533 Make a comment more accurate 2023-02-16T13:19:04Z Ian Jackson iwj@torproject.org 2023-02-16T13:19:04Z urn:sha1:b4e48b0695e8a6fbb82f5d0dd4cff5b965bc5c4f tor-cell: Use a more generic mechanism for managing extensions 2023-02-15T13:44:43Z Nick Mathewson nickm@torproject.org 2023-02-15T13:44:43Z urn:sha1:5521df0909ff7afa2d78304c9376861dfcf7041a Several HS message types have an extension list type. They all use the same framing for extensions, but each of them has separate extension types and separate extension namespaces. This commit simplifies establish_intro a little, and adds support for maintaining unrecognized extension types--at the expense of some new internal code. tor-cell: Extract establish-intro into its own module. 2023-02-15T12:46:36Z Nick Mathewson nickm@torproject.org 2023-02-15T12:46:36Z urn:sha1:37fcb0ca7cd6d68a328a24e71362cc3d789db15d Some of the HS message types have a lot of dependent types, like extensions and options for those extensions, and so on. Except when those extensions are portable across cell types, it makes sense to put them in their own modules.