Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2022-11-03T12:16:08Zhttps://gitlab.torproject.org/legacy/trac/-/issues/13968Document a metaproject security policy2022-11-03T12:16:08ZTracDocument a metaproject security policyConsidering the year of heartbleed, shell shock, and POODLE exploits, as well as internal vulnerabilities and high profile attention catchers, a security page might help folks in tricky situations determine if their Tor component is secu...Considering the year of heartbleed, shell shock, and POODLE exploits, as well as internal vulnerabilities and high profile attention catchers, a security page might help folks in tricky situations determine if their Tor component is secure. Right now security advisories are published on the blog and there's no formal maintenance window.
As with #13966 (exploit reporting), it might be useful to study [FreeBSD security information](http://www.freebsd.org/security/) and pick out the parts we'd like to apply.
**Trac**:
**Username**: michaelhttps://gitlab.torproject.org/legacy/trac/-/issues/13966Publish guidelines for reporting exploits2020-06-15T23:22:43ZTracPublish guidelines for reporting exploitsThere exists no easy to find documentation (on the wiki nor elsewhere) that advises how to report a suspected Tor (proxy, browser, bundle, transport...) exploit. And no search on keyservers shows up a 'security' key for a tor-sec@torproj...There exists no easy to find documentation (on the wiki nor elsewhere) that advises how to report a suspected Tor (proxy, browser, bundle, transport...) exploit. And no search on keyservers shows up a 'security' key for a tor-sec@torproject.org or similar account.
A blueprint for working this task could be: Just figure out how we've been handling exploit reporting in the past (tor-assistants@ maybe?) and make sure it's a consensus, and write it down in the wiki.
**Trac**:
**Username**: michaelTor: 0.3.1.x-final