You are looking at historical revision 28073 of this page. It may differ significantly from its current revision.
NOTE: This is still a draft document. It is subject to (possibly drastic) change.
CHICKEN Security Policy
This documents describes our approach to security problems. If you have found a security issue, we'd appreciate it if you try to stick as closely as possible to the documented approach. This allows us to fix and report the issue in a controlled manner.
The documentation below describes the typical stages in the reporting and resolution of security issues. It relies heavily on the idea of responsible disclosure, which is a constructive and ethical approach towards security issues. It involves an equal amount of responsibility on the part of the researcher (you) as well as the "vendor" (us; the project).
Your responsibility is to report the vulnerability to us, and to keep it a secret to the outside world for a period of time. Publishing a vulnerability before we've had a chance to patch it is unfair, uncool and loses you considerable karma points. Disclosing it responsibly, however, will make you a hero and earn you massive respect from the community (and of course credits in our security advisory!). More seriously, by keeping issues secret while unfixed (hopefully) prevents them from becoming known more widely and being exploited "in the wild".
Our responsibility is to fix the problem as soon as possible and to be as open as possible about it while causing the least amount of harm. This involves keeping you in the loop about our progress and publishing a detailed security advisory with information about the bug. Being open about issues ensures that adminstrators can make an informed decision about whether they're affected and whether to roll out a patch on all their systems, and it allows others to learn from our mistakes.
If everyone follows these rules, bugs still get fixed quickly and people can learn from eachother, leading to a higher level of security awareness.
Finding an issue and collecting info
Whenever you believe you've found a security issue, please ensure that it's present in the latest stable release. The latest stable release has either a x.y.0 or x.y.0.z version number and should be mentioned on the main web site or the code sub site as being the latest release.
If you find a security issue in an older version which is not present in the latest version, please check the NEWS file. If it is not listed as being fixed, we'd still appreciate a report along with a note in which version you found the bug.
When you've confirmed it's in the latest version, please try to spend some time cooking up a simple proof of concept or test case with which we can reproduce the issue. If you have a hard time making a test case, you can gather some pointers to documentation explaining the issue or write up an explanation yourself. Of course, a patch would be much appreciated but this is not absolutely required.
Rationale: This saves time for everyone. If you find a bug that's already fixed and reported, you can save yourself the time of composing an e-mail and producing a proof of concept/test case. For us it means less stress and time spent attempting to reproduce the issue in the version where it's fixed.
Including as much information as you can will make it easier for us to understand the bug, so we can come up with a fix sooner. Otherwise we'll have to contact you again for more details, which takes more time.
Reporting the issue
Once you're verified the issue you've found is really a security issue and created a test case and/or patch, it's time to notify the CHICKEN security team. But please keep it a secret to everyone else!
You can contact us via the chicken-security address. We will attempt to acknowledge receipt of the issue as soon as possible. Our project is volunteer-driven, so please cut us some slack ;)
This address corresponds to a moderated mailinglist, so your mail might get stuck in a moderation queue. If you don't receive a reply within 2 or 3 days, please contact one or two core members directly or ask in #chicken on Freenode (don't mention any details; just say you're wondering about an e-mail sent to chicken-security). Include the message-ID and From-address if possible, this may help us find your mail more quickly.
Normally we will request a CVE identifier (see below), but if you already have one, please include it in your mail to prevent duplicates.
If you prefer to stay anonymous (or want to use a pseudonym), please let us know. We will take this into account when writing an advisory's credits section.
Rationale: By mailing to us and keeping the issue under embargo, we can figure out the cause and a build fix for the issue before it becomes general public knowledge and exploited in the wild.
Response from the CHICKEN team
After receiving your report we will attempt to reproduce the problem, figure out which versions are affected and audit the rest of the code for other similar issues. Then we will write a patch (or apply yours). While working on a patch we may contact you for further information or feedback.
Once the patch is applied, we'll write a security advisory and send it to chicken-users and chicken-announce. Of course you will be duly credited, as a way to acknowledge your valuable work in helping us improve CHICKEN! The advisory will include details about the nature of the problem (including links to further reading material), ways to determine whether an installation is affected and any known mitigations or workarounds, if applicable.
The person responsible for issuing the advisory will also take care of requesting a CVE identifier unless you already got one assigned. Once assigned, the CVE identifier will be posted to the mailinglist in a follow-up. The CVE-request will be sent to the oss-security mailinglist, with a short description of the issue and a link to the advisory from the chicken-users archive.
Depending on the complexity of the fix and the security impact of the issue, the CHICKEN Team will decide whether to publish a new point release in the stable branch. This will be done either immediately or soon after issuing an advisory. If at all practical it will be done before.
After the advisory is made public, the embargo period is formally over and we encourage you to publish more detailed information about the issue and how you've found it as a way of educating the wider developer community.
Rationale: When many people are relying on the stability and security of a system, there exists some tension. On one hand, we want to make sure security issues get fixed in a release version as soon as possible so that everyone can secure their system. On the other hand, we don't want to break anyone's critical systems. This means any security fixes must be released soon but ideally they are well-tested before doing so. Of course, the longer you wait the higher the chances the bug will be exploited in the wild.
We will always give credit to encourage people from sharing their findings with us in the future. We will also try to include detailed information about vulnerabilities to inform others, to increase the overall state of security in field of software.
Keeping advised about security issues
As outlined above, when a security issue is found and fixed, it will lead to a release as soon as possible, within limits. All issues are published in security advisories, which are posted to chicken-users and chicken-announce.
The latter list is low-volume and will only have announcements posted to it (including security announcements, of course).