Kea

We do have 3 stable branches. As of time writing, this was stable 1.6, stable 1.8 and development 1.9. All versions are available as sources on our FTP site (http://ftp.isc.org/isc/kea/) and native packages (cloudsmith.io/~isc/repos/). The general upgrade procedure is well documented in the Kea ARM, especially the kea-admin tool section that involves database upgrades (https://kea.readthedocs.io/en/kea-1.8.2/arm/admin.html). We recently started adding section in the release notes to warn about potential pitfalls and incompatible changes (https://gitlab.isc.org/isc-projects/kea/-/wikis/release%20notes/release-notes-1.9.4#incompatible-changes). Our changelog lists incompatible changes with an asterisk. For ancient (pre 1.6 versions), we do have a migration document: https://gitlab.isc.org/isc-projects/kea/-/wikis/migrating-to-kea-1.6

https://gitlab.isc.org/isc-projects/kea/-/issues

Kea enjoys very thorough, massive testing process (6000 unit-tests, 1500 system tests) and multiple automated tools (coverity scan, cppcheck, valgrind, thread sanitizer, shellcheck, danger, etc), fuzzing (afl) and stability tests (perfdhcp). We haven't had a security incident in well over a year.

We do have it: https://kb.isc.org/docs/aa-00861 and https://www.isc.org/reportbug/. Also, our gitlab has a note how to report vulnerability reports, see the bug template: https://gitlab.isc.org/isc-projects/kea/-/blob/master/.gitlab/issue_templates/bug_report.md We do have similar note for github.

Sure we do. I can't imagine having a large project without coding guidelines: https://gitlab.isc.org/isc-projects/kea/-/wikis/Processes/coding-guidelines

We're using autotools (autoconf, automake and friends) and do our best to play by the rules. Details here: https://kea.readthedocs.io/en/kea-1.8.2/arm/install.html#configure-before-the-build

We try to provide flexible environment. The user can specify whatever debugging options for g++ he/she wishes. We also have --enable-debug that conveniently enables -O0 -g and couple other things. It's by no means mandatory and user can specify or tweak flags as desired.

running make distcheck is part of our build process and it's verified after each commit that's merged on master.

User who like to compile can do the usual make install, make uninstall. We also provide native (DEB, RPM, APK) packages for many distros that make the installation and removal easy. The nature of this project (DHCP server) implies that some manual configuration is necessary.

Yes, we're using normal autoconf/automake regime. --prefix and more detailed switches (--bindir, --sbindir, --libexecdir, --runstatedir and more) are available.

We do have a Developer's guide that explains how to set up the test environment to run unit-tests. Also have a dedicated tool named hammer that can automate installing Kea on bare metal or spin up VMs with requested mandatory and optional dependencies. For details, see https://gitlab.isc.org/isc-projects/kea/-/blob/master/hammer.py.

Kea can be compiled using GNU autotools (with using automated configure script) or installed using native (DEB, RPM or APK) packages. The autotools automatically detect presence or absence of external dependencies. The packages have listed external dependencies, so they're installed automatically. Details in the package scripts: https://gitlab.isc.org/isc-projects/kea-packaging

Kea has a -W option that lists external dependencies used during compilation, including their versions. The configure script (typical GNU autotools) provide an option to use alternative components (such as patched dependency in non-standard location). The dependencies are well documented in the Kea ARM document (see https://kea.readthedocs.io/en/kea-1.8.2/arm/intro.html#required-software-at-run-time).

We try to not use deprecated or obsolete functions and APIs. When possible, we print out a warning that a dependency (e.g. openssl) is too old and we disable TLS support in Kea. For some cases, e.g. CentOS 7, which still is popular, we attempt to provide alternatives, e.g. you need to install newer openssl. all the technology stack is open source (mostly gcc, but also flex, bison, and other smaller open source tools).

We do have a massive (6000+ unit-tests, 1500 system tests) test farm. It is run after each check-in.

We try to live by the TDD (test driven development) philosophy. Except some rare corner cases, each fix or new functionality has new unit tests. For non-trivial features or bugfixes system tests are frequently developed by an independent QA. Often the system tests are ready before the functionality is ready.

We have developed a generic DHCP/DNS testing suite called ISC Forge. It's published under ISC license. See https://github.com/isc-projects/forge

Yes, it's part of out coding guidelines: https://gitlab.isc.org/isc-projects/kea/-/wikis/Processes/coding-guidelines and https://gitlab.isc.org/isc-projects/kea/-/blob/master/CONTRIBUTING.md

https://gitlab.isc.org/isc-projects/kea/-/blob/master/CONTRIBUTING.md

By default, our configure script enables the following extra switches in g++: -Wall -Wextra -Wnon-virtual-dtor -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -pthread -Wno-missing-field-initializers -fPIC. Note the -Wall and -Wextra. Many of our builds are run with -Werror. We do experiments with -Wpedantic sometimes, but we're not fully committed to that idea yet.

We use security for TSIG, but there is no default algorithm, it must be positively specified.

We support HMAC-MD5 (for backward compatibility), HMAC-SHA1, HMAC-SHA224, HMAC-SHA256, HMAC-SHA384 and HMAC-SHA512 in our TSIG implementation.

As of April 2021, we have implemented TLS support in Kea.

We support TLS 1.3. Details: https://kea.readthedocs.io/en/kea-1.9.7/arm/security.html#tls-https-support

All releases are signed and each release notes document has a note about how to check them. See example here: https://gitlab.isc.org/isc-projects/kea/-/wikis/release%20notes/release-notes-1.9.5#download and a general instructions how to check the signatures: https://www.isc.org/pgpkey/

We use the standard capabilities of GITLAB. See details here: https://gitlab.isc.org/isc-projects/kea/-/releases

DHCP often being the first packets exchanged with an unknown new device entering the network, we pay strict attention to data sanitization, including truncated, malformed, oversized fields, options and packets etc. The requests received over Kea management API undergo sanity checks before they're processed. We have substantial amount of system and unit tests that check for broken input. We also do fuzz testing for incoming packets and configuration files.

Coverity Scan, cppcheck, danger, clang static analyzer, shellcheck

We run valgrind tests under Jenkins, use cppcheck, and thread sanitizer from clang.