nihilist/tor
1
0
Fork 0
mirror of https://gitlab.torproject.org/tpo/core/tor.git synced 2024-11-24 04:13:28 +01:00
Code Issues Packages Projects Releases Wiki Activity

doc(hacking): update = to # on sections

Browse Source
This commit is contained in:
Antoine Veuiller 2019-08-21 16:22:37 +02:00
parent 0d6c8eed49
commit 3bf90e704c
3 changed files with 15 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
doc/HACKING/EndOfLifeTor.md
View File

@ -7,7 +7,7 @@ series reaches End of Life. Note that they are _only_ for entire series that
have reached their planned EOL: they do not apply to security-related
deprecations of individual versions.
=== 0. Preliminaries
### 0. Preliminaries
0. A few months before End of Life:
Write a deprecation announcement.
@ -17,7 +17,7 @@ deprecations of individual versions.
Send the announcement to tor-announce, tor-talk, tor-relays, and the
packagers.
=== 1. On the day
### 1. On the day
1. Open tickets to remove the release from:
- the jenkins builds

14
doc/HACKING/Fuzzing.md
View File

@ -1,6 +1,6 @@
= Fuzzing Tor
# Fuzzing Tor
== The simple version (no fuzzing, only tests)
## The simple version (no fuzzing, only tests)
Check out fuzzing-corpora, and set TOR_FUZZ_CORPORA to point to the place
where you checked it out.
@ -12,7 +12,7 @@ This won't actually fuzz Tor! It will just run all the fuzz binaries
on our existing set of testcases for the fuzzer.
== Different kinds of fuzzing
## Different kinds of fuzzing
Right now we support three different kinds of fuzzer.
@ -37,7 +37,7 @@ In all cases, you'll need some starting examples to give the fuzzer when it
starts out. There's a set in the "fuzzing-corpora" git repository. Try
setting TOR_FUZZ_CORPORA to point to a checkout of that repository
== Writing Tor fuzzers
## Writing Tor fuzzers
A tor fuzzing harness should have:
* a fuzz_init() function to set up any necessary global state.
@ -52,7 +52,7 @@ bug, or accesses memory it shouldn't. This helps fuzzing frameworks detect
"interesting" cases.
== Guided Fuzzing with AFL
## Guided Fuzzing with AFL
There is no HTTPS, hash, or signature for American Fuzzy Lop's source code, so
its integrity can't be verified. That said, you really shouldn't fuzz on a
@ -101,7 +101,7 @@ macOS (OS X) requires slightly more preparation, including:
* using afl-clang (or afl-clang-fast from the llvm directory)
* disabling external crash reporting (AFL will guide you through this step)
== Triaging Issues
## Triaging Issues
Crashes are usually interesting, particularly if using AFL_HARDEN=1 and --enable-expensive-hardening. Sometimes crashes are due to bugs in the harness code.
@ -115,7 +115,7 @@ To see what fuzz-http is doing with a test case, call it like this:
(Logging is disabled while fuzzing to increase fuzzing speed.)
== Reporting Issues
## Reporting Issues
Please report any issues discovered using the process in Tor's security issue
policy:

12
doc/HACKING/ReleasingTor.md
View File

@ -5,7 +5,7 @@ Putting out a new release
Here are the steps that the maintainer should take when putting out a
new Tor release:
=== 0. Preliminaries
### 0. Preliminaries
1. Get at least two of weasel/arma/Sebastian to put the new
version number in their approved versions list. Give them a few
@ -18,7 +18,7 @@ new Tor release:
date of a TB that contains it. See note below in "commit, upload,
announce".
=== I. Make sure it works
### I. Make sure it works
1. Make sure that CI passes: have a look at Travis
(https://travis-ci.org/torproject/tor/branches), Appveyor
@ -52,7 +52,7 @@ new Tor release:
memory leaks.)
=== II. Write a changelog
### II. Write a changelog
1a. (Alpha release variant)
@ -139,7 +139,7 @@ new Tor release:
text of existing entries, though.)
=== III. Making the source release.
### III. Making the source release.
1. In `maint-0.?.x`, bump the version number in `configure.ac` and run
`make update-versions` to update version numbers in other
@ -165,7 +165,7 @@ new Tor release:
If it is not, you'll need to poke Roger, Weasel, and Sebastian again: see
item 0.1 at the start of this document.
=== IV. Commit, upload, announce
### IV. Commit, upload, announce
1. Sign the tarball, then sign and push the git tag:
@ -241,7 +241,7 @@ new Tor release:
For templates to use when announcing, see:
https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/AnnouncementTemplates
=== V. Aftermath and cleanup
### V. Aftermath and cleanup
1. If it's a stable release, bump the version number in the
`maint-x.y.z` branch to "newversion-dev", and do a `merge -s ours`