mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-11-27 13:53:31 +01:00
mirror repository of the tor core protocol in case of issues
23f4a28f97
This started as a response to ticket #40792 where Coverity is complaining about a potential year 2038 bug where we cast time_t from approx_time() to uint32_t for use in token_bucket_ctr. There was a larger can of worms though, since token_bucket really doesn't want to be using wallclock time here. I audited the call sites for approx_time() and changed any that used a 32-bit cast or made inappropriate use of wallclock time. Things like certificate lifetime, consensus intervals, etc. need wallclock time. Measurements of rates over time, however, are better served with a monotonic timer that does not try and sync with wallclock ever. Looking closer at token_bucket, its design is a bit odd because it was initially intended for use with tick units but later forked into token_bucket_rw which uses ticks to count bytes per second, and token_bucket_ctr which uses seconds to count slower events. The rates represented by either token bucket can't be lower than 1 per second, so the slower timer in 'ctr' is necessary to represent the slower rates of things like connections or introduction packets or rendezvous attempts. I considered modifying token_bucket to use 64-bit timestamps overall instead of 32-bit, but that seemed like an unnecessarily invasive change that would grant some peace of mind but probably not help much. I was more interested in removing the dependency on wallclock time. The token_bucket_rw timer already uses monotonic time. This patch converts token_bucket_ctr to use monotonic time as well. It introduces a new monotime_coarse_absolute_sec(), which is currently the same as nsec divided by a billion but could be optimized easily if we ever need to. This patch also might fix a rollover bug.. I haven't tested this extensively but I don't think the previous version of the rollover code on either token bucket was correct, and I would expect it to get stuck after the first rollover. Signed-off-by: Micah Elizabeth Scott <beth@torproject.org> |
||
|---|---|---|
| .gitlab/issue_templates | ||
| changes | ||
| contrib | ||
| doc | ||
| m4 | ||
| scripts | ||
| src | ||
| .appveyor.yml | ||
| .clang-format | ||
| .editorconfig | ||
| .gitignore | ||
| .gitlab-ci.yml | ||
| .travis.yml | ||
| acinclude.m4 | ||
| autogen.sh | ||
| ChangeLog | ||
| CODE_OF_CONDUCT | ||
| configure.ac | ||
| CONTRIBUTING | ||
| Doxyfile.in | ||
| INSTALL | ||
| LICENSE | ||
| Makefile.am | ||
| README.md | ||
| ReleaseNotes | ||
| warning_flags.in | ||
Tor protects your privacy on the internet by hiding the connection between your Internet address and the services you use. We believe Tor is reasonably secure, but please ensure you read the instructions and configure it properly.
Build
To build Tor from source:
./configure
make
make install
To build Tor from a just-cloned git repository:
./autogen.sh
./configure
make
make install
Releases
The tarballs, checksums and signatures can be found here: https://dist.torproject.org
- Checksum:
<tarball-name>.sha256sum - Signatures:
<tarball-name>.sha256sum.asc
Schedule
You can find our release schedule here:
Keys that CAN sign a release
The following keys are the maintainers of this repository. One or many of these keys can sign the releases, do NOT expect them all:
- Alexander Færøy: 514102454D0A87DB0767A1EBBE6A0531C18A9179
- David Goulet: B74417EDDF22AC9F9E90F49142E86A2A11F48D36
- Nick Mathewson: 2133BC600AB133E1D826D173FE43009C4607B1FB
Development
See our hacking documentation in doc/HACKING/.
Resources
Home page:
Download new versions:
Documentation, including links to installation and setup instructions:
Frequently Asked Questions: