Failing to set private key before peers makes socket unresponsive
stevekerrison opened this issue · comments
If boringtun
is given peer settings without the private key being set, it will panic and the socket will end session without providing a response. Subsequent requests to the socket yield no response.
To reproduce:
- Run a
boringtun
:
RUST_BACKTRACE=1 boringtun myvpn -v debug -l /dev/stdout -f
Feb 08 02:43:49.373 INFO BoringTun started successfully
- Check socket works:
socat - UNIX-CONNECT:/var/run/wireguard/myvpn.sock
get=1
listen_port=51601
errno=0
- Issue a
set
without the private key:
socat - UNIX-CONNECT:/var/run/wireguard/myvpn.sock
set=1
listen_port=12345
public_key=6040ad1d02595ad318d7b54673de74361d7cce0a1a617da5b851031243abe67a
endpoint=1.2.3.4:5678
- Observe no response from
set
, and observe error:
thread '<unnamed>' panicked at 'Private key must be set first', src/device/mod.rs:337:14
stack backtrace:
0: rust_begin_unwind
at /rustc/e1884a8e3c3e813aada8254edfa120e85bf5ffca/library/std/src/panicking.rs:495:5
1: core::panicking::panic_fmt
at /rustc/e1884a8e3c3e813aada8254edfa120e85bf5ffca/library/core/src/panicking.rs:92:14
2: core::option::expect_failed
at /rustc/e1884a8e3c3e813aada8254edfa120e85bf5ffca/library/core/src/option.rs:1260:5
3: boringtun::device::Device<T,S>::update_peer
4: boringtun::device::api::api_set_peer
5: boringtun::device::dev_lock::LockReadGuard<T>::try_writeable
6: boringtun::device::api::<impl boringtun::device::Device<T,S>>::register_api_handler::{{closure}}
7: boringtun::device::DeviceHandle<T,S>::event_loop
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
- Subsequent socket interaction yields nothing:
socat - UNIX-CONNECT:/var/run/wireguard/myvpn.sock
get=1
It seems that private_key
could have been set in a previous set
, so it's not necessary for it to be there. But, if it isn't previously set, an appropriate errno
response should come back and avoid the panic.