On 24/07/2020 12:45, Arne Schwabe wrote: > 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.
These oddities, they sounds like bugs, or? If I try to put on my Never-used-NCP-before-hat, this would not be what I would expect. Why haven't we resolved this within the current 2.4 scope without changing options? > 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 As mentioned on IRC, yes. I am willing to accept msg(M_INFO, "Rewriting deprecated option X to the replacement Y" ... [...] >> * 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. I hear about you seeing downsides ... but I have not seen any argument here convincing me otherwise. This overall process should take care of supporting all reasonable OpenVPN 2.x versions. >> 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 That is true. But at the same time, if we do not have a proper deprecation process where we draw the line in which OpenVPN versions we are willing to support (from a functional perspective), we cannot touch compression. Which is why I'm trying to raise the points of a bigger picture. We need to find a reasonable solution to which OpenVPN versions we are willing to support, and when those versions enters the unsupported side we should be free to cleanup code and options related to the behavior and functionality only these now not supported releases provided. >> 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. This is again the same issue, to be able to draw the line somewhere to what we are willing to support. What kind of life cycles do we want for OpenVPN? >> 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. So the question is ... do we care about broken OpenVPN 2.3 (or older) configurations today? Which is technically supported by us another 12 months after the v2.5 release. >> 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. But it still will break users configs without any prior warning in 2.4. It was added to our git master only in 15 days ago. Including potential client configurations. Again, this exemplifies that we are lacking a proper product life cycle process and even adhering to a feature deprecation process. >> 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. Why Access Server supports such old OpenVPN releases is a completely different discussion not belong here in the community. There might be valid use cases for these customers, but in such situations additional (and often fairly expensive) support contracts are required by the vast majority of vendor agreements I've seen. And these corporate special needs should not end up in the community. The community needs to be decoupled to be fully functional. I say this as a OpenVPN Inc hire - and has also said this internally to the management over the years I've been there. From what I experience, there is a general understanding for the need of this separation. >> 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. I agree that --data-cipher is a better name for it; I have not rejected that. But that doesn't mean we should have two thoughts active at the same time: a) NCP improvements, and b) product life cycle, what we support and how we support OpenVPN in the long run ... in this case they do impact each other. But when we only focus on a) without properly considering b), that is the point where I object. -- kind regards, David Sommerseth OpenVPN Inc
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
