Clarification on WildFly's Security Policy and Support for Older Versions

[Magnus Grimsell]

Hi,

According to WildFly’s stated security policy:

"We aim to take immediate action to address serious security-related problems that involve our projects. Note that we will only fix such issues in the most recent minor release of WildFly."

This seems to imply that security fixes are only made available for the latest major version of WildFly. Is that correct?

Now that the project is part of the Commonhaus Foundation, has there been any discussion about extending security fix support to older major versions?

Such a change would be highly valuable for software vendors working under the requirements of the EU Cyber Resilience Act, where long-term patch availability is important for compliance.

Thanks in advance for any insights.

[Brian Stansberry]

Hi,

Our standard practice is to provide one bug fix release for each roughly quarterly feature release; thereafter to get fixes users would need to consume the next feature release. And, yes, these are typically major version releases.

Infrequently we may produce one or more additional bug fix releases beyond that, in order to address some particularly serious security issue.

Occasionally we discuss ways to provide at least a bit longer lifecycle for WildFly. The fundamental barrier to this is resources, particularly people who have the time and interest to do that kind of work. It takes a lot of work to support multiple release streams, and the WildFly project just doesn't have resources available to it to do that, particularly on a consistent basis where we could make commitments to our users. The move to Commonhaus hasn't changed this. Perhaps over time it will, if our being at Commonhaus encourages more participation and infrastructure funding. I question though whether new participants will want to devote their energies to maintaining old releases.

A second key barrier is the availability of fixes. WildFly depends on community projects for its hundreds of components, and we can only consume what those projects are willing to produce. If a fix for an issue is only available in a release that is incompatible with what is used in an older WildFly, we are stuck, unless we are willing to fork the project, which is rarely feasible. This fundamentally limits any kind of promises we could make about what could be fixed in an older release stream. It could only be a best-effort kind of thing.

Best regards,

Brian Stansberry

WildFly project lead