| Version | Date | Notes |
|---|---|---|
| 1.0.0 | 16 December 2013 | First version |
The following is a summary of the minimum requirements that need to be met for code contributions to be considered for the Joomla Framework.
a. Satisfy the Joomla! Coding Standards. Code submitted for merging must comply with the latest Coding Standards.
b. All existing automated tests must pass.
c. Provide automated tests for all new API classes and methods. Any new methods or classes added to the software API must be accompanied by passing Unit Tests to verify their correct behavior. This serves to help guarantee that not only the current code works, but that future changes do not cause an unstable master branch.
d. Provide basic documentation for changes and additions to the code software. Basic documentation must include thorough code Docblocks in the source code and API explanatory text in the README.md file.
Please refer to the CONTRIBUTING.markdown for the latest and any additional requirements.
The version identifiers for Joomla Framework follow a three level numerical convention as defined by the Semantic Versioning (2.0.0) specification in the form:
Major.Minor[.patch]
In summary:
a. Major releases indicate a break in backward compatibility.
b. Minor releases indicate the addition of new features or a significant change to existing features.
c. Patch releases indicate that bugs have been fixed.
There are four formal milestones in the life-cycle of software development:
a. Alpha. Alpha's indicate that there is new technology in the software ready for testing, but that the software is not feature complete. This type of release is not suitable for production environments.
b. Beta. Beta's are considered feature complete, but not yet stable enough for production environments. The software is intended to be tested thoroughly for regressions, security and stability problems.
c. Release Candidate (RC) Release candidates are considered complete and stable for production environments.
d. General Availability (GA) General availability software is considered stable for porduction environments.
The most recent minor release, including the first release of a new major series, is supported for a minimum of two (2) years, or until a minor release takes its place, whichever comes first.
When referrence is made to backward compatibility, this applies to, where applicable:
a. PHP code that is not private.
b. JavaScript functions and objects that are not private.
c. Database schema.
d. XML schema.
e. Language keys
Backward compatibility must be maintained between all minor and patch versions in the same major series. Where backward compatibility is introduced, a new major version of the software must be released.
Code can be marked for deprecation in any minor or patch release. Deprecated code is always removed in the next major version.
The team of developers and security experts tasked with implementing the Joomla Project Security Policy is the Joomla Security Strike Team (JSST). The JSST is tasked with investigating and responding to reported core vulnerabilities, executing core code reviews before software releases, providing a public presence regarding security issues, and helping the public to better understand Joomla security issues.
Joomla is a member of oCERT (along with a number of other security conscious software companies and organisations). Those reporting security issues may do so through oCERT or the JSST directly, but either way the JSST will make reasonable effort to work within the oCERT guidelines.
We appreciate the efforts of people finding and reporting bone fide issues but we encourage reporters to hold back information until Joomla releases a patched version of the software. Reporters that do so will be credited on the official vulnerability report.
The project does not disclose proof-of-concept information to demonstrate vulnerabilities and reporters are encouraged to do the same. Where a reporter feels strongly that proof-of-concept instructions should be published, they are encouraged to hold that information for an additional period of at least 4 weeks after the release of the patched version of the software.
The JSST will be available to answer questions and/or validate any Joomla security related articles at the publisher’s request.
Unless the threat level dictates otherwise, security patches will be rolled into the next available "release" of the software subject to oCERT guidelines and best practice.
There are two main details that contribute to a vulnerability’s priority or "threat level": impact and severity. The following tables provide generic guidelines for how vulnerabilities may be assessed. In practice each vulnerability will be assessed for damage potential and ranked accordingly.
| Level | Description |
|---|---|
| Critical | “0-day" attacks, and attacks where site control is compromised (allows attacker to take control over site). |
| High | SQL injection attacks, remote file include attacks, and other attack vectors where site data is compromised. |
| Moderate | XSS attacks, write ACL violations (editing or creating of content where not allowed). |
| Low | Read ACL violations (reading of content where not allowed). |
| Level | Description | Release Fix |
|---|---|---|
| Critical | VERY easy to perform. Relies on no outside information (TRUE 0-day attack). | As soon as possible |
| High | Moderately easy to perform. May rely on readily available outside information. | Per oCERT guidelines |
| Moderate | Not easy to perform. May rely on sensitive information. | Per oCERT guidelines |
| Low | Difficult to perform. Relies on sensitive information or requires special circumstances to perform. | Per oCERT guidelines |
Typo 2.3d, 2.5 reference, and 2.7.2 bona fide