[tor-bugs] #10614 [Tor]: pt-spec.txt describes using `keyid=fingerprint` in torrc `Bridge` lines

[Tor Bug Tracker & Wiki]

#10614: pt-spec.txt describes using `keyid=fingerprint` in torrc `Bridge` lines
------------------------+----------------------------------
     Reporter:  isis    |      Owner:  isis
         Type:  defect  |     Status:  closed
     Priority:  minor   |  Milestone:
    Component:  Tor     |    Version:
   Resolution:  fixed   |   Keywords:  easy,tor-spec,tor-pt
Actual Points:          |  Parent ID:
       Points:          |
------------------------+----------------------------------

Comment (by isis):

 Replying to [comment:4 asn]:
 > Replying to [comment:3 nickm]:
 > > Since this is an 0.2.5 change, we might as well just add the missing
 syntax and document that it was missing before the proper version, right?
 > >
 > > There's a patch to add the missing feature as bug10614 in my public
 repository. How does that look?
 >
 > First we should figure out whether we actually want this `keyid`
 syntactic sugar. As far as I can see, it's not needed for parsing the
 line, and it also complicates the format (`keyid=` is a `k=v` value but
 with different semantics than the `k=v` values that follow it). Do you
 know what was the original purpose of it?


 My understanding is that, because BridgeDB can be configured to give or
 not give to clients bridges' fingerprints, it is not known if a
 fingerprint (or `keyid=` field) will be in the resulting `Bridge` line.
 For example, without having `keyid=` thrown in there, the following are
 all "valid" lines which BridgeDB might hand out:
 {{{
 Bridge 1.2.3.4:443
 Bridge 1.2.3.4:443 abcdef0123456789abcdef0123456789abcdef01
 Bridge obfs3 1.2.3.4:443
 Bridge obfs3 1.2.3.4:443 ubersekrit=totoro
 Bridge obfs3 1.2.3.4:443 abcdef0123456789abcdef0123456789abcdef01
 Bridge obfs3 1.2.3.4:443 abcdef0123456789abcdef0123456789abcdef01
 ubersekrit=totoro
 1.2.3.4:443
 1.2.3.4:443 abcdef0123456789abcdef0123456789abcdef01
 obfs3 1.2.3.4:443
 obfs3 1.2.3.4:443 ubersekrit=totoro
 obfs3 1.2.3.4:443 abcdef0123456789abcdef0123456789abcdef01
 obfs3 1.2.3.4:443 abcdef0123456789abcdef0123456789abcdef01
 ubersekrit=totoro
 }}}

 Hence it could get a little bit messy parsing for the fingerprint, because
 you wouldn't really know if there was a fingerprint until you'd already
 parsed the text before and after it. Keeping `keyid=` doesn't matter to
 me, but if it makes things easier for TorLauncher or little-t tor, then we
 should probably use Nick's patch.

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