We disagree with this CVE. In the GitHub report , the RedHat reporter claims:
we are aware of a way to exploit this,
No description of this alleged exploit was shared with us at our security contact.
Our security contact is “firstname.lastname@example.org”, which has been active for almost 20 years. This address and security instructions are available on our web site at:
In the GitHub report, RedHat further claims that exploitation
… requires the attacker to already have “high privileges” (that is, he needs to have access to the radiusd user)
Which demonstrates that this issue is largely nonsense. A full explanation follows.
While the FreeRADIUS server runs as user/group “radiusd/radiusd”, that account has no login shell, no home directory, and no default password. The account is used solely to run the FreeRADIUS server, and to control ownership of configuration files and log files. These files are typically administered solely by the “root” user.
As such, the CVE can be better stated as “if the root user misconfigures FreeRADIUS, then the RADIUS server can later elevate privileges to root”.
We have to ask why the “root” user would need to leverage a less-privileged account in order to gain “root” permissions.
Further, anyone who can operate as the RADIUS server can perform all RADIUS authentication and authorization. i.e. authenticating all users on the network, including unknown and malicious users.
There is at this time no known exploit which would let malicious users gain access to the “radiusd” user. Therefore as discussed here, there is simply no way for anyone to gain privileges through this alleged issue.
In addition, there also appears to be disagreement within RedHat about the severity and scope of this issue. The original reporter  states:
The su directive to logrotate ensures that log rotation happens under the owner of the logs. Otherwise, logrotate runs as root:root, potentially enabling privilege escalation if a RCE is discovered against the FreeRADIUS daemon.
This attack avenue seems quite unlikely to me.
We agree. We take great care in securing FreeRADIUS. We use multiple source code analyzers and fuzzing tests.
Even the most charitable interpretation of this issue shows that the vulnerability is theoretical in nature, and is not currently exploitable.
As such, we disagree with the issuance of this CVE. We also express dismay at the process by which this CVE was issued. We recommend that security “experts” follow best practices in discussing issues with authors prior to requesting spurious CVEs.
 https://github.com/FreeRADIUS/freeradius-server/pull/2666#issuecomment-495511510  https://github.com/FreeRADIUS/freeradius-server/pull/2666#issue-276755666
2019.04.10Authentication bypass in EAP-PWD
The EAP-PWD module is vulnerable to multiple issues, including authentication bypass. This module is not enabled in the default configuration. Administrators must manually enable it for their server to be vulnerable. Version 3.0.0 through 3.0.18 are are affected.
The EAP-PWD module is vulnerable to side-channel and cache-based attacks. The issue is discussed in more in Hostap 2019-2. The attack requires the attacker to be able to run a program on the target device. This is not commonly the case on an authentication server (EAP server), so the most likely target for this would be a client device using EAP-PWD. It is not clear at this time if the attack is possible between multiple virtual machines on the same hardware.
Other issues with EAP-PWD were found earlier, and patched in Hostap. The FreeRADIUS team was not notified of these attacks until recently. We have now patched FreeRADIUS to address these issues.
Additional issues were found by Mathy Vanhoef as part of a deep investigation into EAP-PWD. He also supplied patches to address the issues. His report is included below. This issue is recorded in VU#871675
We have released version 3.0.19 to address these issues.
Report from Mathy VanHoef
This report summarizes possible implementations-specific vulnerabilities in EAP-pwd clients or servers. Additionally, it summarizes two design flaws in EAP-pwd that all implementations are likely vulnerable to (note that you may have already received information about these design flaws previously).
While investigating 4 different EAP-pwd implementations, we discovered that all 4 were vulnerable to invalid curve and reflection attacks. Although these are implementation-specific flaws, this indicates both vulnerabilities might be present in other implementations of EAP-pwd as well. We therefore recommend to audit EAP-pwd implementations for these two vulnerabilities.
Invalid Curve Attack
The first implementation-specific vulnerability is an invalid curve attack, and
would allow an attacker to authenticate as any user (without knowing the
password). The problem is that on the reception of an EAP-PWD Commit frame, a
vulnerable EAP-pwd implementation does not verify whether the received elliptic
curve point is valid. To fix this vulnerability, it must be checked that the
received point is on the elliptic curve, and that it is not the point at
infinity (e.g. using the function
EC_POINT_is_at_infinity). Additionally, EAP-pwd implementations must check
that the received scalar s is within the range 1 < s < r, where r is the order
of the elliptic curve being used. If the scalar is not within this range, or
the curve point is not valid, the handshake should be aborted.
An adversary can exploit the above vulnerability by sending a scalar equal to zero (or equal to the order of the elliptic curve), and by sending a specially crafted (invalid) elliptic curve point. This combination causes the negotiated session key to have a very small range of possible values. The adversary can then test each possible key until the correct session key is found. We successfully confirmed this attack against both vulnerable client-side and server-side implementations.
The second implementation-specific vulnerability might allow “fake” authentications. More precisely, an attacker can reflect the received scalar and element (i.e. elliptic curve point) that was sent by the server, in its own commit message, and subsequently reflect the confirm value as well. This causes the adversary to successfully authenticate as the victim. Fortunately, the adversary will not learn the negotiated session key, meaning the adversary cannot actually perform any actions as the victim.
This vulnerability can be patched by comparing the received scalar and curve point to the one generated by the server (i.e. by comparing it to the element and scalar that was sent to the client). If either of them are the same, the handshake should be aborted.
We successfully tested this attack against vulnerable client-side implementations of EAP-pwd.
We also discovered design flaws in EAP-pwd which likely affect all implementations. Note that you may have already been informed about this in a separate announcement. In any case, we discovered the following two issues:
The password generation algorithm (the “hunting and pecking” algorithm) uses a variable number of iterations to find the password element. The precise number of iterations depends on the password being used, and on the token generated by the server. This means sensitive information is leaked if the adversary can measure how many iterations it took to derive the password element. Although making these measurements is far from trivial, obtaining this information allows the adversary to carry out a password partitioning attack (this is practically the same as an offline dictionary attack).
A backwards-compatible countermeasure is to always perform 40 iterations in the password generation algorithm. How to do this is explain in more detail in section 4.4.1 of RFC 8492, which describes a very close variant of the EAP-pwd handshake: https://tools.ietf.org/html/rfc8492#section-4.4.1 Additionally, determining whether there’s a quadratic residue should be done in a blinded manner. How this can be done is also explained in section 4.4.1 of RFC 8492.
On top of the above timing attack countermeasures, implementations must also incorporate defenses against cache-based attacks. This is because the password generation algorithm (the “hunting and pecking” algorithm) contains conditional branches based on secret values. If an adversary can determine which branch of such an if-then-else branch was taken, they can learn whether the password element was found in a specific iteration of this algorithm. In practice we found that, if an adversary can run unprivileged code on the victim machine, we were able to use cache-based attacks to determine which branch was taken in an iteration of the password generation algorithm. More concretely, an adversary can determine whether the password element was found in a specific iteration or not. This information can be abused to perform a password partitioning attack (this is similar to an offline dictionary attack).
Note that this cache-based attack is only possible if an adversary can run unprivileged code on the victim’s machine (e.g. from an android application that doesn’t have special privileges, or from a co-located virtual machine).
A backward-compatible countermeasure is to replace conditional branches that
depend on secret values with constant-time select utilities. See the file
constant_time.md for examples on how to do this in C. Implementations must
also use a constant time Legendre symbol computation.
2017.07.17Multiple issues found by Guido Vranken
We requested that Guido Vranken do fuzz testing against the server. He found issues in all versions of the server. These issues are documented on the fuzzer page.
2017.05.26Erroneous Session Resumption
We discovered that the server could be convinced to permit TLS session resumption before the authentication finished. A partial fix was put into 3.0.13. Pavel Kankovsky verified that the fix was insufficient, and provided a tool to test the issue. A better fix was put into the server, and was released in version 3.0.14.
The original EAP-TLS code would refuse to resume sessions unless there were policy attributes in the session cache. This check was put in place to work around this issue with the OpenSSL API. At some point, the code was changed to cache policy attributes by default, which opened up the vulnerability. Given the long history of the server, it is not clear when that change was made.
FIX: The short-term fix is to disable session resumption in the
cache subsection of the
We believe that this issue affects version 2.1.1 through 2.1.7 inclusive. Other versions seem to be unaffected. We remind users that versions 1.0.x, 1.1.x, 2.0.x, 2.1.x, and 2.2.x are old and unsupported. Patches for those versions will not be released, as the issue can be corrected with a minor configuration change. We also note that prior to version 3, the session cache was disabled by default, and required administrator intervention to enable it.
The v4.0.x branch is not vulnerable to this issue. The underlying code has been refactored to hide the TLS session data until the final EAP Success is sent, in the Access-Accept. This change means that the issue is impossible to reoccur in the future.
At this time, we have not had reports of the issue being exploited in the wild.
2017.05.16FreeRADIUS server scanned by PVS-Studio
You can read our write-up here.
Denis Andzakovic found issues with the decryption of very long Tunnel-Passwords. The decryption routines could walk off of the end of a buffer, and write to adjacent addresses. The data being written is not under control of an attacker. The end result is usually a crash of the server.
The initial report was for version 3.0. We determined that the v3.1.x branch in git is also vulnerable. Version 2 has similar code for Tunnel-Password, which we were not able to exploit. However, for safety, all currently supported versions of the server were fixed.
The packet decoder in FreeRADIUS ensures that the only time this issue is exploitable is when a proxy server receives a long Tunnel-Password attribute in the reply from a home server. The attack cannot be performed by a RADIUS client, or an end user. As such, the exploitability of the attack is limited to systems within the trusted RADIUS environment.
We are releasing version 2.2.9 and version 3.0.10 to correct the issue.
2015.06.22Revoked intermediate certificates are not properly validated
All versions which implement EAP-TLS, prior to 2.2.8 and 3.0.9 do not check intermediate CAs for revocation. We have put patches into the version 2 and version 3 branches to fix these issues.
We expect that this issue has minimal effect on the majority of RADIUS systems. If you are using a self-signed CA for 802.1X, this issue does not seriously affect you, as only you can issue intermediate certificates. If you are using certificates from a public CA, then your configuration already permits third parties to issue certificates which will be accepted by your RADIUS server.
i.e. The act of using a public CA cert in RADIUS can open your systems to security issues which are larger, and much worse than this one. The fix for this particular issue does not change the underlying security problem behind using a public CA.
Our analysis of the issue led us to disagree with the analysis done by oCert, and the (alleged) original vendor who made the report. We a requested a response to our analysis, and oCert refused. We requested that the public notice contain an accurate description of the issue and it’s impact. oCert again refused. After repeated messages, the response from Andrea Barisani of oCert was:
The reporter disagrees with your assessment yet cannot share details about their setup, oCERT has no wishes to do technical support on their setup as we just care about the reported bug.
Which is missing the point. We never asked to do “technical support on their setup”. We asked for an accurate description of the issue and it’s impact. oCert refused, whichs means that they do not, in fact, “care about the reported bug”.
We wanted to work together to come up with an accurate description of the issue, including it’s impact. It was clear that oCert was had no such goal. They saw their work as simply taking the original report, and forwarding it to a wider audience (including us).
We can only conclude that our analysis is correct, and that the original report, and the summary published by oCert is largely wrong. We can also recommend that people avoid oCert, as they are unwilling to work with authors to publish accurate reports.
The EAP-PWD module performed insufficient validation on packets received from an EAP peer. This module is not enabled in the default configuration. Administrators must manually enable it for their server to be vulnerable. Only versions 3.0 up to 3.0.8 are affected.
These issues were found by Jouni Malinen as part of investigating 2015-4 for HostAP.
- The EAP-PWD packet length is not checked before the first byte is dereferenced. A zero-length EAP-PWD packet will cause the module to dereference a NULL pointer, and will cause the server to crash.
- The commit message payload length is not validated before the packet is decoded. This can result in a read overflow in the server.
- The confirm message payload length is not validated before the packet is decoded. This can result in a read overflow in the server.
- A strcpy() was used to pack a C string into an EAP-PWD packet. This would result in an over-run of the destination buffer by one byte.
FreeRADIUS is not vulnerable to this issue. All version to at least 1.0.0 (and possibly earlier) require TLSv1.
Systems running FreeRADIUS may be vulnerable to this bug. The
default configuration does not execute any external programs or
shell scripts. However, administrators who have configured the
server to execute shell scripts must upgrade their version of
bash to a version which is not vulnerable.
2014.02.17Stack overflow in the PAP module
The CVE notification is CVE-2014-2015
The PAP module takes a “known good” password (e.g. Crypt-Password), and compares it to the password entered by the user (e.g. User-Password). In cases where the “known good” password was very long, insufficient input validation was performed. An administrator who controlled the password store could enter long passwords, and cause the server to crash.
2012.11.10Unix module allows expired passwords
The CVE notification is CVE-2011-4966.
It was found that the “unix” module ignored the password expiration setting in “/etc/shadow”. The default configuration does not use the “unix” module, so there is no issue for most deployments. However, if the server was configured to use this module for authentication, users with an expired password could successfully authenticate, even though their access should have been denied. We recommend managing users in a database, instead of leveraging /etc/passwd. The fact that a user has login access to a machine does not necessarily mean that they can use RADIUS for other kinds of network access.
2012.09.10Overflow in EAP-TLS
The CVE notification is CVE-2012-3547. The issue was found by Timo Warns, and communicated to email@example.com. A sample exploit for the issue was included in the notification.
We recommend all administrators using EAP and 2.1.10, 2.1.11, 2.1.12, or the git “master’ branch upgrade immediately.
The vulnerability was created in commit a368a6f4f4aaf on August 18, 2010. Vulnerable versions include 2.1.10, 2.1.11, and 2.1.12. Also anyone running the git “master” branch after August 18, 2010 is vulnerable.
All sites using TLS-based EAP methods and the above versions are vulnerable. The only configuration change which can avoid the issue is to disable EAP-TLS, EAP-TTLS, and PEAP.
An external attacker can use this vulnerability to over-write the stack frame of the RADIUS server, and cause it to crash. In addition, more sophisticated attacks may gain additional privileges on the system running the RADIUS server.
This attack does not require local network access to the RADIUS server. It can be done by an attacker through a WiFi Access Point, so long as the Access Point is configured to use 802.1X authentication with the RADIUS server.
We scanned the rlm_eap_tls.c file with the LLVM checker-267, taken from http://clang-analyzer.llvm.org/. It did not find this issue. However, a Coverity scan did discover it.
2011.09.22Manually enabling OCSP has no effect
This issue is applicable only to version 2.1.11.
The CVE notification is CVE-2011-2701. The discoverer notified us and sent a patch.
The OCSP functionality in 2.1.11 could be enabled manually, but it would never mark certificates as revoked. As such, it did not behave as expected.
Since this issue requires manually enabling OCSP, it’s severity is low. The recommended solution is to upgrade to version 2.1.12.
2010.10.08FreeRADIUS may crash if database goes down
If FreeRADIUS depends on a database, and the database goes down for extended periods, the server may crash. This issue applies to versions 2.0.0 through 2.1.9. This issue is not externally exploitable.
The CVE notification is CVE-2010-3697.
As with many such notifications, the issuer did not communicate with us before releasing the alleged vulnerability. We also disagree with their description of the problem.
The short description of this problem is that any administrator who can (a) take the database down, or (b) disrupt communication between FreeRADIUS and the database can prevent FreeRADIUS from operating correctly. This result should not be a surprise.
In normal operation, when the server stops responding to packets (i.e. because the database is down), the NAS will stop sending it packets, and will fail over to another server. In addition, our tests indicate that this issue occurs only when the database is down for extended periods of time, and the server receives many millions of packets during that time. i.e. the problem will not occur in most deployments.
There is no possibility for privilege escalation, or access to the system running FreeRADIUS. The issue is marked “network exploitable” in the CVE database because it requires the network to be down for the attack to work.
Our recommendation is to upgrade to the latest version of the server. We also recommend that mission-critical systems be monitored. If they go offline for extended periods, they should be restarted.
2010.10.08Code modifications to the server can cause it to crash
This issue is applicable only to version 2.1.9.
The CVE notification is CVE-2010-3696.
The issuer did not communicate with us before releasing the alleged vulnerability, and we disagree with their description of the problem.
The DHCP functionality in 2.1.9 is not enabled by default. Enabling it requires code modifications, a complete re-build and re-install of the server, and a manual enabling of DHCP in the configuration. Further, the DHCP functionality is marked “experimental” in this release. As such, it should be used only on trusted networks.
This issue is exploitable whenever FreeRADIUS has had DHCP functionality enabled, and where the administrator has manually configured the server to accept DHCP packets. Any DHCP packet with a “Relay Agent” sub-option can cause FreeRADIUS to enter an infinite loop.
Our recommendation is to run experimental features only in trusted networks.
2010.02.03Apple Mac OS X server misconfiguration
CVE-2010-0524 - This issue only affects Mac OS X Server systems.
Apple had apparently configured FreeRADIUS to accept all “well known” Certificate Authorities as valid for EAP-TLS. This configuration permitted almost anyone to create a client certificate for use with EAP-TLS, which would then be accepted by Mac OS X Server systems.
We recommend that the list of Certificate Authorities configured in FreeRADIUS be audited, and kept as small as possible.
2009.09.09Server crash with Tunnel-Password attribute
Anyone who can send packets to the server can crash it by sending a Tunnel-Password attribute in an Access-Request packet. This vulnerability is not otherwise exploitable. We have released 1.1.8 to correct this vulnerability.
This issue is similar to the previous Tunnel-Password issue noted below. The vulnerable versions are 1.1.3 through 1.1.7. Version 2.x is not affected.
2007.04.10Memory leak in EAP-TTLS can cause server crash
This issue affects version 1.1.5 and earlier.
A malicous 802.1x supplicant could send malformed Diameter format
attributes inside of an EAP-TTLS tunnel. The server would reject the
authentication request, but would leak one
structure, of approximately 300 bytes. If an attacker performed the
attack many times (e.g. thousands or more over a period of minutes
to hours), the server could leak megabytes of memory, potentially
leading to an “out of memory” condition, and early process exit.
We recommend that administrators using EAP-TTLS upgrade immediately.
2007.01.02Stack overflow in rlm_smb means admins can write to server config
While the summary is superficially correct, and there is a stack overflow in rlm_smb, the issue is less problematic than it sounds.
CVE-2007-0080 has been updated with our statement.
SecurityTracker Alert ID: 1017463 has been updated with our statement.
freeradius-smbconnectserver-bo (31248) has been updated to no longer claim the issue is remotely exploitable. They do not, however, include our vendor statement, though they do reference it. They also list the issue as “High Risk”, and “Gain Privileges”, which is NOT TRUE, for the reasons outlined below.
In summary, the issue is not remotely exploitable. It is exploitable by local administrators who have write access to the server configuration files. If an attacker can write to the server configuration files, they can configure the server to run arbitrary programs. Exploiting the server via a stack overflow would be unnecessary.
The solution to this “vulnerability”, of course, is to ensure that only the correct people are given write access to the server configuration files.
2006.03.20Insufficient input validation in MS-CHAP
A validation issue exists with the EAP-MSCHAPv2 module in all versions from 1.0.0 (where the module first appeared) to 1.1.0. Insufficient input validation was being done in the EAP-MSCHAPv2 state machine. A malicious attacker could manipulate their EAP-MSCHAPv2 client state machine to potentially convince the server to bypass authentication checks. This bypassing could also result in the server crashing. We recommend that administrators upgrade immediately.
2005.09.09Multiple SQL vulnerabilities
Multiple issues exist with version 1.0.4, and all prior versions of
the server. Externally exploitable vulnerabilities exist only for
sites that use the
rlm_sqlcounter module. Those sites may be
vulnerable to SQL injection attacks, similar to the issues
noted below. All sites that have not deployed the
module are not vulnerable to external exploits. However, we still
recommend that all sites upgrade to version 1.0.5.
The issues are:
- SQL Injection attack in the
- Buffer overflow in the
rlm_sqlcountermodule, that may cause a server crash.
- Buffer overflow while expanding %t, that may cause a server crash.
These issues were found by Primoz Bratanic. As the
module is marked “experimental” in the server source, it is not
enabled or configured in most sites. As a result, we believe that
the number of vulnerable sites is low.
2005.05.01Two SQL vulnerabilities
Two vulnerabilities in the SQL module exist in all versions prior to 1.0.3. Sites not using the SQL module are not affected by this issue. However, we still recommend that all sites upgrade to version 1.0.3.
The issues are:
- Buffer overflow - A long string could overflow an internal buffer in the SQL module, and write two bytes of text [0-9a-f] past the end of the buffer. The server may exit when this happens, resulting in a DoS attack. Depending on the local configuration of the server, this may occur before a user is authenticated. This vulnerability is externally exploitable, but can not result in the execution of arbitrary code.
- SQL injection attacks - The SQL module suffers from SQL
injection attacks in the
simul_verify_queryconfiguration entries. The first query is exploitable if your site is configured to use the
SQL-Groupattribute in any module in the
radiusd.conf. The last two queries are exploitable only if your site has user names that contain a single quote character (
2004.09.14Multiple external DoS attacks
Multiple external DoS attacks exist in the server. These are related to the attacks below, in 0.9.2, but were not caught then. The vulnerabilities are fixed in 1.0.1, and in all later versions of the server. The vulnerabilities are not exploitable, but can be used to remotely crash the server.
2003.11.20Externally exploitable root compromise in rlm_smb
There is an externally exploitable root compromise in rlm_smb, through a stack overflow when a password greater than 128 bytes referenced by the module. The module is not built or installed by default, so we have not released a 0.9.4. This vulnerability is fixed in the CVS snapshots, and will be included in any later release of the server.
2003.10.15Crash upon receipt of Tunnel-Password attribute
Anyone who can send packets to the server can crash it by sending a Tunnel-Password attribute in an Access-Request packet. This vulnerability is not otherwise exploitable. We have released 0.9.3 to correct this vulnerability.
2002.07.26Kerberos module may grant incorrect access
The Kerberos module may grant access to a user whose Kerberos ticket cannot be verified against the server principal. We have released 0.7.1 to correct this vulnerability.
2001.12.17Multiple RADIUS vulnerabilities
CA-2002-06. Multiple vulnerabilities in multiple RADIUS implementations. We have released 0.4 to correct these vulnerabilities.
OpenSSL has a major security issue, seen in to CVE-2014-0160. The issue mainly affects servers such as SMTPS or HTTPS, which allow random IP addresses to connect to them via TLS. Those sites must assume that all information available to the system using TLS has been compromised.
Based on further information from Jouni Malinen, it appears that both Version 2 and Version 3 of FreeRADIUS are vulnerable to the attack. It is likely that earlier versions of the server are vulnerable, too.
The problem appears to be that OpenSSL has already allowed invalid reads by the time that FreeRADIUS detects the invalid heartbeat, and closes the connection. The benefit of the way FreeRADIUS uses OpenSSL is that the attack appears to be limited to reading ~1K of data from the stack, when the server receives the malicious heartbeat. This limitation mitigates the attack, but does not remove the possibility of exposing private information.
We recommend that all administrators upgrade OpenSSL immediately.
Administrators can detect “heartbleed” attacks by looking in their
logs for a message containing the text
Invalid ACK received: 24.
If such a message is seen, it means that the attack has
been attempted. You should upgrade your version of
We suggest that all administrators upgrade all of their systems to a version of OpenSSL which is not vulnerable to this attack. Sites which allow random IPs to connect to a TLS server (e.g. SMTPS or HTTPS) should assume that all information available to those servers has been stolen from those systems. This information includes user credentials, keys for private certificates, cookies sent over HTTPS, etc.
We have updated FreeRADIUS (all versions) so that it refuses to start when it detects the vulnerable versions of OpenSSL.
v3.0.x - Administrators can over-ride this check by setting
allow_vulnerable_openssl = CVE-2014-0160 in the
subsection of radiusd.conf.
v2.2.x - Administrators can over-ride this check by setting
allow_vulnerable_openssl = yes in the
2012.04.19Versions of OpenSSL are vulnerable to malformed certificates
The CVE notification is CVE-2012-2110.
We recommend all administrators using certificates with FreeRADIUS upgrade their OpenSSL to a secure version. For details, see the OpenSSL notification
We emphasize that this is not a bug in FreeRADIUS. FreeRADIUS uses OpenSSL for many of it’s cryptographic operations, and as such, is at the mercy of any problems in OpenSSL.
2008.05.13SSL keys may be guessable
We recommend that administrators using OpenSSL on Debian or Ubuntu upgrade immediately. We also recommend re-generating any SSL certificates used in RADIUS systems, if those certificates were created on a Debian or Ubuntu system since 2006.
We emphasize that this is not a bug in FreeRADIUS. FreeRADIUS uses OpenSSL for many of it’s cryptographic operations, and as such, is at the mercy of any problems in OpenSSL.
All input is sanity-checked before use.
There are no C compiler warnings in the build. Builds performed by developers have -Werror set, so that new errors are not introduced.
Builds with multiple compilers
We use GCC and CLANG for all builds. Each compiler produces a slightly different set of warnings. As seen above, no warnings from any compiler are allowed in the build.
Builds on multiple operating systems
We always build on Mac OSX and Ubuntu. We are in the process of adding FreeBSD and CentOS.
Builds are done with every single module, and multiple feature permutations
There is no portion of the server which has "code rot" because it has not been built for years.
The src/tests/ directory has a growing set of tests for server functionality. These tests help ensure that new commits do not accidentally break existing functionality
Commits are built and tested via travis
Static analysis (3X!)
Builds are performed weekly with Coverity. Builds are performed daily with Clang static analyzer and cppcheck. The server must build with no errors before it can be released.
These practices are not perfect. The test suite is growing, but it does not cover all of the servers functionality. As a result, the latest releases may still have bugs. Version 2 is "end of life" (EOL), and has new releases only when security issues mandate it. Version 3 is the "long term support" stable release. New releases are limited to bug fixes and minor new features. The git "master" branch will become version 4 at some point, but is not yet available as a released version.