#31823: HSv3 descriptor support in stem [encoding] -------------------------------------------------+------------------------- Reporter: asn | Owner: atagar Type: defect | Status: | needs_revision Priority: Medium | Milestone: Tor: | unspecified Component: Core Tor/Stem | Version: Severity: Normal | Resolution: Keywords: tor-hs scaling onionbalance | Actual Points: 2 network-team-roadmap-september tor-spec | Parent ID: #26768 | Points: 5 Reviewer: | Sponsor: -------------------------------------------------+------------------------- Changes (by asn):
* status: needs_information => needs_revision Comment: Thanks for the fixes atagar! They seem to work just fine, so I resolved all previous comments on the GH PR and added three new ones. Good news! I'm testing a stem created descriptor with little-t-tor and parsing seems to work just fine! :) >> One of the goals of my old _get_middle_descriptor_layer_body() function here was to make the output of stem indistinguishable from the output of Tor. > Sorry, I'm not quite understanding this. The _descriptor_content() arguments are simply default values for mandatory fields - if a caller would care to provide their own desc-auth-ephemeral-key (rather than use a default value) they simply need to provide it... Hm. I understand that _descriptor_content() arguments are default values, but what defines a good default value here? In particular, the `desc-auth- ephemeral-key` and `auth-client` fields of the outerlayer are usually fake data in little-t-tor which are easy to generate (see my old `_get_middle_descriptor_layer_body()`). It's true that a caller can provide their own fake data, but why not make the default value more sensible (so that it matches with the one from little-t-tor)? The benefit here will be that stem descriptors will be closer to identical with little-t-tor's, so that a client cannot tell if a descriptor was made by stem or little-t-tor (without the individual applications having to explicitly do this themselves). In any case and regardless of the above, we do need to provide a single fake `auth-client` line otherwise the descriptor won't get parsed by Tor (it's a `T1N()` element in `hs_descriptor.c`). I left a comment in the PR about this. ---- Back to you now! Over the next few days I will be testing this deeper through onionbalance (and as key blinding becomes usable again)! -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/31823#comment:13> Tor Bug Tracker & Wiki <https://trac.torproject.org/> The Tor Project: anonymity online
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs