3 ms·
How will we go to newer Wireguard versions then? Throw it all away and use a wholly new product? Or have a Wireguard 2.0, where all participants need to upgrade
by diarrhea 3y ago
How will we go to newer Wireguard versions then? Throw it all away and use a wholly new product? Or have a Wireguard 2.0, where all participants need to upgrade in lockstep, with no backwards compatibility (actually sounds attractive: some churn from time to time, but none of the avoidable headaches)?
- segfaultbuserr 3y ago> Or have a Wireguard 2.0, where all participants need to upgrade in lockstep, with no backwards compatibility (actually sounds attractive: some churn from time to time, but none of the avoidable headaches)? I think it's basically the plan. Even with protocol negotiation, replacing an existing crypto algorithm would be a breaking change anyway. Furthermore, it should be possible to preserve backward compatibility using a reserved field without a heavy-weight, full-fledged protocol negotiation. Entering a different code path if the message is tagged "version 2" should be enough.