[tor-bugs] #22781 [Core Tor/Tor]: hs: Unify link specifier API/ABI

[Tor Bug Tracker & Wiki]

#22781: hs: Unify link specifier API/ABI
---------------------------------------+-----------------------------------
 Reporter:  dgoulet                    |          Owner:  dgoulet
     Type:  enhancement                |         Status:  needs_revision
 Priority:  Medium                     |      Milestone:  Tor:
                                       |  0.3.3.x-final
Component:  Core Tor/Tor               |        Version:
 Severity:  Normal                     |     Resolution:
 Keywords:  tor-cell, tor-relay, ipv6  |  Actual Points:
Parent ID:  #24403                     |         Points:  1
 Reviewer:  teor                       |        Sponsor:  SponsorV-can
---------------------------------------+-----------------------------------

Comment (by teor):

 Replying to [comment:9 dgoulet]:
 > Replying to [comment:7 teor]:
 > > The Prop224 spec says that we should pass on all link specifiers, even
 unknown link specifier types.
 > > So I think we need a final member `extra_spec_list` that's a smartlist
 pointer.
 > > On the fast path, it doesn't get used, because it's NULL.
 > >
 > > This could handle extra addresses, too, if we ever did that.
 >
 > Hmmm well the generic object I'm talking about is the one we decode to
 and encode from `link_specifier_t` which means that if you don't recognize
 one, you ignore. Thus the object doesn't really need to keep "extra
 unknown specifier(s)" because you can really decode and encode what you
 don't know.

 As long as you know the length, you can transmit unknown link specifier
 types without parsing them.

 > This is more a matter of ignoring unknown link spec type.

 Hang on, that's not what the spec says:

    The hidden service SHOULD NOT reject any LSTYPE fields which it
    doesn't recognize; instead, it should use them verbatim in its EXTEND
    request to the rendezvous point.

 https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-
 ng.txt#n1689

 But the spec is inconsistent: it specifies this for service to rend, but
 not client to intro.
 I think we should do it for both, because it means that we automatically
 upgrade when a new link specifier comes along.

 Also, we should add something about how to deal with link specifiers that
 are too long:

     Any link specifier that would make the total length exceed the length
 of an EXTEND cell MUST be ignored. (This is important for HS descriptor to
 intro EXTEND, because the descriptor link specifiers aren't limited to the
 size of a cell.)

 Or, we can just ignore unknown link specifiers, but that introduces a
 version distinguisher, and makes upgrades slower.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/22781#comment:11>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online