Le 12/16/16 à 23:33, Steffan Karger a écrit :
> Also, is -Werror=format-security needed (instead of -Wformat-security)
> if we already have -Werror?
No. In this case, it's indeed clearer to have -Wformat-security
Julien
signature.asc
Description: OpenPGP digital signature
-
Le 12/17/16 à 11:44, Gert Doering a écrit :
> Taking 2.4_rc2 and building on AIX with -Wall -Wno-pointer-sign is
> actually much less bad than I thought :-) - but there are things in
> there which are annoying, like these
>
> ../../../git/src/openvpn/route.c: In function 'add_route_ipv6':
> ../..
Le 12/16/16 à 21:52, Steffan Karger a écrit :
>> +AX_CHECK_COMPILE_FLAG([ -Werror=implicit ], [
>> +CFLAGS_EXTRA="$CFLAGS_EXTRA -Werror=implicit"
>> +])
>> +AX_CHECK_COMPILE_FLAG([ -Werror=format -Werror=format-security ], [
>> +CFLAGS_EXTRA="$CFLAGS_EXTRA -Werror=format -Werror=format-secu
The bug in Trac #792 (pointer wrongly truncated as 'int', leading to segfaults)
would have been understood faster with either
-Werror=implicit or -Werror=format
(and above all, before running buggy executables in production)
Debian already compiles with -Werror=format-security, and it's indeed a
Le 12/16/16 à 18:03, Steffan Karger a écrit :
> On 16-12-16 17:32, Julien Muchembled wrote:
>> This fixes a regression in commit 8e95e20913:
>> on amd64, an implicit declaration of ERR_error_string leads to segfaults
>> if the returned pointer does not fit in an &#
This fixes a regression in commit 8e95e20913:
on amd64, an implicit declaration of ERR_error_string leads to segfaults
if the returned pointer does not fit in an 'int'.
Trac: #792
Signed-off-by: Julien Muchembled
---
This patch is for the 2.3 branch. In the master branch,
crypto
To avoid issues like https://community.openvpn.net/openvpn/ticket/792 to happen
again, I wanted to also submit a patch that adds a few -Werror= flags. However,
I wonder what would be your preferred way to only add flags that are supported
by the compiler.
One solution is with
https://www.gnu.
Le 07/30/14 11:37, Gert Doering a écrit :
>> Although I didn't try all MTU-related options of OpenVPN, it seems to
>> ignore EMSGSIZE.
>
> Well, handling that error will not lead anywhere, as it just tells us
> "the packet got lost, because it was too big".
Maybe not such a good idea but could
Hello,
Le 07/30/14 07:42, Gert Doering a écrit :
> On Wed, Jul 30, 2014 at 03:15:53AM +0200, Julien Muchembled wrote:
>> Le 07/29/14 23:05, Gert Doering a écrit :
>>>> For example:
>>>> A --[mtu=1500]-- B --[mtu=1400]-- C
>>>>
>>>> Given
Le 07/29/14 23:05, Gert Doering a écrit :
>> For example:
>> A --[mtu=1500]-- B --[mtu=1400]-- C
>>
>> Given a UDP6 socket on A with IPV6_MTU_DISCOVER=IP_PMTUDISC_DO,
>> sendto(1452 bytes, B) will succeed
>> but sendto(1452 bytes, C) will return EMSGSIZE (except for the first send to
>> C)
>
Le 07/29/14 20:57, Gert Doering a écrit :
> On Tue, Jul 29, 2014 at 07:28:49PM +0200, Julien Muchembled wrote:
>> Socket configuration of MTU discovery was done unconditionally at IP level,
>> which has no effect for other protocols. This fixes the issue of OpenVPN
>> sending
Socket configuration of MTU discovery was done unconditionally at IP level,
which has no effect for other protocols. This fixes the issue of OpenVPN
sending fragmented tcp6/udp6 packets even when 'mtu-disc yes' option is passed.
Signed-off-by: Julien Muchembled
---
src/openvpn/mtu
12 matches
Mail list logo
