Forthcoming changes to the Exim Project contribution, security reporting and release procedures.
We are updating our contribution, security reporting and release procedures to better align with the new landscape of development and reporting.
These will be incorporated into the appropriate document locations in due course.
----
Contributing
As a mature project we do not expect major changes in the current codebase. Most changes are likely to be limited to security/bug fixes, refactoring for code consistency and very occasionally new capabilities to accomodate new standards (example as of today being the forthcoming DKIM2 specification).
Any sizeable contribution will be considered not only in respect to its conformity with current project standards but also in terms of whether the project developers consider the ongoing maintenance burden to be acceptable.
With this in mind we would ask you follow the following steps to contribute.
* Start by checking and discussing via the exim-user mailing list whether we would consider the feature.
* If we approve an suitable ticket will be created to track the specifics.
* We do not accept LLM generated content in any form whatsoever.
----
Security Reports
* We only accept reports against the latest release.
* Reports should be limited to succinct descriptions of the problem, with minimal code inclusion.
* Reports where EXPERIMENTAL builds flags are used must be filed as ordinary bugs and are not considered security issues.
* Reports against isolated source files builds are not accepted. Only reports against the full binary are considered.
* Do not include Proof of Concepts
* Do not include suggested patches.
* Do not include extended diatribes about code flow.
* Reports we believe are LLM generated will either be rejected outright or if thought to be plausible will be credited to the unnamed and uncredited authors whose works were ingested as the training corpus.
* Reports that do not meet the criteria for security issues but are merely bugs will be turned into normal public issues.
* If we do determine there is a security issue then we will release an update on the relevant branch as soon as there is a tested fix. Each issue will be allocated a GCVE identifier against our GNA ID, we will no longer be using legacy CVE IDs.
----
Release Procedures
We will be changing some of our release procedures. Starting with 4.100 we will change to releasing only 4.yy and 4.yy.zz releases on the master branch.
Intermediate work such as general bug fixing and feature enhancement will move to the 4.next branch.
We will endeavour to apply any .zz security fixes to the 4.next branch in a timely manner though there may be some lag.
Release candidates for 4.yy+1 will be tagged on the 4.next branch.
----
These changes will allow us to allocate our limited resources more efficiently within the current environment. Whilst we might fine-tune some of these changes we will not envisage any significant changes.