mirrors/arti.git/crates/tor-hsservice/src/req.rs, branch arti-v1.1.9mirror of https://gitlab.torproject.org/tpo/core/arti
http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.1.92023-09-27T17:42:50Zhss: Remove OnionServiceDataStram type.2023-09-27T17:42:50ZNick Mathewsonnickm@torproject.org2023-09-27T13:21:40Zurn:sha1:d208c062fc2d78dc45d2b92d6eee441d5585b3db
I think that the reason we added this was in case we needed
different behavior from DataStream; but on reflection it does seem
that we don't. Having a single type here will make things a bit
simpler.
hss: Implement methodss for StreamRequest2023-09-27T17:42:50ZNick Mathewsonnickm@torproject.org2023-09-26T20:18:02Zurn:sha1:6049bfe35a810ff4bdeec11c20d117eb49363fbbtor-proto: Make allow_stream_requests() not return a Result2023-09-27T17:32:07ZNick Mathewsonnickm@torproject.org2023-09-26T18:42:00Zurn:sha1:8cdd30491201c3a8d54e482ef4904a51900ea399
The function never yields anything but an `Ok`, so we can
simplify its type.
(Not a stable feature, so no semver entry needed)
HSS: Enable RendRequests to be answered.2023-09-20T13:07:42ZNick Mathewsonnickm@torproject.org2023-09-20T13:07:42Zurn:sha1:a1fbe5375cd385914cc731d930f20730ca3a60e9
This requires yet more plumbing—this time, of HsCircPool and
NetDirProvider.
HSS: route most necessary key material to RendRequest2023-09-20T12:25:43ZNick Mathewsonnickm@torproject.org2023-09-20T12:25:43Zurn:sha1:9775136bb23faf48da5c6c64afcc725c976bbef6
When we go to answer a RendRequest, we need to have a few objects
present. This commit makes sure that they're available at the
right places.
We also note a significant problem with the need for a Subcredential
here.
tor-hsservice: Apply deferred rustfmt churn2023-09-18T11:35:46ZIan Jacksonijackson@chiark.greenend.org.uk2023-09-18T11:35:46Zurn:sha1:0e86f5781933734b9316a526877a416d8c882252tor-hsservice: Unify ids as IptLocalId replacing IntroPointId2023-09-18T10:53:51ZIan Jacksonijackson@chiark.greenend.org.uk2023-09-18T10:42:26Zurn:sha1:6a1bd5b2be447e96c33f4b3cb4d877ec085ab205
IntroPointId was RelayIds but that's wrong, because there can be
different IPTs at the same relay - but also because an established IPT
might change its RelayIds.
Use IptLocalId instead, which I think is the type we decided to use
for this, and which is, conveniently, Copy.
And change the variable names to match, everywhere.
Specifically: in places where an intro point is implied (ipt_mgr.rs,
ipt_establish.rs) use the name `lid` everywhere, like in ipt_mgr.rs.
Elsewhere, use `ipt_lid`.
(We could use a longer name, but in that case it should be changed in
ipt_mgr.rs too.)
No actual functional change in this commit.
HSS: Refactor RendRequest so we can return a stream of it.2023-08-22T14:50:43ZNick Mathewsonnickm@torproject.org2023-08-18T17:06:42Zurn:sha1:ec6721ec9412fa08a47855965c6a1e0ceb6e63fe
We need a type that holds a rend_handshake::IntroRequest object
internally, but where we don't materialize that object from the
Introduce2 message inside the MsgHandler, since that's more crypto
than we want to put in that task.
tor-hsservice errors: Distinguish operational errors by context2023-08-17T12:28:44ZIan Jacksonijackson@chiark.greenend.org.uk2023-08-17T12:04:53Zurn:sha1:360c90a9d8ec14c713560bc089f9706527056d31
At the very least, I need FatalError to be distinct:
IptEstablisher::new ought not to fail unless everything is terrible.
Add a the Spawn variant to FatalError (that we'll need soon) and the
Bug variant (which it seems likely we might need).
This also gets rid of the crate-level Result alias.
tor-hsservice errors: Use Bug for methods that oughtn't to fail2023-08-17T12:19:21ZIan Jacksonijackson@chiark.greenend.org.uk2023-08-17T12:02:34Zurn:sha1:5e047da9cc4017433b7282858a33543587a976ee
If the service encouters operational errors, surfacing them here is
not helpful. So these methods ought to work, if they weren't called
erroneously.