Reporting Bugs and Security Bugs FAQ

Q: How do I report a bug?

The first step is to search Issue Tracker to see if the problem has already been reported. Anyone can search the database but, if you don't find a report for your issue, you must register as a user. See the Governance for more information or click Join on the navigation bar.

Q: Is reporting a security bug different?

Yes, security bugs are treated as a matter of absolute urgency so handling a security vulnerability is different from handling any other kind of bug. The bug report cannot be submitted through the regular channels as the objective is to analyze and fix the bug in secrecy, announcing the existence of the bug and its fix concurrently.

Q: How do I report a security bug?

Security bugs are submitted to a private security team alias outside the java.net infrastructure since it is not possible to restrict a java.net mailing list archive to a tight group of subscribers. The security team email address is:

opensso-sec-bugs-ext@sun.com

Subscription to the security bug alias and its archive will be tightly restricted to a small security team. At the project's inception, the security team will comprise only Module Owners.

And remember, only security bugs should be sent to the security team alias.

Q: How do I know if it is a security bug?

You might not know. There is the assumption that people will send other bugs to the alias, either deliberately, to circumvent the regular process, or mistakenly, believing a real security bug has been found. The security team will discuss the submitted bug and its relevance using the private security team alias (opensso-sec-bugs-ext@sun.com). After a consensus has been reached, a member of the security team may reply to the submitter with a pro forma response, directing them to submit the bug to Issue Tracker using the non-security bug process.

Q: What are the criteria for evaluating a security bug?

The next task after conceding the receipt of a valid security bug is for the security team to evaluate its severity:

1. How serious is the vulnerability?
   • Critical: the bug can lead to arbitrary code execution.
   • Severe: the bug can compromise confidentiality, integrity or availability of resources.
   • Moderate: anything else - for example, the bug exposes operational information such as number of active sessions.
2. How easy is it to exploit the vulnerability? Is a scripted attack possible? Must the attacker successfully authenticate as a regular user before initiating an attack?
3. Who reported the issue? A report from a source outside the project is treated with even more urgency than one from an internal engineer.

Q: Should we put the bug on the Common Vulnerabilities and Exposures (CVE) list?

CVE is a list of standardized names for vulnerabilities and other information security exposures. It aims to standardize the names for all publicly known vulnerabilities and security exposures. CVE names (also called CVE numbers, CVE-IDs, or CVEs) are unique, common identifiers for publicly known information security vulnerabilities. CVE names have entry or candidate status. Entry status indicates that the CVE name has been accepted to the CVE list. Candidate status (also called candidates, candidate numbers, or CANs) indicates that the name is under review for inclusion to the list.

Q: What is the process for fixing a security bug?

1. Work on the fix must proceed as quietly as possible, with discussion restricted to members of the security team. Code reviews will be performed as usual with the audience restricted to the security team.
2. Once a fix has been produced and tested, important users will be pre-notified. These users will be allowed to apply the patch before the bug becomes public knowledge.
3. The bug and the fix must be announced and made available simultaneously (or as close to simultaneous as possible).