On 20/07/17 09:46, Farkas Levente wrote: > On 07/20/2017 02:09 AM, David Sommerseth wrote: >> On 18/07/17 22:55, Farkas Levente wrote: >>> On 07/18/2017 10:03 PM, David Sommerseth wrote: >>>> On 18/07/17 17:50, Farkas Levente wrote: >>>>> On 07/18/2017 03:55 PM, Jaroslav Reznik wrote: >>>>>> This will result in the following: >>>>>> * OpenVPN 2.4 based clients will automatically upgrade to AES-256-GCM, >>>>>> regardless if they have --cipher in their configuration file or not. >>>>>> For OpenVPN v2.4 configurations not wanting this cipher upgrade, the >>>>>> client configuration needs to deploy --ncp-disable. >>>>>> * OpenVPN 2.3 based clients and older (and v2.4 clients using >>>>>> --ncp-disable in the client configuration) can connect to the server >>>>>> using any of the --ncp-ciphers list; this is what is called "poor >>>>>> man's cipher negotiation" by the upstream OpenVPN developers. >>>>>> * Any client not providing --cipher defaults to BF-CBC. These clients >>>>>> should still be able to connect to the server as the server allows >>>>>> BF-CBC through --ncp-ciphers. >>>>> >>>>> unfortunately it's not working:-( >>>>> it takes me long time to debug it on my own server and a long discussion >>>>> in this ticket: >>>>> https://community.openvpn.net/openvpn/ticket/886 >>>>> it's not possible to set >>>>> cipher AES-256-GCM >>>>> since in this case old clients eg android client which not updated to >>>>> 2.4.x are not able to connect. >>>> >>>> The issue I believe you refer to ("unreliable NCP") should be fixed in >>>> OpenVPN v2.4.3. >>>> <https://community.openvpn.net/openvpn/ticket/887#comment:13> >>> >>> this means only a few weeks ago... >>> imho openvpn is _very_ widely used and if it's break anything it's break >>> a lots of thing... >>> i'd rather postpone it to f28 when it's fully tested and stabilized. >> >> What is the benefit of postponing based on a bug which have been fixed? >> And have been tested? And where the test process should reasonably >> thoroughly documented and can be verified by others? >> >> Also considering that we're just in the very early planning phase of >> F-27 and F-26 have just been released. So F-27 is at least 6 months >> ahead of us. Which means the NCP feature will be at least 1 year old, >> with the last fix making this work will be 6 months - which should be >> plenty of time to test this out. Plus considering that OpenVPN is >> deployed elsewhere in much grander scales than Fedora alone where also >> NCP is getting more and more used and rolled out in similar ways as this >> proposal. So this is also being tested outside the Fedora universe as well. > > if this is so obvious and has only benefits and at the same time you > also upstream developer why the upstream openvpn not change it's > default? since it'll exactly has the same effect as it's changed in > fedora and in this case fedora don't have to do anything. You never seem to really answer any questions, you just shoot new ones. This makes it really makes it hard to take your feedback serious. Especially when you even base your claims that this won't work on false premises, completely disregards issues have been fixed upstream already and it is reasonably easy to verify my claims it works. You have not provided any feedback that there are any flaws in neither the example configurations nor the test script described in the change proposal. With this argumentation tactic, Fedora would still be arguing when to include systemd in an official release. And this OpenVPN change is a far less invasive change. And even only hitting OpenVPN server configurations. But to answer your yet new question: A far more invasive change is being discussed upstream, which will enforce this change also on non-systemd based OSes (that change will be happen in the OpenVPN executable). The experienced functionality will be most likely be pretty much the same. But as this is a very simple change for Fedora - by changing the unit file, so I didn't really see any reason to postpone it. This also helps preparing Fedora users once it hits a future upstream OpenVPN release (something I got lots complaints about when moving towards OpenVPN 2.4 in Fedora). So if the consensus is that we should just silently wait until upstream OpenVPN forces this change upon us, then I don't want to he hear a lot of noise and complaints when OpenVPN is updated later on in Fedora. I rather prefer to have this change in Fedora _now_ in a _planned_ release where this can be tested out before the final F27 is released. And where we have a chance roll it back if yet unknown and unexpected issues are found and not getting a proper fix in a timely manner. With this approach _we_ have better control of what happens for our Fedora users. And this is me wearing the Fedora, not the OpenVPN hat. -- kind regards, David Sommerseth _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
