First of all I did not want to reply to this since we had a lengthy discussion on IRC.
> Lets take a few steps back try to see a broader picture. > > * --ncp-ciphers was introduced in OpenVPN 2.4 as a brand new option. > > * Steffan has suggested to add --data-ciphers alias into the next v2.4 > release; to which I agree(!). Yes, this sounds like a simple idea but also has the danger of creating more confusion. I feel it better to have ncp-cipher and data-ciphers coexist. Then you also have the understand that ncp-cipher is an older/less capable version of data-ciphers. OpenVPN 2.4 has a number of oddities in NCP support: - the client always announces AES-GCM support even if disabled in ncp-ciphers - the server will always push the first cipher of its ncp-ciphers list to the client. From a user perspective data-ciphers is a true superset of ncp-ciphers. All existing ncp-ciphers setup will continue to work on 2.5 but the data-ciphers option from 2.5 is likely to break on 2.5 if you don't take into account the 2.4 oddities. > * I propose we add a warning whenever --ncp-ciphers used, recommending the > user to switch to --data-ciphers as soon as possible. As compromise maybe something like NOTE: Rewriting old-option x y z to new new-option x y z > > * We keep both --ncp-ciphers *and* --data-ciphers in v2.5 and v2.6. > > * When v2.5 is released v2.4 goes into "old stable support" - where both > alternatives will work. v2.4 is guaranteed to be supported by the community > for at least 6 months with full support [0] after v2.5 is released. > > * When 2.6 is released, v2.4 goes into "git tree only" support but will have a > > 12 month "old stable support" guarantee [0]. > > * 12 months *after* the v2.6 release is out, we can remove --ncp-ciphers. But > since we will not do option changes mid-release easily, it might be natural > to remove this in OpenVPN 2.7 at earliest. > > This means --ncp-ciphers will be supported in 2.4 for the life time of that > release. And v2.4 is supported for *at least* 18 months after v2.5 is > released. It also guarantees --ncp-ciphers will first be removed when we > release OpenVPN 2.7. > > What would be a problem with such a schedule? Because I don't understand the > real objection you have to remove options which ends up duplicating other > options. My general problem is that I don't see a real advantage in removing ncp-cipher but see a lot of downsides removing it. > > At the same time ... it is also important for me that we try to see this at > from an even bigger perspective than just --ncp-ciphers/--data-ciphers or even > --udp-mtu alone. Now I'm shifting the discussion to a more generic product > life cycle perspective. > > If we skimp through this and just allow whatever option duplications we head > into, just because we're too concerned about various breakages with old > configurations or setups - it will not be the last time we might end up in > such discussions UNLESS we can find a proper and reasonable process for > deprecation (which we in fact already defined for feature deprecation 10 years > ago! [1]). > > If we cannot remove options during the whole life time of OpenVPN, we cannot > touch compression options or possibly even deprecate any compression at all - > because we need to support both compression and decompression for the whole > lifetime of OpenVPN. This also extends into how to ensure proper OpenVPN 3 > compatibility as well. The amount of time we spend on testing/developing etc on compression and the complexity it introduces is vastly different from ncp-cipher > And if we cannot remove any options during the eternal life time of OpenVPN, I > will see no other alternative to being even more critical and rejective to add > new options. We already have pretty close to 300 options in OpenVPN. That is > an insane amount - where a typical common OpenVPN setup might need up to 20 of > these options, the rest are for all kinds of special cases. And we have > several competing solutions which are far simpler in many aspects which new > users might just as well prefer. > > Even though I highlight the number of options we have, I do NOT say that we > should swipe them all out and reduce the amount to 50 or so; for some users > they have a _real_ value and provides really useful features. But I want us > to save the options which do have a REAL value, not because unsupported > OpenVPN versions might break or "10 bytes extra source code" is too heavy to > carry around for an alias option. I'm arguing for keeping options covering > _REAL_ USE CASE for users. And no, breaking unsupported OpenVPN releases is > NOT a real use case from my point of view. This is the point where we disagree. I still think that we should weigh the pros and cons if we still want have compatibility. And also to consider if there are alternatives/workaround for the setups/users affected. > But back to the deprecated options ... If we cannot remove options, we also > need to consider bringing back the --tls-remote option, and --compat-names - > both with the capability to break client configs (in fact, it already did for > several Fedora EPEL users [2]). Well if weighing the pros of bringing it back outwights the cons, then the decision to compeletly remove it might have been wrong. > The proposal to remove --remote-nopull needs > to be reconsidered, as well as --secret, --max-routes, and possibly even > --ncp-disable. Maybe even more of these deprecated options needs to be > reconsidered [3]. For ncp-disable I did the weighing of pros and cons and answer that question. ncp-disable add complexity to the code paths and is in conflict which the direction we want to go. And for users that currently use the option the workable workaround is to just remove that options as it should not be necessary in 2.5 anymore. > We really need a proper and sane processes to allow the development of OpenVPN > to have a chance to move on and leave things behind when appropriate, to be > able to evolve and grow with the future - without being strangled by what > existed in the far past (meaning: no longer community supported releases). > Otherwise I do fear for the future of OpenVPN 2.x. There is more a to software than the development. There is also how it is used/etc. And we should not make it harder than it needs to be. And even for our own company internal use case of Access server the reality is that we even though we do not like supporting the old clients (back to 2.2 in some cases), we still have to do it because there is demand for it. > By having a clear strategy and adhering to a process of feature/option > management in OpenVPN, we give clearly defined time-window for stability and > functionality for our users. This predictability is, in my experience, much > more important to users than if a specifically named option is supported or > not. Yes. If we decide to remove an option we should have this predictable removal process. But if we remove an option/drop support for something something that should still be a weighing of pros and cons. For this specific option of ncp-ciphers/data-ciphers. This not just a fringe option. This is an option that affects one of the core things of OpenVPN, the chosen chipher. I want to make the transition to NCP as painless as possible and keeping ncp-cipher as alias to data-cipher is just the better choice in my opinion. Arne
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
