source: project/wiki/security @ 36118

Last change on this file since 36118 was 33589, checked in by sjamaan, 4 years ago

Summary: Fix a few spelling mistakes and change http: to https: where possible. Thanks to Sander Bos for reporting these.

  • Property svnwiki:authenticate set to yes
  • Property svnwiki:frozen set to yes
File size: 8.0 KB
Line 
1[[toc:]]
2
3== CHICKEN Security Policy
4
5This documents describes our approach to security problems.  If you
6have found a security issue, we'd appreciate it if you try to stick as
7closely as possible to the documented approach.  This allows us to fix
8and report the issue in a controlled manner.
9
10The documentation below describes the typical stages in the reporting
11and resolution of security issues.  It relies heavily on the idea of
12[[https://en.wikipedia.org/wiki/Responsible_disclosure|responsible disclosure]],
13which is a ''constructive and ethical'' approach towards security issues.
14It involves an equal amount of responsibility on the part of the
15researcher (you) as well as the "vendor" (us; the project).
16
17Your responsibility is to report the vulnerability to us, and to keep
18it a secret to the outside world for a period of time.  Publishing a
19vulnerability before we've had a chance to patch it is unfair, uncool
20and loses you considerable karma points.  Disclosing it responsibly,
21however, will make you a hero and earn you massive respect from the
22community (and of course credits in our security advisory!).  More
23seriously, keeping issues secret while unfixed (hopefully) prevents
24them from becoming known more widely and being exploited "in the
25wild".
26
27Our responsibility is to fix the problem as soon as possible and to be
28as open as possible about it while causing the least amount of harm.
29This involves keeping you in the loop about our progress and
30publishing a detailed security advisory with information about the
31bug.  Being open about issues ensures that administrators can make an
32informed decision about whether they're affected and whether to roll
33out a patch on all their systems, and it allows others to learn from
34our mistakes.
35
36If everyone follows these rules, bugs still get fixed quickly and
37people can learn from each other, leading to a higher level of
38security awareness.
39
40=== Finding an issue and collecting info
41
42Whenever you believe you've found a security issue, please ensure that
43it's present in the latest ''stable'' release.  The latest stable
44release has either an {{x.y.0}} or {{x.y.0.z}} version number and
45should be mentioned on the main [[https://www.call-cc.org|web site]] or
46the [[https://code.call-cc.org|code sub site]] as being the latest release.
47
48If you find a security issue in an older version which is not present
49in the latest version, please check the {{NEWS}} file.  If it is not
50listed as being fixed, we'd still appreciate a report along with a
51note in which version you found the bug.
52
53When you've confirmed it's in the latest version, please try to spend
54some time cooking up a simple proof of concept or test case with which
55we can reproduce the issue.  If you have a hard time making a test case,
56you can gather some pointers to documentation explaining the issue or
57write up an explanation yourself.  Of course, a patch would be much
58appreciated but this is not absolutely required.
59
60'''Rationale''': This saves time for everyone.  If you find a bug
61that's already fixed and reported, you can save yourself the time of
62composing an e-mail and producing a proof of concept/test case.  For
63us it means less stress and time spent attempting to reproduce the
64issue in the version where it's fixed.
65
66Including as much information as you can will make it easier for us to
67understand the bug, so we can come up with a fix sooner.  Otherwise
68we'll have to contact you again for more details, which takes more
69time.
70
71=== Reporting the issue
72
73Once you're verified the issue you've found is really a security issue
74and created a test case and/or patch, it's time to notify the CHICKEN
75security team.  But please keep it a secret to everyone else!
76
77You can contact us via the
78[[https://lists.nongnu.org/mailman/listinfo/chicken-vulnerabilities|chicken-vulnerabilities]]
79address.  We will attempt to acknowledge receipt of the issue as soon
80as possible.  Our project is volunteer-driven, so please cut us some
81slack ;)
82
83This address corresponds to a moderated mailing list, so your mail
84might get stuck in a moderation queue.  If you don't receive a reply
85within 2 or 3 days, please contact one or two core members directly or
86ask in #chicken on Freenode (don't mention any details; just say
87you're wondering about an e-mail sent to {{chicken-security}}).
88Include the message-ID and From-address if possible, this may help us
89find your mail more quickly.
90
91Normally we will request a CVE identifier (see below), but if you
92already have one, please include it in your mail to prevent
93duplicates.
94
95If you prefer to stay anonymous (or want to use a pseudonym), please
96let us know.  We will take this into account when writing an
97advisory's credits section.
98
99'''Rationale''': By mailing to us and keeping the issue under embargo,
100we can figure out the cause and a build fix for the issue before it
101becomes general public knowledge and exploited in the wild.
102
103=== Response from the CHICKEN team
104
105After receiving your report we will attempt to reproduce the problem,
106figure out which versions are affected and audit the rest of the code
107for other similar issues.  Then we will write a patch (or apply
108yours).  While working on a patch we may contact you for further
109information or feedback.
110
111Once the patch is applied, we'll write a security advisory and send it
112to [[https://lists.nongnu.org/mailman/listinfo/chicken-users|chicken-users]]
113and [[https://lists.nongnu.org/mailman/listinfo/chicken-announce|chicken-announce]].
114Of course you will be duly credited, as a way to acknowledge
115your valuable work in helping us improve CHICKEN!  The advisory will
116include details about the nature of the problem (including links to
117further reading material), ways to determine whether an installation is
118affected and any known mitigations or workarounds, if applicable.
119
120The person responsible for issuing the advisory will also take care
121of requesting a [[https://cve.mitre.org/about/index.html|CVE]]
122identifier unless you already got one assigned.  Once assigned, the
123CVE identifier will be posted to the mailing list in a follow-up.
124The CVE-request will be sent to
125[[http://oss-security.openwall.org/wiki/mailing-lists/oss-security|the oss-security mailing list]],
126with a short description of the issue and a link to the advisory from the
127[[https://lists.nongnu.org/archive/html/chicken-users/|chicken-users archive]].
128
129Depending on the complexity of the fix and the security impact of the
130issue, the CHICKEN Team will decide whether to publish a new point
131release in the stable branch.  This will be done either immediately
132or soon after issuing an advisory.  If at all practical it will be
133done before.
134
135After the advisory is made public, the embargo period is formally over
136and we encourage you to publish more detailed information about the
137issue and how you've found it as a way of educating the wider
138developer community.
139
140'''Rationale''': When many people are relying on the stability and
141security of a system, there exists some tension.  On the one hand, we
142want to make sure security issues get fixed in a release version as
143soon as possible so that everyone can secure their system.  On the
144other hand, we don't want to break anyone's critical systems.  This
145means any security fixes must be released soon but ideally they are
146well-tested before doing so.  Of course, the longer you wait the
147higher the chances the bug will be exploited in the wild.
148
149We will always give credit to encourage people from sharing their
150findings with us in the future.  We will also try to include detailed
151information about vulnerabilities to inform others, to increase the
152overall state of security in the field of software.
153
154=== Keeping advised about security issues
155
156As outlined above, when a security issue is found and fixed, it will
157lead to a release as soon as possible, within limits.  All issues
158are published in security advisories, which are posted to
159[[https://lists.nongnu.org/mailman/listinfo/chicken-users|chicken-users]]
160and [[https://lists.nongnu.org/mailman/listinfo/chicken-announce|chicken-announce]].
161
162The latter list is low-volume and will only have announcements posted
163to it (including security announcements, of course).
Note: See TracBrowser for help on using the repository browser.