ECIES (ratchet) introduced about 4 years ago, and we are still defaulting to both ECIES and ElG in most places.
There are four cases:
- New install: $I2P/i2ptunnel.config as shipped
- New tunnel: i2ptunnel code sets default
- Existing tunnel, no enc type config: i2ptunnel code sets default
- Existing tunnel, config changed and saved via UI in last 4 years: Setting as in config file
Changes:
- New install: Change eepsite and IRC client to ECIES-only; shared clients remains both
- New tunnel: Change from both to ECIES-only
- Existing tunnel, no enc type config: Change servers to ECIES-only; clients remain both
- Existing tunnel with enc type config: No defaults, no change
- Add support for Tor RESOLVE extension by caching and returning fake IP
- Handle user/pw when not required to support Tor stream isolation
(not really isolating, just handling the authentication)
- Fix user/pw authentication
- Handle outproxy config changes after start
- Support CONNECT outproxies
- Add config UI for outproxy type
- Enable IPv6 (untested)
- Support outproxy config with :port (untested)
- Various cleanups
Further testing required
- Add fromPort and toPort to Sink interface (breaking API change)
- Change cache maps from Destination to I2PSocketAddress to include port
- Accept host:port for destination in Streamr Client, use port
as toPort in pinger
- Change to muxed listener in I2PSource, only listen for
specified protocols
- Eliminate thread and queue in I2PSource, process messages inline
in the listener
- Add support for handling both repliable and raw datagrams in
a single I2PSource instance
- Remove verify option from I2PSource and I2PTunnelUDPServerBase,
always verify repliable datagrams
- Add getPort() method to UDPSource
- Add a constructor to UDPSink to pass in an existing DatagramSocket
- Change I2PTunnelUDPClientBase to receive both repliable and raw
- Change SOCKSUDPTunnel reply handling strategy to key on I2CP toPort;
remove ReplyTracker; the tunnel would not have worked before, because
it expected raw replies only but MultiSink required a destination
to look up where to forward the reply.
- Mark SOCKSUDPTunnel as preliminary; note lack of support
for raw replies; untested
- Change Streamr Client Pinger to support fromPort
- Change Streamr Server to remember fromPort in subscriptions
and use it as toPort in data stream
- Move fields to top of classes for sanity
- Cleanups and log tweaks
