Skip to content

ALPNs and NodeIDs should be infallible #3123

@flub

Description

@flub

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:

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

No one assigned

    Labels

    Type

    No type

    Projects

    Status

    No status

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions