-
Notifications
You must be signed in to change notification settings - Fork 302
Description
Because of our crypto setup we know we have some invariants on an accepted connection: we always have a NodeId. We (probably also) always have an ALPN. Similarly the underlying APIs of peer_identity
and handshake_data
are probably also infallible. But maybe we don't even want to provide the underlying function at all anymore.
These APIs need to be carefully checked and the implementations should be made infallible. Taking care to deal with the fact that we can not panic based on data accepted on the network since anyone can modify iroh or write a custom impl that would violate the constraints. Those should gracefully reject the connection.
Original issue text:
The Connection::remote_node_id
method currently returns a Result
. The kind of errors it throws are currently all essentially bugs in the code. I am not sure how future proof this is however:
- Maybe feat(iroh)!: switch TLS authentication to raw public keys #2937 which introduces raw public keys would change things?
- Maybe some other change will no longer mean the number of certificates will always be 1 and then having this check in old versions would at least mean they don't panic.
It is however an eyesore that this API is fallible right now. Is there a way we can safely ensure this API is actually infallible? Maybe it involves changing how the handshake data gets stored so we can directly store a NodeId? This would also involve making the peer_identity
no longer optional.
Metadata
Metadata
Assignees
Type
Projects
Status