Since we use strlen() to determine the length
and then check it ourselves, there is really
no point in using strncpy.
But the compiler might complain that we use
the output of strlen() for the length of
strncpy which is usually a sign for bugs:
error: ‘strncpy’ specified bound depends
on the len
Just some very basic tests.
v2:
- fix off-by-one
Change-Id: I73fc893136387d1da05f4aea98cb37b02d6c3230
Signed-off-by: Frank Lichtenheld
---
tests/unit_tests/openvpn/test_buffer.c | 62 ++
1 file changed, 62 insertions(+)
diff --git a/tests/unit_tests/openvpn/test_buffer
This function allows us to map from a management key id to a key structure
and also allows this function to be reused.
Signed-off-by: Arne Schwabe
---
src/openvpn/ssl_common.h | 20
src/openvpn/ssl_verify.c | 17 +++--
2 files changed, 27 insertions(+), 10 deleti
the management interface expects the management key id instead
of the openvpn key id. In the past they often were the same for low ids
which hid the bug quite well.
Also do not pick uninitialised keystates (management key_id is not valid
in these) and provide better logging when a key state is not
Since we use strlen() to determine the length
and then check it ourselves, there is really
no point in using strncpy.
But the compiler might complain that we use
the output of strlen() for the length of
strncpy which is usually a sign for bugs:
error: ‘strncpy’ specified bound depends
on the len
Am 15.02.23 um 13:31 schrieb David Sommerseth:
OpenVPN 2.x is licensed under the GNU Public License v2.0 (GPL-2.0).
This license has served us well in the past and we are not trying to
change that. However, changes in licenses of our dependencies put us in
an unfortunate situation.
So a go
Acked-by: Gert Doering
Unit Tests are good, this function-under-test is a bit weird, and
having the UTs in tree (and working) before the actual patch gives
double assurance that it's still working in the same weird way :-)
[ RUN ] test_buffer_printf_catrunc
[ OK ] test_buffer_printf_c
Acked-by: Gert Doering
Change looks good (less +/-1, so easier for my old brain), and our nice
and shiny new unit test confirms that things still work.
Your patch has been applied to the master branch.
commit c89a97e449baaf60924a362555d35184f188a646
Author: Frank Lichtenheld
Date: Wed May 17
malloc was not checked against NULL, I was able
to get core dump in case of failure
Signed-off-by: Ilya Shipitsin
---
src/openvpn/dco_freebsd.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/openvpn/dco_freebsd.c b/src/openvpn/dco_freebsd.c
index abeb..adbd1120 100644
--- a/src
On 17 May 2023, at 16:01, Ilya Shipitsin wrote:
> malloc was not checked against NULL, I was able
> to get core dump in case of failure
>
> Signed-off-by: Ilya Shipitsin
> ---
> src/openvpn/dco_freebsd.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/src/openvpn/dco_freebsd.c b/src
Hi,
On 17/05/2023 22:01, Ilya Shipitsin wrote:
malloc was not checked against NULL, I was able
to get core dump in case of failure
Signed-off-by: Ilya Shipitsin
---
src/openvpn/dco_freebsd.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/openvpn/dco_freebsd.c b/src/openvpn/dco
ср, 17 мая 2023 г. в 22:43, Kristof Provost :
> On 17 May 2023, at 16:01, Ilya Shipitsin wrote:
> > malloc was not checked against NULL, I was able
> > to get core dump in case of failure
> >
> > Signed-off-by: Ilya Shipitsin
> > ---
> > src/openvpn/dco_freebsd.c | 5 +
> > 1 file changed, 5
ср, 17 мая 2023 г. в 22:47, Antonio Quartulli :
> Hi,
>
> On 17/05/2023 22:01, Ilya Shipitsin wrote:
> > malloc was not checked against NULL, I was able
> > to get core dump in case of failure
> >
> > Signed-off-by: Ilya Shipitsin
> > ---
> > src/openvpn/dco_freebsd.c | 5 +
> > 1 file cha
On 17 May 2023, at 16:58, Илья Шипицин wrote:
> ср, 17 мая 2023 г. в 22:43, Kristof Provost :
>
>> On 17 May 2023, at 16:01, Ilya Shipitsin wrote:
>>> malloc was not checked against NULL, I was able
>>> to get core dump in case of failure
>>>
>>> Signed-off-by: Ilya Shipitsin
>>> ---
>>> src/open
ср, 17 мая 2023 г. в 23:04, Kristof Provost :
> On 17 May 2023, at 16:58, Илья Шипицин wrote:
> > ср, 17 мая 2023 г. в 22:43, Kristof Provost :
> >
> >> On 17 May 2023, at 16:01, Ilya Shipitsin wrote:
> >>> malloc was not checked against NULL, I was able
> >>> to get core dump in case of failure
>
On 17 May 2023, at 17:06, Илья Шипицин wrote:
> ср, 17 мая 2023 г. в 23:04, Kristof Provost :
>
>> On 17 May 2023, at 16:58, Илья Шипицин wrote:
>>> ср, 17 мая 2023 г. в 22:43, Kristof Provost :
>>>
On 17 May 2023, at 16:01, Ilya Shipitsin wrote:
> malloc was not checked against NULL, I wa
Hi,
On 17/05/2023 23:10, Kristof Provost wrote:
On 17 May 2023, at 17:06, Илья Шипицин wrote:
ср, 17 мая 2023 г. в 23:04, Kristof Provost :
On 17 May 2023, at 16:58, Илья Шипицин wrote:
ср, 17 мая 2023 г. в 22:43, Kristof Provost :
On 17 May 2023, at 16:01, Ilya Shipitsin wrote:
malloc wa
Hi,
On Wed, May 17, 2023 at 04:43:01PM -0400, Kristof Provost wrote:
> Fwiw: I usually don???t bother handling malloc failure in userspace,
> because modern systems all overallocate anyway, so the first thing
> you know about lack of memory is the out-of-memory killer terminating
> you. It???s a p
18 matches
Mail list logo
