tor-commits November 2019

tor-commits@lists.torproject.org

20 participants
2923 discussions

[translation/bridgedb] https://gitweb.torproject.org/translation.git/commit/?h=bridgedb
by translation＠torproject.org 15 Nov '19

15 Nov '19

commit a0055a37e55bf8fb63db53da2471c2a953378249 Author: Translation commit bot <translation(a)torproject.org> Date: Fri Nov 15 14:15:15 2019 +0000 https://gitweb.torproject.org/translation.git/commit/?h=bridgedb --- vi/LC_MESSAGES/bridgedb.po | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/vi/LC_MESSAGES/bridgedb.po b/vi/LC_MESSAGES/bridgedb.po index f1d6c544f..c3d95b44c 100644 --- a/vi/LC_MESSAGES/bridgedb.po +++ b/vi/LC_MESSAGES/bridgedb.po @@ -4,6 +4,7 @@ # # Translators: # Acooldude, 2016 +# Đức Phạm Minh <phamducvn.0308(a)gmail.com>, 2019 # Khanh Nguyen <nguyenduykhanh85(a)gmail.com>, 2015-2016 # Gary, 2016 # Ngo Long <ngotienlong1996(a)gmail.com>, 2018 @@ -13,8 +14,8 @@ msgstr "" "Project-Id-Version: Tor Project\n" "Report-Msgid-Bugs-To: 'https://trac.torproject.org/projects/tor/newticket?component=BridgeDB&keywo…'\n" "POT-Creation-Date: 2019-10-19 14:51-0700\n" -"PO-Revision-Date: 2019-10-22 01:44+0000\n" -"Last-Translator: erinm\n" +"PO-Revision-Date: 2019-11-15 14:12+0000\n" +"Last-Translator: Đức Phạm Minh <phamducvn.0308(a)gmail.com>\n" "Language-Team: Vietnamese (http://www.transifex.com/otf/torproject/language/vi/)\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" @@ -293,7 +294,7 @@ msgid "" "Another way to get bridges is to send an email to %s. Please note that you must\n" "send the email using an address from one of the following email providers:\n" "%s or %s." -msgstr "" +msgstr "Cách khác để lấy bridges là gửi một email tới %s. Hãy lưu ý rằng bạn phải gửi một email\nsử dụng đỉa chỉ từ một trong những nhà cung cấp email sau:\n%s hoặc %s." #: bridgedb/strings.py:115 msgid "My bridges don't work! I need help!"

1 0

[tor/master] Improve subsys documentation; add initialization documentation.
by nickm＠torproject.org 15 Nov '19

15 Nov '19

commit a6d22d7fc2c5f5c868fda4ed1224216a16c25f84 Author: Nick Mathewson <nickm(a)torproject.org> Date: Sun Nov 10 16:11:40 2019 -0500 Improve subsys documentation; add initialization documentation. --- src/lib/subsys/initialization.dox | 76 +++++++++++++++++++++++++++++++++++++++ src/lib/subsys/subsys.h | 58 ++++++++++++++++++++++++++++-- src/mainpage.dox | 3 ++ 3 files changed, 135 insertions(+), 2 deletions(-) diff --git a/src/lib/subsys/initialization.dox b/src/lib/subsys/initialization.dox new file mode 100644 index 000000000..3b500f962 --- /dev/null +++ b/src/lib/subsys/initialization.dox @@ -0,0 +1,76 @@ +/** + +@page initialization Initialization and shutdown + +@tableofcontents + +@section overview Overview + +Tor has a single entry point: tor_run_main() in main.c. All the ways of +starting a Tor process (ntmain.c, tor_main.c, and tor_api.c) work by invoking tor_run_main(). + +The tor_run_main() function normally exits (\ref init_exceptwhen "1") by +returning: not by calling abort() or exit(). Before it returns, it calls +tor_cleanup() in shutdown.c. + +Conceptually, there are several stages in running Tor. + +1. First, we initialize those modules that do not depend on the + configuration. This happens in the first half of tor_run_main(), and the + first half of tor_init(). (\ref init_pending_refactor "2") + +2. Second, we parse the command line and our configuration, and configure + systems that depend on our configuration or state. This configuration + happens midway through tor_init(), which invokes + options_init_from_torrc(). We then initialize more systems from the + second half of tor_init(). + +3. At this point we may exit early if we have been asked to do something + requiring no further initialization, like printing our version number or + creating a new signing key. Otherwise, we proceed to run_tor_main_loop(), + which initializes some network-specific parts of Tor, grabs some + daemon-only resources (like the data directory lock) and starts Tor itself + running. + + +> \anchor init_exceptwhen 1. tor_run_main() _can_ terminate with a call to +> abort() or exit(), but only when crashing due to a bug, or when forking to +> run as a daemon. + +> \anchor init_pending_refactor 2. The pieces of code that I'm describing as +> "the first part of tor_init()" and so on deserve to be functions with their +> own name. I'd like to refactor them, but before I do so, there is some +> slight reorganization that needs to happen. Notably, the +> nt_service_parse_options() call ought logically to be later in our +> initialization sequence. See \ticket{32447} for our refactoring progress. + + +@section subsys Subsystems and initialization + +Our current convention is to use the subsystem mechanism to initialize and +clean up pieces of Tor. The more recently updated pieces of Tor will use +this mechanism. For examples, see e.g. time_sys.c or log_sys.c. + +In simplest terms, a **subsytem** is a logically separate part of Tor that +can be initialized, shut down, managed, and configured somewhat independently +of the rest of the program. + +To define a subsystem, we declare a `static const` instance of subsys_fns_t, +describing the subsystem and a set of functions that initialize it, +deconstruct it, and so on. See the documentation for subsys_fns_t for a full +list of these functions. + +After defining a subsytem, it must be inserted in subsystem_list.c. At that +point, table-driven mechanisms in subsysmgr.c will invoke its functions when +appropriate. + +@subsection vsconfig Initialization versus configuration + +We note that the initialization phase of Tor occurs before any configuration +is read from disk -- and therefore before any other files are read from +disk. Therefore, any behavior that depends on Tor's configuration or state +must occur _after_ the initialization process, during configuration. + + + +**/ diff --git a/src/lib/subsys/subsys.h b/src/lib/subsys/subsys.h index 29a90c049..258d060bb 100644 --- a/src/lib/subsys/subsys.h +++ b/src/lib/subsys/subsys.h @@ -25,6 +25,13 @@ struct config_format_t; * * You should use c99 named-field initializers with this structure: we * will be adding more fields, often in the middle of the structure. + * + * See \ref initialization for more information about initialization and + * shutdown in Tor. + * + * To make a new subsystem, you declare a const instance of this type, and + * include it on the list in subsystem_list.c. The code that manages these + * subsystems is in subsysmgr.c. **/ typedef struct subsys_fns_t { /** @@ -55,7 +62,7 @@ typedef struct subsys_fns_t { * it is only for global state or pre-configuration state. * * (If you need to do any setup that depends on configuration, you'll need - * to declare a configuration callback. (Not yet designed)) + * to declare a configuration callback instead. (Not yet designed)) * * This function MUST NOT have any parts that can fail. **/ @@ -63,22 +70,49 @@ typedef struct subsys_fns_t { /** * Connect a subsystem to the message dispatch system. + * + * This function should use the macros in \refdir{lib/pubsub} to register a + * set of messages that this subsystem may publish, and may subscribe to. + * + * See pubsub_macros.h for more information, and for examples. **/ int (*add_pubsub)(struct pubsub_connector_t *); /** * Perform any necessary pre-fork cleanup. This function may not fail. + * + * On Windows (and any other platforms without fork()), this function will + * never be invoked. Otherwise it is used when we are about to start + * running as a background daemon, or when we are about to run a unit test + * in a subprocess. Unlike the subsys_fns_t.postfork callback, it is run + * from the parent process. + * + * Note that we do not invoke this function when the child process's only + * purpose is to call exec() and run another program. */ void (*prefork)(void); /** * Perform any necessary post-fork setup. This function may not fail. + * + * On Windows (and any other platforms without fork()), this function will + * never be invoked. Otherwise it is used when we are about to start + * running as a background daemon, or when we are about to run a unit test + * in a subprocess. Unlike the subsys_fns_t.prefork callback, it is run + * from the child process. + * + * Note that we do not invoke this function when the child process's only + * purpose is to call exec() and run another program. */ void (*postfork)(void); /** * Free any thread-local resources held by this subsystem. Called before * the thread exits. + * + * This function is not allowed to fail. + * + * \bug Note that this callback is currently buggy: See \ticket{32103}. */ void (*thread_cleanup)(void); @@ -86,18 +120,28 @@ typedef struct subsys_fns_t { * Free all resources held by this subsystem. * * This function is not allowed to fail. + * + * Subsystems are shut down when Tor is about to exit or return control to + * an embedding program. This callback must return the process to a state + * such that subsys_fns_t.init will succeed if invoked again. **/ void (*shutdown)(void); /** * A config_format_t describing all of the torrc fields owned by this * subsystem. + * + * This object, if present, is registered in a confmgr_t for Tor's options, + * and used to parse option fields from the command line and torrc file. **/ const struct config_format_t *options_format; /** * A config_format_t describing all of the DataDir/state fields owned by * this subsystem. + * + * This object, if present, is registered in a confmgr_t for Tor's state, + * and used to parse state fields from the DataDir/state file. **/ const struct config_format_t *state_format; @@ -106,7 +150,11 @@ typedef struct subsys_fns_t { * on success, -1 on failure. * * It is safe to store the pointer to the object until set_options() - * is called again. */ + * is called again. + * + * This function is only called after all the validation code defined + * by subsys_fns_t.options_format has passed. + **/ int (*set_options)(void *); /* XXXX Add an implementation for options_act_reversible() later in this @@ -118,6 +166,12 @@ typedef struct subsys_fns_t { * * It is safe to store the pointer to the object; set_state() is only * called on startup. + * + * This function is only called after all the validation code defined + * by subsys_fns_t.state_format has passed. + * + * This function will only be called once per invocation of Tor, since + * Tor does not reload its state while it is running. **/ int (*set_state)(void *); diff --git a/src/mainpage.dox b/src/mainpage.dox index eb29eb5fa..575d8b7f4 100644 --- a/src/mainpage.dox +++ b/src/mainpage.dox @@ -30,7 +30,10 @@ Tor repository. @subpage intro +@subpage initialization + @subpage dataflow + **/ /**

1 0

[tor/master] Not const.
by nickm＠torproject.org 15 Nov '19

15 Nov '19

commit 2d508f8fa56e180428337750788a155579ba84c8 Author: Nick Mathewson <nickm(a)torproject.org> Date: Sun Nov 10 16:14:38 2019 -0500 Not const. --- src/lib/subsys/initialization.dox | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/lib/subsys/initialization.dox b/src/lib/subsys/initialization.dox index 3b500f962..ed2d5abf2 100644 --- a/src/lib/subsys/initialization.dox +++ b/src/lib/subsys/initialization.dox @@ -55,7 +55,7 @@ In simplest terms, a **subsytem** is a logically separate part of Tor that can be initialized, shut down, managed, and configured somewhat independently of the rest of the program. -To define a subsystem, we declare a `static const` instance of subsys_fns_t, +To define a subsystem, we declare a `const` instance of subsys_fns_t, describing the subsystem and a set of functions that initialize it, deconstruct it, and so on. See the documentation for subsys_fns_t for a full list of these functions. @@ -73,4 +73,5 @@ must occur _after_ the initialization process, during configuration. + **/

1 0

[tor/master] Merge branch 'ticket32211'
by nickm＠torproject.org 15 Nov '19

15 Nov '19

commit 97b5ff2b1d6ec59aea66cc262cf2545c98eefc5b Merge: 7aaa4ae30 8746fedce Author: Nick Mathewson <nickm(a)torproject.org> Date: Fri Nov 15 09:10:11 2019 -0500 Merge branch 'ticket32211' Doxyfile.in | 2 + src/lib/subsys/initialization.dox | 77 +++++++++++++++++++++++++++++++++++++++ src/lib/subsys/subsys.h | 63 ++++++++++++++++++++++++++++++-- src/mainpage.dox | 2 + 4 files changed, 140 insertions(+), 4 deletions(-) diff --cc src/mainpage.dox index 1da074951,575d8b7f4..e3b17cf16 --- a/src/mainpage.dox +++ b/src/mainpage.dox @@@ -30,16 -30,10 +30,18 @@@ Tor repository @subpage intro + @subpage initialization + @subpage dataflow +@subpage certificates + +@subpage threading + +@subpage strings + +@subpage time_periodic + **/ /**

1 0

[tor/master] Initialization documents: incorporate feedback from review.
by nickm＠torproject.org 15 Nov '19

15 Nov '19

commit 8746fedce4a440cccde2b4683d7aa72e7c0b0c89 Author: Nick Mathewson <nickm(a)torproject.org> Date: Fri Nov 15 09:00:54 2019 -0500 Initialization documents: incorporate feedback from review. (Thanks, Taylor!) --- src/lib/subsys/initialization.dox | 18 +++++++++--------- src/lib/subsys/subsys.h | 9 +++++---- 2 files changed, 14 insertions(+), 13 deletions(-) diff --git a/src/lib/subsys/initialization.dox b/src/lib/subsys/initialization.dox index ed2d5abf2..561cd17ba 100644 --- a/src/lib/subsys/initialization.dox +++ b/src/lib/subsys/initialization.dox @@ -9,7 +9,7 @@ Tor has a single entry point: tor_run_main() in main.c. All the ways of starting a Tor process (ntmain.c, tor_main.c, and tor_api.c) work by invoking tor_run_main(). -The tor_run_main() function normally exits (\ref init_exceptwhen "1") by +The tor_run_main() function normally exits (@ref init_exceptwhen "1") by returning: not by calling abort() or exit(). Before it returns, it calls tor_cleanup() in shutdown.c. @@ -17,7 +17,7 @@ Conceptually, there are several stages in running Tor. 1. First, we initialize those modules that do not depend on the configuration. This happens in the first half of tor_run_main(), and the - first half of tor_init(). (\ref init_pending_refactor "2") + first half of tor_init(). (@ref init_pending_refactor "2") 2. Second, we parse the command line and our configuration, and configure systems that depend on our configuration or state. This configuration @@ -33,16 +33,16 @@ Conceptually, there are several stages in running Tor. running. -> \anchor init_exceptwhen 1. tor_run_main() _can_ terminate with a call to +> @anchor init_exceptwhen 1. tor_run_main() _can_ terminate with a call to > abort() or exit(), but only when crashing due to a bug, or when forking to > run as a daemon. -> \anchor init_pending_refactor 2. The pieces of code that I'm describing as +> @anchor init_pending_refactor 2. The pieces of code that I'm describing as > "the first part of tor_init()" and so on deserve to be functions with their > own name. I'd like to refactor them, but before I do so, there is some > slight reorganization that needs to happen. Notably, the > nt_service_parse_options() call ought logically to be later in our -> initialization sequence. See \ticket{32447} for our refactoring progress. +> initialization sequence. See @ticket{32447} for our refactoring progress. @section subsys Subsystems and initialization @@ -55,10 +55,10 @@ In simplest terms, a **subsytem** is a logically separate part of Tor that can be initialized, shut down, managed, and configured somewhat independently of the rest of the program. -To define a subsystem, we declare a `const` instance of subsys_fns_t, -describing the subsystem and a set of functions that initialize it, -deconstruct it, and so on. See the documentation for subsys_fns_t for a full -list of these functions. +The subsys_fns_t type describes a subsystem and a set of functions that +initialize it, desconstruct it, and so on. To define a subsystem, we declare +a `const` instance of subsys_fns_t. See the documentation for subsys_fns_t +for a full list of these functions. After defining a subsytem, it must be inserted in subsystem_list.c. At that point, table-driven mechanisms in subsysmgr.c will invoke its functions when diff --git a/src/lib/subsys/subsys.h b/src/lib/subsys/subsys.h index 258d060bb..324f4f294 100644 --- a/src/lib/subsys/subsys.h +++ b/src/lib/subsys/subsys.h @@ -23,10 +23,11 @@ struct config_format_t; * All callbacks are optional -- if a callback is set to NULL, the subsystem * manager will treat it as a no-op. * - * You should use c99 named-field initializers with this structure: we - * will be adding more fields, often in the middle of the structure. + * You should use c99 named-field initializers with this structure, for + * readability and safety. (There are a lot of functions here, all of them + * optional, and many of them with similar signatures.) * - * See \ref initialization for more information about initialization and + * See @ref initialization for more information about initialization and * shutdown in Tor. * * To make a new subsystem, you declare a const instance of this type, and @@ -71,7 +72,7 @@ typedef struct subsys_fns_t { /** * Connect a subsystem to the message dispatch system. * - * This function should use the macros in \refdir{lib/pubsub} to register a + * This function should use the macros in @refdir{lib/pubsub} to register a * set of messages that this subsystem may publish, and may subscribe to. * * See pubsub_macros.h for more information, and for examples.

1 0

[tor/master] doxygen: add a command for linking to our bugtracker
by nickm＠torproject.org 15 Nov '19

15 Nov '19

commit baddb30889fd281962f014614a43f323b5df6ae6 Author: Nick Mathewson <nickm(a)torproject.org> Date: Sun Nov 10 15:49:45 2019 -0500 doxygen: add a command for linking to our bugtracker --- Doxyfile.in | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Doxyfile.in b/Doxyfile.in index a087012c7..2ede04447 100644 --- a/Doxyfile.in +++ b/Doxyfile.in @@ -258,6 +258,8 @@ ALIASES = ALIASES += refdir{1}="\ref src/\1 \"\1\"" +ALIASES += ticket{1}="[ticket \1](https://bugs.torproject.org/\1)" + # This tag can be used to specify a number of word-keyword mappings (TCL only). # A mapping has the form "name=value". For example adding "class=itcl::class" # will allow you to use the command class in the itcl::class meaning.

1 0

[translation/support-portal] https://gitweb.torproject.org/translation.git/commit/?h=support-portal
by translation＠torproject.org 15 Nov '19

15 Nov '19

commit c8fb42d3baf1d57aae8547919359f3000ab3df85 Author: Translation commit bot <translation(a)torproject.org> Date: Fri Nov 15 13:53:45 2019 +0000 https://gitweb.torproject.org/translation.git/commit/?h=support-portal --- contents+es.po | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/contents+es.po b/contents+es.po index ffdcfd49f..6e3c9682d 100644 --- a/contents+es.po +++ b/contents+es.po @@ -6570,7 +6570,9 @@ msgstr "" #: https//support.torproject.org/misc/glossary/ #: (content/misc/glossary/contents+en.lrquestion.description) msgid "[Tor Browser](#tor-browser) prevents fingerprinting." -msgstr "[Navegador Tor](#tor-browser) previene la toma de huellas ." +msgstr "" +"[Navegador Tor](#tor-browser) previene que se genere una huella digital " +"diferente para cada usuario." #: https//support.torproject.org/misc/glossary/ #: (content/misc/glossary/contents+en.lrquestion.description) @@ -6585,7 +6587,7 @@ msgid "" msgstr "" "Un historial de navegación es un registro de las solicitudes realizadas " "durante el uso de un [navegador](#web-browser), e incluye información tal " -"como los sitios web visitados y cuándo." +"como qué sitios web se han visitado y cuándo." #: https//support.torproject.org/misc/glossary/ #: (content/misc/glossary/contents+en.lrquestion.description)

1 0

[translation/support-portal] https://gitweb.torproject.org/translation.git/commit/?h=support-portal
by translation＠torproject.org 15 Nov '19

15 Nov '19

commit 5461fbd14101e1406994c2d592b21bd75cc6346e Author: Translation commit bot <translation(a)torproject.org> Date: Fri Nov 15 13:23:38 2019 +0000 https://gitweb.torproject.org/translation.git/commit/?h=support-portal --- contents+es.po | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/contents+es.po b/contents+es.po index 591dca905..ffdcfd49f 100644 --- a/contents+es.po +++ b/contents+es.po @@ -6584,7 +6584,7 @@ msgid "" "](#web-browser), and includes information like websites visited and when." msgstr "" "Un historial de navegación es un registro de las solicitudes realizadas " -"durante el uso de un [web browser](#web-browser), e incluye información tal " +"durante el uso de un [navegador](#web-browser), e incluye información tal " "como los sitios web visitados y cuándo." #: https//support.torproject.org/misc/glossary/ @@ -7401,7 +7401,7 @@ msgid "" "the window, which allows you to control the [JavaScript](#javascript)that " "runs on individual web pages, or to block it entirely." msgstr "" -"[Navegador Tor](#tor-browser) incluye un [add-on](#add-on-extension-or-" +"El [Navegador Tor](#tor-browser) incluye un [add-on](#add-on-extension-or-" "plugin) llamado NoScript, al que se accede a través del icono \"S\" en la " "parte superior izquierda de la ventana, que te permite controlar el " "[JavaScript](#javascript) que se ejecuta en páginas web individuales, o " @@ -7942,7 +7942,7 @@ msgid "" msgstr "" "Una sesión se refiere a una conversación entre dos dispositivos que se " "comunican en una red. Usar [Navegador Tor](#tor-browser) significa que se " -"borraran los datos de tu sesión cuando cierres el [web browser](#web-" +"borrarán los datos de tu sesión cuando cierres el [web browser](#web-" "browser)." #: https//support.torproject.org/misc/glossary/

1 0

[translation/tpo-web_completed] https://gitweb.torproject.org/translation.git/commit/?h=tpo-web_completed
by translation＠torproject.org 15 Nov '19

15 Nov '19

commit db58e0975b8bee0cbe436dabb5c3b3aeef50209f Author: Translation commit bot <translation(a)torproject.org> Date: Fri Nov 15 13:23:06 2019 +0000 https://gitweb.torproject.org/translation.git/commit/?h=tpo-web_completed --- contents+es.po | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/contents+es.po b/contents+es.po index 91c366d3d..1c76c6291 100644 --- a/contents+es.po +++ b/contents+es.po @@ -152,11 +152,11 @@ msgstr "Dona Ahora" #: https//www.torproject.org/about/trademark/ #: (content/about/trademark/contents+en.lrtrademark.title) msgid "Trademark" -msgstr "" +msgstr "Marca registrada" #: https//www.torproject.org/menu/ (content/menu/contents+en.lrpage.body) msgid "Community" -msgstr "" +msgstr "Comunidad" #: https//www.torproject.org/thank-you/ #: (content/thank-you/contents+en.lrpage.title)

1 0

[tor/master] copy 0.4.2.4-rc changelog to master
by nickm＠torproject.org 15 Nov '19

15 Nov '19

commit 7aaa4ae3031aff2d84a24abb4522f77b91e4ea53 Author: Nick Mathewson <nickm(a)torproject.org> Date: Fri Nov 15 08:14:43 2019 -0500 copy 0.4.2.4-rc changelog to master --- ChangeLog | 58 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 58 insertions(+) diff --git a/ChangeLog b/ChangeLog index 594f11ff9..1f23fa1cf 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,61 @@ +Changes in version 0.4.2.4-rc - 2019-11-15 + Tor 0.4.2.4-rc is the first release candidate in its series. It fixes + several bugs from earlier versions, including a few that would result in + stack traces or incorrect behavior. + + o Minor features (build system): + - Make pkg-config use --prefix when cross-compiling, if + PKG_CONFIG_PATH is not set. Closes ticket 32191. + + o Minor features (geoip): + - Update geoip and geoip6 to the November 6 2019 Maxmind GeoLite2 + Country database. Closes ticket 32440. + + o Minor bugfixes (client, onion service v3): + - Fix a BUG() assertion that occurs within a very small race window + between when a client intro circuit opens and when its descriptor + gets cleaned up from the cache. The circuit is now closed early, + which will trigger a re-fetch of the descriptor and continue the + connection. Fixes bug 28970; bugfix on 0.3.2.1-alpha. + + o Minor bugfixes (code quality): + - Fix "make check-includes" so it runs correctly on out-of-tree + builds. Fixes bug 31335; bugfix on 0.3.5.1-alpha. + + o Minor bugfixes (configuration): + - Log the option name when skipping an obsolete option. Fixes bug + 32295; bugfix on 0.4.2.1-alpha. + + o Minor bugfixes (crash): + - When running Tor with an option like --verify-config or + --dump-config that does not start the event loop, avoid crashing + if we try to exit early because of an error. Fixes bug 32407; + bugfix on 0.3.3.1-alpha. + + o Minor bugfixes (directory): + - When checking if a directory connection is anonymous, test if the + circuit was marked for close before looking at its channel. This + avoids a BUG() stacktrace if the circuit was previously closed. + Fixes bug 31958; bugfix on 0.4.2.1-alpha. + + o Minor bugfixes (shellcheck): + - Fix minor shellcheck errors in the git-*.sh scripts. Fixes bug + 32402; bugfix on 0.4.2.1-alpha. + - Start checking most scripts for shellcheck errors again. Fixes bug + 32402; bugfix on 0.4.2.1-alpha. + + o Testing (continuous integration): + - Use Ubuntu Bionic images for our Travis CI builds, so we can get a + recent version of coccinelle. But leave chutney on Ubuntu Trusty, + until we can fix some Bionic permissions issues (see ticket + 32240). Related to ticket 31919. + - Install the mingw OpenSSL package in Appveyor. This makes sure + that the OpenSSL headers and libraries match in Tor's Appveyor + builds. (This bug was triggered by an Appveyor image update.) + Fixes bug 32449; bugfix on 0.3.5.6-rc. + - In Travis, use Xcode 11.2 on macOS 10.14. Closes ticket 32241. + + Changes in version 0.4.2.3-alpha - 2019-10-24 This release fixes several bugs from the previous alpha release, and from earlier versions of Tor.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-commits November 2019