We just discovered that we dont enforce protover rules when prop224 clients pick rendezvous points, so we end up picking rps on 0.2.8 which make our circuits hang.
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items
0
Show closed items
No child items are currently assigned. Use child items to break down this issue into smaller parts.
Linked items
0
Link issues together to show that they're related.
Learn more.
You might also find it useful to put a warn message in, if you're about to send a v3 rend request to a relay that doesn't support a v3 rend request. In case there are other edge cases (or new ones show up in the future).
Also, this seems to violate proposal 224 section 4.3, which says that we can use older rendezvous points. Why did we decide not to do that?
That is a spec issue that needs to be updated. Back at the Montreal hidden service meeting, we realized that we needed legacy rendezvous point to relay an HS cell that had more bytes than the 20 bytes rendezvous cookie and that patch got in 0.2.9 (commit be0e1e9e2f6). So, HS client can not use RPs below that version which is HSRend=2.
HOWEVER, we should most certainly pad all RENDEZVOUS cells in the legacy HS system so v2 and v3 cells look "alike".
OK I tested this branch again to make sure that nothing broke in the meanwhile.
Branch seems to work well.
To test, I used a client with this branch, connected to an hsv3 service and made sure that the rendezvous point used supported the hsv3 protocol and data made it to the service. I did this test about 20 times to make sure that we only pick legit RPs.
I'm always afraid whenever there's a chance that what we're testing has diverged from what we're running--so, thanks for double-checking that we actually have been testing this code.
Squashed and merging to 0.3.2.
Trac: Resolution: N/Ato fixed Status: merge_ready to closed