Kea

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

https://gitlab.isc.org/isc-projects/kea/-/commits/master

We use git - our primary repository is a self-hosted instance of Gitlab, with a mirror on Github. https://gitlab.isc.org/isc-projects/kea

We have only issued a few versions so far. Those are consistent with the SemVer format.

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

We issue release notes with every release, which include the changelog for changes since the prior version. https://gitlab.isc.org/isc-projects/kea/-/releases

We have a pretty mature system for vulnerability handling, documented here: https://kb.isc.org/docs/aa-00861 We have had very few reportable CVEs in Kea, but they are well documented, in the Mitre Database as well as in our own release notes and knowledgebase. ISC is a CNA. Example CVE for Kea: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-6474

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

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

We address the majority of relevant bug reports much faster than 12 months. We do include a lot of 'to do' items in our issue tracker, it is not only bugs, and some of those linger for a while. We have some reports on the time taken in the various steps in the process here: https://gitlab.isc.org/isc-projects/kea/-/value_stream_analytics

We address the majority of relevant enhancement requests much faster than 12 months. The project is quite active. We do include a lot of 'to do' items in our issue tracker, it is not only bugs, and some of those linger for a while.

Our repository is open, if this means issue reports. The following link will give you all the closed issue reports. https://gitlab.isc.org/isc-projects/kea/-/issues?scope=all&utf8=✓&state=closed

https://www.isc.org/security-report/

https://www.isc.org/security-report/

You can email us at security-officer@isc.org, ideally using encrypted email. Reports to this alias are responded to immediately by a member of our security incident team. We would then create an issue in Gitlab, and make that issue 'confidential' until it is published and the issue disclosed as a CVE (if the report turns out to be accurate).

Our process is well with this - normally we respond to security issues within the hour. Kea has not had any security reports in the past 6 months however.

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

Our CI build system is integrated with our repo.

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

Our CI build system is integrated with our repo. We do still use an older Jenkins-based system for some testing as well. https://jenkins.isc.org

Unit tests are part of the main project repo. https://gitlab.isc.org/isc-projects/kea/-/blob/master/CONTRIBUTING.md

We document how to run tests here https://gitlab.isc.org/isc-projects/kea/-/blob/master/CONTRIBUTING.md#running-unit-tests We use "make check". We also developed a system/conformance test suite called ISC Forge, available here: github.com/isc-projects/forge. It is being run as part of our CI system, after each commit. We also have automated perfomance tests using perfdhcp (part of the Kea source tree).

This is of course a goal. We also have system-level tests, compliance and performance tests. We have developed and published tools for performance tests and protocol compliance testing.

We use GitlabCI (https://gitlab.isc.org/isc-projects/kea/-/pipelines) and also have internal Jenkins system that runs additional tests, such as coverage, conformance, negative, performance and other test types.

We adhere to this strictly, as explained in our Contribution guidelines. (https://gitlab.isc.org/isc-projects/kea/-/blob/master/CONTRIBUTING.md)

If you look at any major merge request you can see the results of the CI tests. We use danger and other standard tools to check for compliance to our commit requirements.

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

Yes, our standard CI process includes linter tools.

We are a bit behind in addressing some of our static analysis results (https://scan.coverity.com/projects/kea?tab=overview).

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 external libraries for our cryptographic requirements. (Botan or OpenSSL)

We use external libraries for our cryptographic requirements. (Botan or OpenSSL)

We use external libraries for our cryptographic requirements. (Botan or OpenSSL)

We use external libraries for our cryptographic requirements. (Botan or OpenSSL)

We may MD5 for generating pseudo random numbers, but this is really not a crypto function.

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

This mainly applies to the authentication of Kea to external database backends. It is possible to build the software so that it does not store the credentials for Kea to authenticate with the external database (it stores an empty password). The result is the user is prompted to enter the password when Kea boots up and connects to the database.

We sign the tarballs distributed on the web site and the packages distributed from our package repository and our web site is https.

our signatures are stored on our ftp site, they are signed by our private/public key pair https://www.isc.org/pgpkey/

https://www.cvedetails.com/product/32807/ISC-KEA.html?vendor_id=64

I am not sure how to prove this, given how extremely rare CVES are in this project.

We use Coverity Scan (https://scan.coverity.com/projects/kea?tab=overview), cppcheck (on internal Jenkins), clang static analyzer (internal Jenkins), shellcheck

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

We do treat all known vulnerabilities seriously. We do have security policy (https://kb.isc.org/docs/aa-00861) and depending on the severity suspend our regular schedule to work on fix asap ("all hands on deck" scenario for high severity), including fix in a monthly release, backporting fix to older stable releases, or issue operational notifications for low severity issues with easily applicable workarounds.

We do have an extensive CI environment. The static and dynamic analysis is run on each commit. While there are days without commits (holidays etc.), this approach ensures we have checks on every change.

We do use AFL. The fuzzing could definitely be improved and expanded, but it's being conducted in an automated and continuous way (the fuzzer hardware is shared between several projects, each running a certain number of days per month). We also run unit-tests with a thread sanitizer.

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

Kea production code handles error situations with C++ exceptions. There's a configuration (--with-gtests or --with-gtest-source) available that validates the exceptions with massive amounts of asserts. A quick grep showed 17000+ asserts in our source code. Note we're using ASSERT_NO_THROW, ASSERT_THROW and similar macros from gtest suite.

Yes, see the answer about medium and higher severity exploitable vulnerabilities above. We use the same process, regardless of the source of the vulnerability (found by dynamic code analysis, discovered by QA team, reported externally etc).