This would allow interested parties to do experimental runs with an
environment set appropriately to raise all the warnings throughout the
build; e.g. env WARNS=6 NO_WERROR=yes buildworld.
Not currently touching the numerous instances in ^/tools.
MFC after: 1 week
r316063 installed pf's embedded libevent as a private lib, with headers
in /usr/include/private/event. Unfortunately we also have a copy of
libevent v2 included in ntp, which needed to be updated for compatibility
with OpenSSL 1.1.
As unadorned 'libevent' generally refers to libevent v2, be explicit that
this one is libevent v1.
Reviewed by: vangyzen (earlier)
Differential Revision: https://reviews.freebsd.org/D17275
This is mostly two problems spread out far and wide:
- ypldap_process should be declared properly
- debug is defined differently in many programs
For the latter, just extern it and define it everywhere that actually needs
it. This mostly works out nicely for ^/libexec/ypxfr, which can remove the
assignment at the beginning of main in favor of defining it properly.
-fno-common will become the default in GCC10/LLVM11.
MFC after: 3 days
In this path, we used va_start() without pairing it with va_end(). Add the
va_end(). (va_start() without paired va_end() is undefined behavior per the C
standard.)
"In many implementations, [va_end] is a do-nothing operation; but those
implementations that need it probably need it badly." - Rationale for the ANSI
C Programming Language, § 4.8.1.3.
Reported by: Coverity
CID: 1340539
Since YP protocol definition uses the constant to declare
variable-size opaque byte strings, the change should be binary
compatible with existing installations which do not expose keys or
values larger than 1024 bytes.
All uses of local variables with YPMAXRECORD sizes were removed to
avoid insane stack use. On the other hand, variables with static
lifetime should be fine and only result in increased VA use.
Glibc made same change, increasing the allowed length for keys and
values in YP to 16M, in 2013.
Reviewed by: markj
Discussed with: ian
Sponsored by: Mellanox Technologies
MFC after: 3 weeks
Differential revision: https://reviews.freebsd.org/D20900
nis_ypldap_enable and nis_ypldap_flags.
Also add an entry on ypldap(8) that it is a feature ready and
appears on FreeBSD 11.0.
Requested by: rodrigc
Relnotes: Yes
At line 479 of ldapclient.c in client_build_req(), the error return
leaks ldap_attrs (CID 1340544). It looks like this can happen if
the first utoa() call in aldap_get_stringset() fails. It looks
like other leaks can happen if other utoa() calls fail since scanning
this array when it is freed stops when the first NULL is encountered.
Fix these problems by not storing NULL in the array when utoa()
fails, and by freeing ret and returning NULL if nothing is stored
in the array. That way the caller will never see the
ldap_attrs[0] == NULL case, so delete that check.
The ber_printf_element() calls ber_free_elements() on its ber
argument and returns NULL on failure. When each of its callers
detects failure, they do a goto fail, which then calls ber_free_elements()
with the same pointer (CID 1340543). Fix is to delete the
ber_free_elements() from ber_printf_element()
Reported by: Coverity
CID: 1340543, 1340544
Reviewed by: araujo
Differential Revision: https://reviews.freebsd.org/D6550
some kind of UTF-8 validation, but actually didn't, but instead, for
malformed UTF-8 input, caused buffer overruns in some cases and caused
skipping of valid ASCII characters in other cases.
Obtained from: OpenBSD (cvs 1.32)
tunable. Also it gets more close with the original implementation from
OpenBSD.
Requested by: rodrigc
Approved by: rodrigc (mentor)
Differential Revision: https://reviews.freebsd.org/D4970
This commit, fix a core dump on ypldap(8) related with memory allocation.
Also an example of how to set the ypldap.conf(5) properly is added to
examples files.
A new user _ypldap is required to be able to run ypldap(8) as well as
in a chroot mode.
Reviewed by: rodrigc (mentor), bjk
Approved by: bapt (mentor)
Relnotes: Yes
Sponsored by: gandi.net
Differential Revision: https://reviews.freebsd.org/D4744
ypldap -- Intended to be a drop-in replacement for ypserv, gluing in a
LDAP directory and thus providing support for users and groups stored in
LDAP for the get{pw,gr}ent family of functions.