- tor-commits - lists.torproject.org

[tor-browser-bundle/hardened-builds] Release preparations for 6.0a2-hardened
by gk＠torproject.org 12 Feb '16

12 Feb '16

commit 7bc69717608f8be105594efa95d7bf7ccdc80077 Author: Georg Koppen <gk(a)torproject.org> Date: Fri Feb 12 06:56:49 2016 +0000 Release preparations for 6.0a2-hardened --- Bundle-Data/Docs/ChangeLog.txt | 16 ++++++++++++++++ gitian/versions.alpha | 6 +++--- tools/update-responses/config.yml | 12 ++++++------ 3 files changed, 25 insertions(+), 9 deletions(-) diff --git a/Bundle-Data/Docs/ChangeLog.txt b/Bundle-Data/Docs/ChangeLog.txt index 4210100..d2b7420 100644 --- a/Bundle-Data/Docs/ChangeLog.txt +++ b/Bundle-Data/Docs/ChangeLog.txt @@ -1,3 +1,19 @@ +Tor Browser 6.0a2-hardened -- February 15 2016 + * All Platforms + * Update Firefox to 38.6.1esr + * Update NoScript to 2.9.0.3 + * Bug 18168: Don't clear an iframe's window.name (fix of #16620) + * Bug 18137: Add two new obfs4 default bridges + * Windows + * Bug 18169: Whitelist zh-CN UI font + * OSX + * Bug 18172: Add Emoji support + * Linux + * Bug 18172: Add Emoji support + * Build System + * Linux + * Bug 15578: Switch to Debian Wheezy guest VMs (10.04 LTS is EOL) + Tor Browser 6.0a1-hardened -- January 27 2016 * All Platforms * Update Firefox to 38.6.0esr diff --git a/gitian/versions.alpha b/gitian/versions.alpha index 2921df9..42468c3 100755 --- a/gitian/versions.alpha +++ b/gitian/versions.alpha @@ -11,7 +11,7 @@ MULTI_LINGUAL=1 VERIFY_TAGS=1 -FIREFOX_VERSION=38.6.0esr +FIREFOX_VERSION=38.6.1esr TORBROWSER_UPDATE_CHANNEL=hardened @@ -62,7 +62,7 @@ GO_VER=1.4.2 ## File names for the source packages OPENSSL_PACKAGE=openssl-${OPENSSL_VER}.tar.gz GMP_PACKAGE=gmp-${GMP_VER}.tar.bz2 -NOSCRIPT_PACKAGE=noscript_security_suite-2.9.0.2-sm+fx+fn.xpi +NOSCRIPT_PACKAGE=noscript_security_suite-2.9.0.3-fx+fn+sm.xpi TOOLCHAIN4_PACKAGE=x86_64-apple-darwin10.tar.xz TOOLCHAIN4_OLD_PACKAGE=multiarch-darwin11-cctools127.2-gcc42-5666.3-llvmgcc42-2336.1-Linux-120724.tar.xz OSXSDK_PACKAGE=MacOSX10.7.sdk.tar.gz @@ -91,7 +91,7 @@ OSXSDK_HASH=da77bb0003fcca5ea8c4e8cb2da8828ded750c54afdcac29ec6f3b46ad5e3adf OSXSDK_OLD_HASH=6602d8d5ddb371fbc02e2a5967d9bd0cd7358d46f9417753c8234b923f2ea6fc TOOLCHAIN4_HASH=7b71bfe02820409b994c5c33a7eab81a81c72550f5da85ff7af70da3da244645 TOOLCHAIN4_OLD_HASH=65c1b2d302358a6b95a26c6828a66908a199276193bb0b268f2dcc1a997731e9 -NOSCRIPT_HASH=f3c9dec710e02d809fa85ac76750e5f074656105c1bde03d400cb597b2eb1fba +NOSCRIPT_HASH=097298d5004c1f384f3af508cb1915921145f0f962e78c977a62f405bd7eb2d9 MSVCR100_HASH=1221a09484964a6f38af5e34ee292b9afefccb3dc6e55435fd3aaf7c235d9067 PYCRYPTO_HASH=f2ce1e989b272cfcb677616763e0a2e7ec659effa67a88aa92b3a65528f60a3c ARGPARSE_HASH=ddaf4b0a618335a32b6664d4ae038a1de8fbada3b25033f9021510ed2b3941a4 diff --git a/tools/update-responses/config.yml b/tools/update-responses/config.yml index c66cec5..7b59296 100644 --- a/tools/update-responses/config.yml +++ b/tools/update-responses/config.yml @@ -9,7 +9,7 @@ build_targets: osx32: Darwin_x86-gcc3 osx64: Darwin_x86_64-gcc3 channels: - hardened: 6.0a1-hardened + hardened: 6.0a2-hardened release: 5.0 versions: 5.0: @@ -23,12 +23,12 @@ versions: osx32: minSupportedOSVersion: 10.8 detailsURL: https://blog.torproject.org/blog/end-life-plan-tor-browser-32-bit-macs#upda… - 6.0a1-hardened: - platformVersion: 38.6.0 - detailsURL: https://blog.torproject.org/blog/tor-browser-60a1-hardened-released - download_url: https://www.torproject.org/dist/torbrowser/6.0a1-hardened + 6.0a2-hardened: + platformVersion: 38.6.1 + detailsURL: https://blog.torproject.org/blog/tor-browser-60a2-hardened-released + download_url: https://www.torproject.org/dist/torbrowser/6.0a2-hardened incremental_from: - - 5.5a6-hardened + - 6.0a1-hardened migrate_archs: osx32: osx64 osx32:

1 0

[torspec/master] fixes from reading 266; and ask a question
by arma＠torproject.org 12 Feb '16

12 Feb '16

commit 585b1c34ebe238f8b1737e623fbb8ab3279a019a Author: Roger Dingledine <arma(a)torproject.org> Date: Fri Feb 12 01:25:03 2016 -0500 fixes from reading 266; and ask a question --- proposals/266-removing-current-obsolete-clients.txt | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/proposals/266-removing-current-obsolete-clients.txt b/proposals/266-removing-current-obsolete-clients.txt index 3d8a6c3..7a490be 100644 --- a/proposals/266-removing-current-obsolete-clients.txt +++ b/proposals/266-removing-current-obsolete-clients.txt @@ -101,7 +101,7 @@ Status: Draft would be at their worst when they focus on authorities, or when they act in synchrony to all strike at once. - One goal of this proposal is to ensure that future clients to not + One goal of this proposal is to ensure that future clients do not become zombies at all; and that ancient clients become slow zombies at worst. @@ -130,7 +130,7 @@ Status: Draft in 0.2.2, gabelmoo has moved and turtles has shut down. The authorities Faravahar and longclaw are new. The authorities moria1, tor26, dizum, dannenberg, urras, maatuska and maatuska would all get - hit here.) + hit here.) [two maatuskas? -RD] (We could simply remove the renegotiation-detection code entirely, and reply to all connections with an immediate VERSIONS cell. The @@ -150,13 +150,13 @@ Status: Draft we could detect these versions by: Looking for use of a TAP handshake from an IP not associated - with with any known relay, or on a connection where the client + with any known relay, or on a connection where the client did not authenticate. (This could be from a bridge, but clients don't build circuits that go to an IntroPoint or RendPoint directly after a bridge.) This would still result in clients not having directories, however, - and retrying once an hours. + and retrying once an hour. 3. Ideas that might work @@ -189,7 +189,7 @@ Status: Draft consensus documents. Later, if we want to disable all Tor versions before today, we can change the consensus algorithm so that the consensus (or perhaps only the microdesc consensus) is spelled with - 'f' lines instead of 'f' lines. This will create a consensus which + 'f' lines instead of 's' lines. This will create a consensus which older clients and relays parse as having all nodes down, which will make them not connect to the network at all. @@ -202,3 +202,4 @@ Status: Draft from downloading new consensuses. [This proposal would result in the quietest shutdown.] +

1 0

[torspec/master] renumber 260
by arma＠torproject.org 12 Feb '16

12 Feb '16

commit 2d7a01399b49749a71d760818ef3f0c9c8799cf5 Author: Roger Dingledine <arma(a)torproject.org> Date: Thu Feb 11 23:29:42 2016 -0500 renumber 260 --- proposals/260-rend-single-onion.txt | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/proposals/260-rend-single-onion.txt b/proposals/260-rend-single-onion.txt index 79990a8..48aa794 100644 --- a/proposals/260-rend-single-onion.txt +++ b/proposals/260-rend-single-onion.txt @@ -200,7 +200,7 @@ Status: Draft And turning off hidden service server preemptive circuits, which is currently unimplemented (#17360) -5.1.3 Recommended Additional Options: Security +5.1.4 Recommended Additional Options: Security We recommend that no other services are run on a rendezvous single onion service tor instance. Since tor runs as a client (and not a relay) by @@ -275,7 +275,7 @@ Status: Draft extend. This is useful for the transition period where not all clients support single onion services. -6.5. Proposal 255 ("Hidden Service Load Balancing") +6.6. Proposal 255 ("Hidden Service Load Balancing") This proposal is compatible with proposal 255. The onion service will perform the rendezvous protocol in the same manner as any other onion @@ -316,7 +316,7 @@ Status: Draft been performed. In addition, a potential drawback is overloading a busy single onion service. -6.4 Predicted circuits +7.4 Predicted circuits We should look whether we can optimize further the predicted circuits that Tor makes as an onion service for this mode. @@ -458,3 +458,4 @@ splitting described in section 8. Here are some initial ideas. This option is disabled in Tor Browser by default. Perhaps some users would be more comfortable enabling submission over an onion service, due to the additional security benefits. +

1 0

[torspec/master] grammar/etc clarifications while reading proposal 260
by arma＠torproject.org 12 Feb '16

12 Feb '16

commit b6b2d248ca9b51876eb841c545c6641c1697aac0 Author: Roger Dingledine <arma(a)torproject.org> Date: Thu Feb 11 23:11:35 2016 -0500 grammar/etc clarifications while reading proposal 260 --- proposals/260-rend-single-onion.txt | 32 ++++++++++++++++---------------- 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/proposals/260-rend-single-onion.txt b/proposals/260-rend-single-onion.txt index fc01551..79990a8 100644 --- a/proposals/260-rend-single-onion.txt +++ b/proposals/260-rend-single-onion.txt @@ -29,10 +29,10 @@ Status: Draft 2. Motivation Rendezvous single onion services are best used by sites which: - * Don’t require location anonymity + * Don't require location anonymity * Would appreciate lower latency or self-authenticated addresses * Would like to work with existing tor clients and relays - * Can’t accept connections to an open ORPort + * Can't accept connections to an open ORPort Rendezvous single onion services have a few benefits over double onion services: @@ -61,7 +61,7 @@ Status: Draft * Connection latency is higher, as one-hop circuits are built to the introduction and rendezvous points. Single onion services perform one - extend to the single onion service’s ORPort only + extend to the single onion service's ORPort only It should also be noted that, while single onion services receive many incoming connections from different relays, rendezvous single onion @@ -99,8 +99,8 @@ Status: Draft further discussion of security issues.) (Please note that this proposal follows the hop counting conventions in the - tor source code. A circuit with a single connections between the client and - the endpoint is one-hop, a circuit with 4 connections (and 3 nodes) between + tor source code. A circuit with a single connection between the client and + the endpoint is one-hop; a circuit with 4 connections (and 3 nodes) between the client and endpoint is four-hop.) 5. Publishing a rendezvous single onion service @@ -109,11 +109,11 @@ Status: Draft group of tor instances) must: * Publish onion descriptors in the same manner as any onion service, - using three-hop circuits. This avoids service blocking by IP address, - proposal #224 (next-generation hidden services) avoids blocking by + using three-hop circuits. This avoids service blocking by IP address. + Proposal #224 (next-generation hidden services) avoids blocking by onion address. * Perform the rendezvous protocol in the same manner as a double - onion service, but make the intro and rendezvous connections one-hop. + onion service, but make the intro and rendezvous circuits one-hop. (This may allow intro and rendezvous points to block the service.) 5.1. Configuration options @@ -130,10 +130,10 @@ Status: Draft a Rendezvous Single Onion Service. (Default: 0) Because of the grave consequences of misconfiguration here, we have added - ‘NonAnonymous’ to the name of the torrc option. Furthermore, Tor MUST issue + 'NonAnonymous' to the name of the torrc option. Furthermore, Tor MUST issue a startup warning message to operators of the onion service if this feature is enabled. - [Should the name start with ‘NonAnonymous’ instead?] + [Should the name start with 'NonAnonymous' instead?] As RendezvousSingleOnionServiceNonAnonymousServer modifies the behaviour of every onion service on a tor instance, it is impossible to run hidden @@ -271,7 +271,7 @@ Status: Draft service, or continue with the rendezvous protocol. Running a rendezvous single onion service and single onion service allows - older clients to connect via rendezvous, and newer clients to connenct via + older clients to connect via rendezvous, and newer clients to connect via extend. This is useful for the transition period where not all clients support single onion services. @@ -319,7 +319,7 @@ Status: Draft 6.4 Predicted circuits We should look whether we can optimize further the predicted circuits that - Tor makes as a onion service for this mode. + Tor makes as an onion service for this mode. 8. Security Implications @@ -342,7 +342,7 @@ Status: Draft single onion services due to their benefits. This could increase the traffic on the tor network, therefore increasing anonymity overall. However, the unique behaviour of each type of onion service may still be - distinguishable from both the client and server ends of the connection. + distinguishable on both the client and server ends of the connection. 8.2 Hidden Service Designs can potentially be more secure @@ -352,9 +352,9 @@ Status: Draft 8.3 One-hop onion service paths may encourage more attacks - There's a possible second-order effect here since both encrypted - services and hidden services will have foo.onion addresses and it's - not clear based on the address whether the service will be hidden -- + There's a possible second-order effect here since both RSOS + and double onion services will have foo.onion addresses and it's + not clear based on the address which one the service uses: if *some* .onion addresses are easy to track down, are we encouraging adversaries to attack all rendezvous points just in case?

1 0

[torspec/master] tiny tweaks to proposal 255 after reading
by arma＠torproject.org 12 Feb '16

12 Feb '16

commit 0c14d27563e6cfb24ee2a11457f8b64b80512259 Author: Roger Dingledine <arma(a)torproject.org> Date: Thu Feb 11 23:04:27 2016 -0500 tiny tweaks to proposal 255 after reading --- proposals/255-hs-load-balancing.txt | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/proposals/255-hs-load-balancing.txt b/proposals/255-hs-load-balancing.txt index eaab035..a19949c 100644 --- a/proposals/255-hs-load-balancing.txt +++ b/proposals/255-hs-load-balancing.txt @@ -101,7 +101,7 @@ is the minimal amount of data required to process the INTRODUCE2 cell on another machine. Before proposal 224 is implemented, this could consist of the -INTRODUCE2 cell payload, the key to decrypt the cell with if the cell +INTRODUCE2 cell payload, the key to decrypt the cell if the cell is not already decrypted (which may be preferable, for performance reasons), and data necessary for other machines to recognize what to do with the cell. @@ -136,7 +136,7 @@ INTRODUCE2 cell arrives at the node which published the descriptor, it does not immediately try to perform the rendezvous, but instead outputs this to the controller. Through an out-of-band process this message is relayed to a controller of another node of Bob's, and this transmits -the "PERFORM-RENDEZVOUS" command to that node. This node finally +the "PERFORM-RENDEZVOUS" command to that node. This node performs the rendezvous, and will continue to serve data to Alice, whose client will now not have to talk to the introduction point anymore. @@ -155,3 +155,4 @@ and to leave the actual load-balancing algorithm to the implementor of the controller. The developer of the tor implementation should not have to choose between a round-robin algorithm and something that could pull CPU load averages from a centralized monitoring system. +

1 0

[tor/master] Fix all doxygen warnings other than "X is not documented"
by nickm＠torproject.org 12 Feb '16

12 Feb '16

commit 1f679d4ae11cd976f5539bc4ddf36873132aeb00 Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Feb 11 22:06:44 2016 -0500 Fix all doxygen warnings other than "X is not documented" --- src/or/config.c | 2 +- src/or/policies.c | 14 ++++++++------ src/or/routerparse.c | 2 +- 3 files changed, 10 insertions(+), 8 deletions(-) diff --git a/src/or/config.c b/src/or/config.c index d71cf6d..5273d5a 100644 --- a/src/or/config.c +++ b/src/or/config.c @@ -2693,7 +2693,7 @@ options_validate_cb(void *old_options, void *options, void *default_options, /** Log a warning message iff filepath is not absolute. * Warning message must contain option name option and - * an absolute path that filepath will resolve to. + * an absolute path that filepath will resolve to. * * In case filepath is absolute, do nothing. */ diff --git a/src/or/policies.c b/src/or/policies.c index 984ab6a..179230b 100644 --- a/src/or/policies.c +++ b/src/or/policies.c @@ -1703,19 +1703,21 @@ exit_policy_remove_redundancies(smartlist_t *dest) /** Reject private helper for policies_parse_exit_policy_internal: rejects * publicly routable addresses on this exit relay. * - * Add reject entries to the linked list *dest: - * - if configured_addresses is non-NULL, add entries that reject each - * tor_addr_t* in the list as a destination. - * - if reject_interface_addresses is true, add entries that reject each + * Add reject entries to the linked list *dest: + * <ul> + * <li>if configured_addresses is non-NULL, add entries that reject each + * tor_addr_t in the list as a destination. + * <li>if reject_interface_addresses is true, add entries that reject each * public IPv4 and IPv6 address of each interface on this machine. - * - if reject_configured_port_addresses is true, add entries that reject + * <li>if reject_configured_port_addresses is true, add entries that reject * each IPv4 and IPv6 address configured for a port. + * </ul> * * IPv6 entries are only added if ipv6_exit is true. (All IPv6 addresses are * already blocked by policies_parse_exit_policy_internal if ipv6_exit is * false.) * - * The list *dest is created as needed. + * The list in dest is created as needed. */ void policies_parse_exit_policy_reject_private( diff --git a/src/or/routerparse.c b/src/or/routerparse.c index fafba96..3be43dc 100644 --- a/src/or/routerparse.c +++ b/src/or/routerparse.c @@ -3679,7 +3679,7 @@ networkstatus_parse_detached_signatures(const char *s, const char *eos) * * Returns NULL on policy errors. * - * Set *malformed_list>/b> to true if the entire policy list should be + * Set *malformed_list to true if the entire policy list should be * discarded. Otherwise, set it to false, and only this item should be ignored * on error - the rest of the policy list can continue to be processed and * used.

1 0

[translation/tails-openpgp-applet] Update translations for tails-openpgp-applet
by translation＠torproject.org 11 Feb '16

11 Feb '16

commit 2f815869be34ac66970989732b264e737d69803e Author: Translation commit bot <translation(a)torproject.org> Date: Thu Feb 11 18:46:49 2016 +0000 Update translations for tails-openpgp-applet --- eu/openpgp-applet.pot | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/eu/openpgp-applet.pot b/eu/openpgp-applet.pot index 6dedc2c..235e795 100644 --- a/eu/openpgp-applet.pot +++ b/eu/openpgp-applet.pot @@ -3,13 +3,14 @@ # This file is distributed under the same license as the PACKAGE package. # # Translators: +# Iban <iban.ferreira(a)gmail.com>, 2016 msgid "" msgstr "" "Project-Id-Version: The Tor Project\n" "Report-Msgid-Bugs-To: tails(a)boum.org\n" "POT-Creation-Date: 2015-08-10 15:55+0200\n" -"PO-Revision-Date: 2015-11-23 02:23+0000\n" -"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n" +"PO-Revision-Date: 2016-02-11 18:28+0000\n" +"Last-Translator: Iban <iban.ferreira(a)gmail.com>\n" "Language-Team: Basque (http://www.transifex.com/otf/torproject/language/eu/)\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" @@ -92,8 +93,8 @@ msgstr "Hatz-marka:" #: bin/openpgp-applet:447 msgid "User ID:" msgid_plural "User IDs:" -msgstr[0] "" -msgstr[1] "" +msgstr[0] "Erabiltzaile ID:" +msgstr[1] "Erabiltzaile ID-ak:" #: bin/openpgp-applet:476 msgid "None (Don't sign)" @@ -128,8 +129,8 @@ msgstr "Gako hauetaz fidatzen zara?" #: bin/openpgp-applet:603 msgid "The following selected key is not fully trusted:" msgid_plural "The following selected keys are not fully trusted:" -msgstr[0] "" -msgstr[1] "" +msgstr[0] "Hurrengo gako aukeratua ez da guztiz fidagarria:" +msgstr[1] "Hurrengo gako aukeratuak ez dira guztiz fidagarriak:" #: bin/openpgp-applet:621 msgid "Do you trust this key enough to use it anyway?"

1 0

[translation/torbutton-aboutdialogdtd] Update translations for torbutton-aboutdialogdtd
by translation＠torproject.org 11 Feb '16

11 Feb '16

commit 719c203e1417a3b5a5e5be7ccd93c2649aa202ff Author: Translation commit bot <translation(a)torproject.org> Date: Thu Feb 11 18:46:05 2016 +0000 Update translations for torbutton-aboutdialogdtd --- tl_PH/aboutdialog.dtd | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/tl_PH/aboutdialog.dtd b/tl_PH/aboutdialog.dtd index 5099ad7..e957f74 100644 --- a/tl_PH/aboutdialog.dtd +++ b/tl_PH/aboutdialog.dtd @@ -1,19 +1,19 @@ -<!ENTITY project.start "&brandShortName; is developed by "> +<!ENTITY project.start "Ang &brandShortName; ay ginawa ng">  -<!ENTITY project.tpoLink "the &vendorShortName;"> +<!ENTITY project.tpoLink "&vendorShortName;"> <!ENTITY project.end ", a nonprofit working to defend your privacy and freedom online."> -<!ENTITY help.start "Want to help? "> +<!ENTITY help.start "Gusto mong Tumulong?">  -<!ENTITY help.donateLink "Donate"> -<!ENTITY help.or " or "> +<!ENTITY help.donateLink "Mag-donate"> +<!ENTITY help.or "o">  -<!ENTITY help.getInvolvedLink "get involved"> +<!ENTITY help.getInvolvedLink "makailahok"> <!ENTITY help.end "!">  -<!ENTITY bottomLinks.questions "Questions?"> +<!ENTITY bottomLinks.questions "Mga katanungan?">  -<!ENTITY bottomLinks.grow "Help the Tor Network Grow!"> +<!ENTITY bottomLinks.grow "Tulungang umnlad ang Tor Network!">  -<!ENTITY bottomLinks.license "Licensing Information"> -<!ENTITY tor.TrademarkStatement "'Tor' and the 'Onion Logo' are registered trademarks of the Tor Project, Inc."> +<!ENTITY bottomLinks.license "Kaalaman sa Paglisensiya"> +<!ENTITY tor.TrademarkStatement "Ang 'Tor' at ang 'Onion Logo' ay rehistradong pagmamay-ari ng Tor Project, Inc.">

1 0

[tor/master] Add an assertion to tor_libevent_get_base()
by nickm＠torproject.org 11 Feb '16

11 Feb '16

commit c595f6d25e9cda58f5327c5806e2c9a534c454f9 Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Feb 4 12:37:00 2016 -0500 Add an assertion to tor_libevent_get_base() Closes ticket 18241. --- changes/assert_event_base | 5 +++++ src/common/compat_libevent.c | 1 + 2 files changed, 6 insertions(+) diff --git a/changes/assert_event_base b/changes/assert_event_base new file mode 100644 index 0000000..b887795 --- /dev/null +++ b/changes/assert_event_base @@ -0,0 +1,5 @@ + o Minor features (robustness): + - Exit immediately with an error message if the code attempts to + use libevent without having initialized it. This should resolve + some frequently-made mistakes in our unit tests. Closes ticket + 18241. diff --git a/src/common/compat_libevent.c b/src/common/compat_libevent.c index 29e5c5f..c367ee4 100644 --- a/src/common/compat_libevent.c +++ b/src/common/compat_libevent.c @@ -247,6 +247,7 @@ tor_libevent_initialize(tor_libevent_cfg *torcfg) MOCK_IMPL(struct event_base *, tor_libevent_get_base, (void)) { + tor_assert(the_event_base != NULL); return the_event_base; }

1 0

[tor/master] Check that the log mutex is initialised before trying to lock or unlock it
by nickm＠torproject.org 11 Feb '16

11 Feb '16

commit db72b509d17311d289b140afb3456376c5525ad7 Author: teor (Tim Wilson-Brown) <teor2345(a)gmail.com> Date: Fri Feb 5 14:08:58 2016 +1100 Check that the log mutex is initialised before trying to lock or unlock it --- src/common/log.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/src/common/log.c b/src/common/log.c index 4a8a7b1..f71583f 100644 --- a/src/common/log.c +++ b/src/common/log.c @@ -149,10 +149,14 @@ static int pretty_fn_has_parens = 0; /** Lock the log_mutex to prevent others from changing the logfile_t list */ #define LOCK_LOGS() STMT_BEGIN \ + tor_assert(log_mutex_initialized); \ tor_mutex_acquire(&log_mutex); \ STMT_END /** Unlock the log_mutex */ -#define UNLOCK_LOGS() STMT_BEGIN tor_mutex_release(&log_mutex); STMT_END +#define UNLOCK_LOGS() STMT_BEGIN \ + tor_assert(log_mutex_initialized); \ + tor_mutex_release(&log_mutex); \ + STMT_END /** What's the lowest log level anybody cares about? Checking this lets us * bail out early from log_debug if we aren't debugging. */ @@ -482,6 +486,8 @@ logv,(int severity, log_domain_mask_t domain, const char *funcname, /* check that severity is sane. Overrunning the masks array leads to * interesting and hard to diagnose effects */ assert(severity >= LOG_ERR && severity <= LOG_DEBUG); + /* check that we've initialised the log mutex before we try to lock it */ + assert(log_mutex_initialized); LOCK_LOGS(); if ((! (domain & LD_NOCB)) && smartlist_len(pending_cb_messages))

1 0