Page MenuHomePhabricator

[keyserver] Handle invalid CSAT in Tunnelbroker socket
ClosedPublic

Authored by bartek on Nov 24 2024, 11:36 PM.
Tags
None
Referenced Files
F3540912: D14030.id46147.diff
Thu, Dec 26, 5:51 AM
F3540911: D14030.id46065.diff
Thu, Dec 26, 5:51 AM
F3540910: D14030.id45984.diff
Thu, Dec 26, 5:51 AM
F3540908: D14030.id46017.diff
Thu, Dec 26, 5:51 AM
F3540746: D14030.diff
Thu, Dec 26, 5:45 AM
Unknown Object (File)
Tue, Dec 24, 6:50 PM
Unknown Object (File)
Mon, Dec 23, 10:33 PM
Unknown Object (File)
Sat, Dec 21, 11:09 AM
Subscribers

Details

Summary

Similiar to D13956 but for keyserver

Depends on D13956

Test Plan

Mocked connection inintialization message to have invalid token. Upon receiving response, the metadata table was cleared. Closing connection caused a retry, on which login was performed and new metadata was created.

Diff Detail

Repository
rCOMM Comm
Lint
No Lint Coverage
Unit
No Test Coverage

Event Timeline

bartek held this revision as a draft.
bartek published this revision for review.Nov 25 2024, 2:08 AM
This revision is now accepted and ready to land.Nov 25 2024, 4:48 AM
keyserver/src/socket/tunnelbroker.js
119 ↗(On Diff #46017)

Confused a bit why this was moved out of createNewTunnelbrokerSocket.

We end up calling fetchIdentityInfo even if !encryptionKey. Is this intentional? If we move this call back into createNewTunnelbrokerSocket, then we could skip it in that case.

keyserver/src/socket/tunnelbroker.js
119 ↗(On Diff #46017)

Intentional. Both ways would work, I just assumed my way was cleaner. But your suggestion makes sense as well, so I'll move it back.

Rebase. Move fetchIdentityInfo back inside inner function