> On 29-08-18 17:18, Jan Just Keijser wrote:
>> Since when can I not type in
>> rm -rf /
>> any more ? did someone build in a flag into the "rm" command to stop me
>> from doing so? I sure hope not.
>
> $ sudo docker run --rm debian rm -rf /
> rm: it is dangerous to operate recursively on '/'
>
On 29-08-18 17:18, Jan Just Keijser wrote:
> Since when can I not type in
> rm -rf /
> any more ? did someone build in a flag into the "rm" command to stop me
> from doing so? I sure hope not.
$ sudo docker run --rm debian rm -rf /
rm: it is dangerous to operate recursively on '/'
rm: use --no-
On 27/08/18 14:46, David Sommerseth wrote:
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 us
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
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.
This gives users the on/off switch and explicitly shows them that
encryption + compression is not s
Hi,
On Fri, Aug 24, 2018 at 04:31:44PM +0200, David Sommerseth wrote:
> > Open Points:
> >
> > - Gert strongly thinks that some people might want to continue having
> > full compression despite the risks. I think it is reasonable to expect
> > them to add 'compress-direction full' and push "compr
On 24/08/18 13:11, Arne Schwabe wrote:
> Hey,
[...snip...]
> - Introduce compress-direction asym|full This will control if we
> actively try to compress or just allow receiving of compressed packets
I'm not sold on this one at all.
> - change the default mode to be asymmetrical.
Agreed. Local s
On 24/08/18 12:11, Arne Schwabe wrote:
Hey,
with this mail I would like to discuss the way forward for compression.
Our default configuration has not compression enabled. So our default
configuration is safe from Voracle.
I would like to have some feedback what the rest of you t
Hi,
On Fri, Aug 24, 2018 at 01:11:44PM +0200, Arne Schwabe wrote:
> On top of that, a lot of the traffic that the VPN carry today is either
> already compressed or encrypted and cannot be compressed any more. So
> benefits are diminishing.
This part is true for the "I use a VPN to safely surf the
Hey,
with this mail I would like to discuss the way forward for compression.
When compression was added to OpenVPN, a lot of Internet traffic was
still unencrypted and encryption+compression was thought to be good
thing. With recent attack like CRIME, BEAST and VORACLE, the general
consensus in t
14 matches
Mail list logo
