Send inn-workers mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/inn-workers
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of inn-workers digest..."
Today's Topics:
1. Re: Potential Memory Leak in inn-2.6.0/lib/getaddrinfo.c
(Julien ?LIE)
2. Improving require_ssl (Julien ?LIE)
----------------------------------------------------------------------
Message: 1
Date: Tue, 13 Oct 2015 21:27:55 +0200
From: Julien ?LIE <[email protected]>
To: "[email protected]" <[email protected]>
Cc: [email protected]
Subject: Re: Potential Memory Leak in inn-2.6.0/lib/getaddrinfo.c
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Bill,
> In reviewing source code in inn-2.6.0, I found a call to strdup() in
> file 'getaddrinfo.c', which upon failure does not release the memory
> previously allocated to variable 'sin' via calloc().
getaddrinfo.c comes from the rra-c-util package maintained by Russ. I
bet he will tell when and if your kind patch is taken into account.
> Also, in sub-directory 'innfeed', file config_y.c, there are
> numerous instances of calls to calloc() which are not checked for a
> return value of NULL, indicating failure.
Would changing all calloc() calls to xcalloc() suit you?
(The same way that file already uses xmalloc().)
> confparse.c:1090:45: warning: Access to field 'file' results in a
dereference
> of a null pointer (loaded from variable 'group')
> syswarn("%s:%u: open of %s failed", group->file, group->line,
path);
> ^~~~~~~~~~~
group->file comes from the group struct given to parse_include(), which
comes from the result of group_new() that uses file->filename from the
file variable given to parse_group() taking it from
parse_group_contents() that takes it from file_open().
When file_open() fails, it returns NULL and neither parse_group() nor
parse_group_contents() are called. Otherwise, file->filename is not NULL.
Besides, the group variable struct created by group_new() is not NULL.
I therefore do not see where the issue comes from. Maybe a false
positive from clang?
Or does it just want:
if (group == NULL)
return false;
at the beginning of the parse_include() function?
Yet, if that is the case, I do not understand why clang does not
complain for line 1058 just before, where group->file is also used:
slash = strrchr(group->file, '/');
> confparse.c:1093:21: warning: Access to field 'included' results in a
dereference
> of a null pointer (loaded from variable 'group')
> group->included = path;
> ~~~~~ ^
I don't understand this one. We're affecting "path" to
"group->included", and not reading the value of "group->included".
group is also not NULL (created with group_new()).
--
Julien ?LIE
? Les femmes seront les ?gales des hommes le jour o? elles
accepteront d'?tre chauves et de trouver que cela distingue. ?
(Coluche)
------------------------------
Message: 2
Date: Tue, 13 Oct 2015 21:54:56 +0200
From: Julien ?LIE <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Improving require_ssl
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi all,
In INN 2.6.0, the require_ssl parameter in readers.conf applies to:
- users whose connection is encrypted from the beginning (nnrpd runs
with the -S flag);
- users who authenticate with AUTHINFO USER/SASL after the use of STARTTLS.
The require_ssl parameter is available only when INN is built with TLS
support.
Here is a suggestion of improvement.
In INN 2.6.1, the require_ssl parameter in readers.conf will apply to:
- users whose connection is encrypted from the beginning (nnrpd runs
with the -S flag);
- users who have used STARTTLS (without necessarily authenticating
themselves afterwards, contrary to INN 2.6.0);
- users who authenticate with AUTHINFO SASL and negotiate an encrypted
layer at the same time (a few SASL mechanisms permit that).
The require_ssl parameter will be available when INN is built with
either TLS support or SASL support.
Does it sound good to you? Other use cases to add?
I also wonder whether we should not rename require_ssl to another name
(like require_encryption). Any suggestion? or is require_ssl generic
enough?
We could do such a change through innupgrade either for INN 2.6.1 or 2.7.0.
--
Julien ?LIE
? Les femmes seront les ?gales des hommes le jour o? elles
accepteront d'?tre chauves et de trouver que cela distingue. ?
(Coluche)
------------------------------
_______________________________________________
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers
End of inn-workers Digest, Vol 77, Issue 1
******************************************
