HACKING 22 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623
  1. Hacking Tor: An Incomplete Guide
  2. ================================
  3. Getting started
  4. ---------------
  5. For full information on how Tor is supposed to work, look at the files in
  6. https://gitweb.torproject.org/torspec.git/tree
  7. For an explanation of how to change Tor's design to work differently, look at
  8. https://gitweb.torproject.org/torspec.git/blob_plain/HEAD:/proposals/001-process.txt
  9. For the latest version of the code, get a copy of git, and
  10. git clone https://git.torproject.org/git/tor
  11. We talk about Tor on the tor-talk mailing list. Design proposals and
  12. discussion belong on the tor-dev mailing list. We hang around on
  13. irc.oftc.net, with general discussion happening on #tor and development
  14. happening on #tor-dev.
  15. How we use Git branches
  16. -----------------------
  17. Each main development series (like 0.2.1, 0.2.2, etc) has its main work
  18. applied to a single branch. At most one series can be the development series
  19. at a time; all other series are maintenance series that get bug-fixes only.
  20. The development series is built in a git branch called "master"; the
  21. maintenance series are built in branches called "maint-0.2.0", "maint-0.2.1",
  22. and so on. We regularly merge the active maint branches forward.
  23. For all series except the development series, we also have a "release" branch
  24. (as in "release-0.2.1"). The release series is based on the corresponding
  25. maintenance series, except that it deliberately lags the maint series for
  26. most of its patches, so that bugfix patches are not typically included in a
  27. maintenance release until they've been tested for a while in a development
  28. release. Occasionally, we'll merge an urgent bugfix into the release branch
  29. before it gets merged into maint, but that's rare.
  30. If you're working on a bugfix for a bug that occurs in a particular version,
  31. base your bugfix branch on the "maint" branch for the first supported series
  32. that has that bug. (As of June 2013, we're supporting 0.2.3 and later.) If
  33. you're working on a new feature, base it on the master branch.
  34. How we log changes
  35. ------------------
  36. When you do a commit that needs a ChangeLog entry, add a new file to
  37. the "changes" toplevel subdirectory. It should have the format of a
  38. one-entry changelog section from the current ChangeLog file, as in
  39. o Major bugfixes:
  40. - Fix a potential buffer overflow. Fixes bug 99999; bugfix on
  41. 0.3.1.4-beta.
  42. To write a changes file, first categorize the change. Some common categories
  43. are: Minor bugfixes, Major bugfixes, Minor features, Major features, Code
  44. simplifications and refactoring. Then say what the change does. If
  45. it's a bugfix, mention what bug it fixes and when the bug was
  46. introduced. To find out which Git tag the change was introduced in,
  47. you can use "git describe --contains <sha1 of commit>".
  48. If at all possible, try to create this file in the same commit where you are
  49. making the change. Please give it a distinctive name that no other branch will
  50. use for the lifetime of your change. To verify the format of the changes file,
  51. you can use "make check-changes".
  52. When we go to make a release, we will concatenate all the entries
  53. in changes to make a draft changelog, and clear the directory. We'll
  54. then edit the draft changelog into a nice readable format.
  55. What needs a changes file?::
  56. A not-exhaustive list: Anything that might change user-visible
  57. behavior. Anything that changes internals, documentation, or the build
  58. system enough that somebody could notice. Big or interesting code
  59. rewrites. Anything about which somebody might plausibly wonder "when
  60. did that happen, and/or why did we do that" 6 months down the line.
  61. Why use changes files instead of Git commit messages?::
  62. Git commit messages are written for developers, not users, and they
  63. are nigh-impossible to revise after the fact.
  64. Why use changes files instead of entries in the ChangeLog?::
  65. Having every single commit touch the ChangeLog file tended to create
  66. zillions of merge conflicts.
  67. Useful tools
  68. ------------
  69. These aren't strictly necessary for hacking on Tor, but they can help track
  70. down bugs.
  71. Jenkins
  72. ~~~~~~~
  73. https://jenkins.torproject.org
  74. Dmalloc
  75. ~~~~~~~
  76. The dmalloc library will keep track of memory allocation, so you can find out
  77. if we're leaking memory, doing any double-frees, or so on.
  78. dmalloc -l ~/dmalloc.log
  79. (run the commands it tells you)
  80. ./configure --with-dmalloc
  81. Valgrind
  82. ~~~~~~~~
  83. valgrind --leak-check=yes --error-limit=no --show-reachable=yes src/or/tor
  84. (Note that if you get a zillion openssl warnings, you will also need to
  85. pass --undef-value-errors=no to valgrind, or rebuild your openssl
  86. with -DPURIFY.)
  87. Coverity
  88. ~~~~~~~~
  89. Nick regularly runs the coverity static analyzer on the Tor codebase.
  90. The preprocessor define __COVERITY__ is used to work around instances
  91. where coverity picks up behavior that we wish to permit.
  92. clang Static Analyzer
  93. ~~~~~~~~~~~~~~~~~~~~~
  94. The clang static analyzer can be run on the Tor codebase using Xcode (WIP)
  95. or a command-line build.
  96. The preprocessor define __clang_analyzer__ is used to work around instances
  97. where clang picks up behavior that we wish to permit.
  98. clang Runtime Sanitizers
  99. ~~~~~~~~~~~~~~~~
  100. To build the Tor codebase with the clang Address and Undefined Behavior
  101. sanitizers, see the file contrib/clang/sanitize_blacklist.txt.
  102. Preprocessor workarounds for instances where clang picks up behavior that
  103. we wish to permit are also documented in the blacklist file.
  104. Running lcov for unit test coverage
  105. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  106. Lcov is a utility that generates pretty HTML reports of test code coverage.
  107. To generate such a report:
  108. -----
  109. ./configure --enable-coverage
  110. make
  111. make coverage-html
  112. $BROWSER ./coverage_html/index.html
  113. -----
  114. This will run the tor unit test suite `./src/test/test` and generate the HTML
  115. coverage code report under the directory ./coverage_html/. To change the
  116. output directory, use `make coverage-html HTML_COVER_DIR=./funky_new_cov_dir`.
  117. Coverage diffs using lcov are not currently implemented, but are being
  118. investigated (as of July 2014).
  119. Running the unit tests
  120. ~~~~~~~~~~~~~~~~~~~~~~
  121. To quickly run all tests:
  122. -----
  123. make check
  124. -----
  125. To run unit tests only:
  126. -----
  127. make test
  128. -----
  129. To selectively run just some tests (the following can be combined
  130. arbitrarily):
  131. -----
  132. ./src/test/test <name_of_test> [<name of test 2>] ...
  133. ./src/test/test <prefix_of_name_of_test>.. [<prefix_of_name_of_test2>..] ...
  134. ./src/test/test :<name_of_excluded_test> [:<name_of_excluded_test2]...
  135. -----
  136. Running gcov for unit test coverage
  137. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  138. -----
  139. ./configure --enable-coverage
  140. make
  141. make check
  142. mkdir coverage-output
  143. ./scripts/test/coverage coverage-output
  144. -----
  145. (On OSX, you'll need to start with "--enable-coverage CC=clang".)
  146. Then, look at the .gcov files in coverage-output. '-' before a line means
  147. that the compiler generated no code for that line. '######' means that the
  148. line was never reached. Lines with numbers were called that number of times.
  149. If that doesn't work:
  150. * Try configuring Tor with --disable-gcc-hardening
  151. * You might need to run 'make clean' after you run './configure'.
  152. If you make changes to Tor and want to get another set of coverage results,
  153. you can run "make reset-gcov" to clear the intermediary gcov output.
  154. If you have two different "coverage-output" directories, and you want to see
  155. a meaningful diff between them, you can run:
  156. -----
  157. ./scripts/test/cov-diff coverage-output1 coverage-output2 | less
  158. -----
  159. In this diff, any lines that were visited at least once will have coverage
  160. "1". This lets you inspect what you (probably) really want to know: which
  161. untested lines were changed? Are there any new untested lines?
  162. Running integration tests
  163. ~~~~~~~~~~~~~~~~~~~~~~~~~
  164. We have the beginnings of a set of scripts to run integration tests using
  165. Chutney. To try them, set CHUTNEY_PATH to your chutney source directory, and
  166. run "make test-network".
  167. Profiling Tor with oprofile
  168. ~~~~~~~~~~~~~~~~~~~~~~~~~~~
  169. The oprofile tool runs (on Linux only!) to tell you what functions Tor is
  170. spending its CPU time in, so we can identify berformance pottlenecks.
  171. Here are some basic instructions
  172. - Build tor with debugging symbols (you probably already have, unless
  173. you messed with CFLAGS during the build process).
  174. - Build all the libraries you care about with debugging symbols
  175. (probably you only care about libssl, maybe zlib and Libevent).
  176. - Copy this tor to a new directory
  177. - Copy all the libraries it uses to that dir too (ldd ./tor will
  178. tell you)
  179. - Set LD_LIBRARY_PATH to include that dir. ldd ./tor should now
  180. show you it's using the libs in that dir
  181. - Run that tor
  182. - Reset oprofiles counters/start it
  183. * "opcontrol --reset; opcontrol --start", if Nick remembers right.
  184. - After a while, have it dump the stats on tor and all the libs
  185. in that dir you created.
  186. * "opcontrol --dump;"
  187. * "opreport -l that_dir/*"
  188. - Profit
  189. Coding conventions
  190. ------------------
  191. Patch checklist
  192. ~~~~~~~~~~~~~~~
  193. If possible, send your patch as one of these (in descending order of
  194. preference)
  195. - A git branch we can pull from
  196. - Patches generated by git format-patch
  197. - A unified diff
  198. Did you remember...
  199. - To build your code while configured with --enable-gcc-warnings?
  200. - To run "make check-spaces" on your code?
  201. - To run "make check-docs" to see whether all new options are on
  202. the manpage?
  203. - To write unit tests, as possible?
  204. - To base your code on the appropriate branch?
  205. - To include a file in the "changes" directory as appropriate?
  206. Whitespace and C conformance
  207. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  208. Invoke "make check-spaces" from time to time, so it can tell you about
  209. deviations from our C whitespace style. Generally, we use:
  210. - Unix-style line endings
  211. - K&R-style indentation
  212. - No space before newlines
  213. - A blank line at the end of each file
  214. - Never more than one blank line in a row
  215. - Always spaces, never tabs
  216. - No more than 79-columns per line.
  217. - Two spaces per indent.
  218. - A space between control keywords and their corresponding paren
  219. "if (x)", "while (x)", and "switch (x)", never "if(x)", "while(x)", or
  220. "switch(x)".
  221. - A space between anything and an open brace.
  222. - No space between a function name and an opening paren. "puts(x)", not
  223. "puts (x)".
  224. - Function declarations at the start of the line.
  225. We try hard to build without warnings everywhere. In particular, if you're
  226. using gcc, you should invoke the configure script with the option
  227. "--enable-gcc-warnings". This will give a bunch of extra warning flags to
  228. the compiler, and help us find divergences from our preferred C style.
  229. Getting emacs to edit Tor source properly
  230. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  231. Nick likes to put the following snippet in his .emacs file:
  232. -----
  233. (add-hook 'c-mode-hook
  234. (lambda ()
  235. (font-lock-mode 1)
  236. (set-variable 'show-trailing-whitespace t)
  237. (let ((fname (expand-file-name (buffer-file-name))))
  238. (cond
  239. ((string-match "^/home/nickm/src/libevent" fname)
  240. (set-variable 'indent-tabs-mode t)
  241. (set-variable 'c-basic-offset 4)
  242. (set-variable 'tab-width 4))
  243. ((string-match "^/home/nickm/src/tor" fname)
  244. (set-variable 'indent-tabs-mode nil)
  245. (set-variable 'c-basic-offset 2))
  246. ((string-match "^/home/nickm/src/openssl" fname)
  247. (set-variable 'indent-tabs-mode t)
  248. (set-variable 'c-basic-offset 8)
  249. (set-variable 'tab-width 8))
  250. ))))
  251. -----
  252. You'll note that it defaults to showing all trailing whitespace. The "cond"
  253. test detects whether the file is one of a few C free software projects that I
  254. often edit, and sets up the indentation level and tab preferences to match
  255. what they want.
  256. If you want to try this out, you'll need to change the filename regex
  257. patterns to match where you keep your Tor files.
  258. If you use emacs for editing Tor and nothing else, you could always just say:
  259. -----
  260. (add-hook 'c-mode-hook
  261. (lambda ()
  262. (font-lock-mode 1)
  263. (set-variable 'show-trailing-whitespace t)
  264. (set-variable 'indent-tabs-mode nil)
  265. (set-variable 'c-basic-offset 2)))
  266. -----
  267. There is probably a better way to do this. No, we are probably not going
  268. to clutter the files with emacs stuff.
  269. Functions to use
  270. ~~~~~~~~~~~~~~~~
  271. We have some wrapper functions like tor_malloc, tor_free, tor_strdup, and
  272. tor_gettimeofday; use them instead of their generic equivalents. (They
  273. always succeed or exit.)
  274. You can get a full list of the compatibility functions that Tor provides by
  275. looking through src/common/util.h and src/common/compat.h. You can see the
  276. available containers in src/common/containers.h. You should probably
  277. familiarize yourself with these modules before you write too much code, or
  278. else you'll wind up reinventing the wheel.
  279. Use 'INLINE' instead of 'inline', so that we work properly on Windows.
  280. Calling and naming conventions
  281. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  282. Whenever possible, functions should return -1 on error and 0 on success.
  283. For multi-word identifiers, use lowercase words combined with
  284. underscores. (e.g., "multi_word_identifier"). Use ALL_CAPS for macros and
  285. constants.
  286. Typenames should end with "_t".
  287. Function names should be prefixed with a module name or object name. (In
  288. general, code to manipulate an object should be a module with the same name
  289. as the object, so it's hard to tell which convention is used.)
  290. Functions that do things should have imperative-verb names
  291. (e.g. buffer_clear, buffer_resize); functions that return booleans should
  292. have predicate names (e.g. buffer_is_empty, buffer_needs_resizing).
  293. If you find that you have four or more possible return code values, it's
  294. probably time to create an enum. If you find that you are passing three or
  295. more flags to a function, it's probably time to create a flags argument that
  296. takes a bitfield.
  297. What To Optimize
  298. ~~~~~~~~~~~~~~~~
  299. Don't optimize anything if it's not in the critical path. Right now, the
  300. critical path seems to be AES, logging, and the network itself. Feel free to
  301. do your own profiling to determine otherwise.
  302. Log conventions
  303. ~~~~~~~~~~~~~~~
  304. https://www.torproject.org/docs/faq#LogLevel
  305. No error or warning messages should be expected during normal OR or OP
  306. operation.
  307. If a library function is currently called such that failure always means ERR,
  308. then the library function should log WARN and let the caller log ERR.
  309. Every message of severity INFO or higher should either (A) be intelligible
  310. to end-users who don't know the Tor source; or (B) somehow inform the
  311. end-users that they aren't expected to understand the message (perhaps
  312. with a string like "internal error"). Option (A) is to be preferred to
  313. option (B).
  314. Doxygen
  315. ~~~~~~~~
  316. We use the 'doxygen' utility to generate documentation from our
  317. source code. Here's how to use it:
  318. 1. Begin every file that should be documented with
  319. /**
  320. * \file filename.c
  321. * \brief Short description of the file.
  322. **/
  323. (Doxygen will recognize any comment beginning with /** as special.)
  324. 2. Before any function, structure, #define, or variable you want to
  325. document, add a comment of the form:
  326. /** Describe the function's actions in imperative sentences.
  327. *
  328. * Use blank lines for paragraph breaks
  329. * - and
  330. * - hyphens
  331. * - for
  332. * - lists.
  333. *
  334. * Write <b>argument_names</b> in boldface.
  335. *
  336. * \code
  337. * place_example_code();
  338. * between_code_and_endcode_commands();
  339. * \endcode
  340. */
  341. 3. Make sure to escape the characters "<", ">", "\", "%" and "#" as "\<",
  342. "\>", "\\", "\%", and "\#".
  343. 4. To document structure members, you can use two forms:
  344. struct foo {
  345. /** You can put the comment before an element; */
  346. int a;
  347. int b; /**< Or use the less-than symbol to put the comment
  348. * after the element. */
  349. };
  350. 5. To generate documentation from the Tor source code, type:
  351. $ doxygen -g
  352. To generate a file called 'Doxyfile'. Edit that file and run
  353. 'doxygen' to generate the API documentation.
  354. 6. See the Doxygen manual for more information; this summary just
  355. scratches the surface.
  356. Doxygen comment conventions
  357. ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  358. Say what functions do as a series of one or more imperative sentences, as
  359. though you were telling somebody how to be the function. In other words, DO
  360. NOT say:
  361. /** The strtol function parses a number.
  362. *
  363. * nptr -- the string to parse. It can include whitespace.
  364. * endptr -- a string pointer to hold the first thing that is not part
  365. * of the number, if present.
  366. * base -- the numeric base.
  367. * returns: the resulting number.
  368. */
  369. long strtol(const char *nptr, char **nptr, int base);
  370. Instead, please DO say:
  371. /** Parse a number in radix <b>base</b> from the string <b>nptr</b>,
  372. * and return the result. Skip all leading whitespace. If
  373. * <b>endptr</b> is not NULL, set *<b>endptr</b> to the first character
  374. * after the number parsed.
  375. **/
  376. long strtol(const char *nptr, char **nptr, int base);
  377. Doxygen comments are the contract in our abstraction-by-contract world: if
  378. the functions that call your function rely on it doing something, then your
  379. function should mention that it does that something in the documentation. If
  380. you rely on a function doing something beyond what is in its documentation,
  381. then you should watch out, or it might do something else later.
  382. Putting out a new release
  383. -------------------------
  384. Here are the steps Roger takes when putting out a new Tor release:
  385. 1) Use it for a while, as a client, as a relay, as a hidden service,
  386. and as a directory authority. See if it has any obvious bugs, and
  387. resolve those.
  388. 1.5) As applicable, merge the maint-X branch into the release-X branch.
  389. 2) Gather the changes/* files into a changelog entry, rewriting many
  390. of them and reordering to focus on what users and funders would find
  391. interesting and understandable.
  392. 2.1) Make sure that everything that wants a bug number has one.
  393. Make sure that everything which is a bugfix says what version
  394. it was a bugfix on.
  395. 2.2) Concatenate them.
  396. 2.3) Sort them by section. Within each section, sort by "version it's
  397. a bugfix on", else by numerical ticket order.
  398. 2.4) Clean them up:
  399. Standard idioms:
  400. "Fixes bug 9999; bugfix on 0.3.3.3-alpha."
  401. One space after a period.
  402. Make stuff very terse
  403. Make sure each section name ends with a colon
  404. Describe the user-visible problem right away
  405. Mention relevant config options by name. If they're rare or unusual,
  406. remind people what they're for
  407. Avoid starting lines with open-paren
  408. Present and imperative tense: not past.
  409. 'Relays', not 'servers' or 'nodes' or 'Tor relays'.
  410. "Stop FOOing", not "Fix a bug where we would FOO".
  411. Try not to let any given section be longer than about a page. Break up
  412. long sections into subsections by some sort of common subtopic. This
  413. guideline is especially important when organizing Release Notes for
  414. new stable releases.
  415. If a given changes stanza showed up in a different release (e.g.
  416. maint-0.2.1), be sure to make the stanzas identical (so people can
  417. distinguish if these are the same change).
  418. 2.5) Merge them in.
  419. 2.6) Clean everything one last time.
  420. 2.7) Run ./scripts/maint/format_changelog.py to make it prettier.
  421. 3) Compose a short release blurb to highlight the user-facing
  422. changes. Insert said release blurb into the ChangeLog stanza. If it's
  423. a stable release, add it to the ReleaseNotes file too. If we're adding
  424. to a release-0.2.x branch, manually commit the changelogs to the later
  425. git branches too.
  426. 4) In maint-0.2.x, bump the version number in configure.ac and run
  427. scripts/maint/updateVersions.pl to update version numbers in other
  428. places, and commit. Then merge maint-0.2.x into release-0.2.x.
  429. 5) Make dist, put the tarball up somewhere, and tell #tor about it. Wait
  430. a while to see if anybody has problems building it. Try to get Sebastian
  431. or somebody to try building it on Windows.
  432. 6) Get at least two of weasel/arma/sebastian to put the new version number
  433. in their approved versions list.
  434. 7) Sign the tarball, then sign and push the git tag:
  435. gpg -ba <the_tarball>
  436. git tag -u <keyid> tor-0.2.x.y-status
  437. git push origin tag tor-0.2.x.y-status
  438. 8a) scp the tarball and its sig to the dist website, i.e.
  439. /srv/dist-master.torproject.org/htdocs/ on dist-master. When you want
  440. it to go live, you run "static-update-component dist.torproject.org"
  441. on dist-master.
  442. 8b) Edit "include/versions.wmi" and "Makefile" to note the new version.
  443. 9) Email the packagers (cc'ing tor-assistants) that a new tarball is up.
  444. The current list of packagers is:
  445. {weasel,gk,mikeperry} at torproject dot org
  446. {blueness} at gentoo dot org
  447. {paul} at invizbox dot io
  448. {ondrej.mikle} at gmail dot com
  449. {lfleischer} at archlinux dot org
  450. 10) Add the version number to Trac. To do this, go to Trac, log in,
  451. select "Admin" near the top of the screen, then select "Versions" from
  452. the menu on the left. At the right, there will be an "Add version"
  453. box. By convention, we enter the version in the form "Tor:
  454. 0.2.2.23-alpha" (or whatever the version is), and we select the date as
  455. the date in the ChangeLog.
  456. 11) Forward-port the ChangeLog.
  457. 12) Wait up to a day or two (for a development release), or until most
  458. packages are up (for a stable release), and mail the release blurb and
  459. changelog to tor-talk or tor-announce.
  460. (We might be moving to faster announcements, but don't announce until
  461. the website is at least updated.)
  462. 13) If it's a stable release, bump the version number in the maint-x.y.z
  463. branch to "newversion-dev", and do a "merge -s ours" merge to avoid
  464. taking that change into master. Do a similar 'merge -s theirs'
  465. merge to get the change (and only that change) into release. (Some
  466. of the build scripts require that maint merge cleanly into release.)