On 27/08/18 14:46, David Sommerseth wrote:
> Wrong. We have those #ifdefs already, it just needs to be reverted and add an
> additional logic in configure.ac to "unlock" unsafe features. Look for
> ENABLE_LZO and ENABLE_LZ4 in the code.
Meh ... Just to clarify ... It needs to be *reversed*, is wh
On 24/08/18 21:16, Gert Doering wrote:
> You do not need to agree with me on this, you just need to accept this
> as a fact of life. I will resist any change that removes useful
> functionality from the "swiss tool kit of VPN" side of OpenVPN just
> because users could "get it wrong".
The only
I agree with Arne on this one. I’m OK with a warning, but I don’t think we
should make it impossible. This is where nasty forks start to show up because
we broke something upstream (recall the day s of the lack of password-save in
our Windows client).
Eric F Crist
> On Aug 27, 2018, at 03:1
>That is a terrible idea. The intention is good but users will then opt
>out of encryption because they want compression or build stacked VPNs.
That was the point of the idea though. If you want to go that far to
go around security, you are very aware of the consequences of what
you're doing. If w
Am 27.08.18 um 00:55 schrieb Derek Zimmer:
> There's always the option of not allowing encryption to be enabled
> with compression enabled. This keeps things like using OpenVPN as
> fancy proxy working without endangering the privacy VPN use-case.
That is a terrible idea. The intention is good but
