Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T14:05:12Zhttps://gitlab.torproject.org/legacy/trac/-/issues/1709Fix compilation with mingw and OpenSSL 0.9.8m+2020-06-13T14:05:12ZTracFix compilation with mingw and OpenSSL 0.9.8m+--- tortls.c.was Tue Jul 13 01:37:00 2010
+++ tortls.c Mon Jul 19 19:17:42 2010
@@ -21,6 +21,17 @@
#endif
#include <assert.h>
+#ifdef MS_WINDOWS /*wrkard for dtls1.h >= 0.9.8m of "#include <winsock.h>"*/
+ #define WIN32_WINNT 0x400
+...--- tortls.c.was Tue Jul 13 01:37:00 2010
+++ tortls.c Mon Jul 19 19:17:42 2010
@@ -21,6 +21,17 @@
#endif
#include <assert.h>
+#ifdef MS_WINDOWS /*wrkard for dtls1.h >= 0.9.8m of "#include <winsock.h>"*/
+ #define WIN32_WINNT 0x400
+ #define _WIN32_WINNT 0x400
+ #define WIN32_LEAN_AND_MEAN
+ #if defined(_MSC_VER) && (_MSC_VER < 1300)
+ #include <winsock.h>
+ #else
+ #include <winsock2.h>
+ #include <ws2tcpip.h>
+ #endif
+#endif
#include <openssl/ssl.h>
#include <openssl/ssl3.h>
#include <openssl/err.h>
**Trac**:
**Username**: mingw-sanTor: 0.2.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/1715Remove old unused win code.2020-06-13T14:05:13ZTracRemove old unused win code.After 8d31141ccbdbeee9589d04ea99819af7aa35193b no more chance for non WinNT platforms. Moreover no was chances for dns stuff. Guess CE have more Tor users than 9x/Me.
--- eventdns.c.was Tue May 25 04:57:58 2010
+++ eventdns.c Tue Jul 20 ...After 8d31141ccbdbeee9589d04ea99819af7aa35193b no more chance for non WinNT platforms. Moreover no was chances for dns stuff. Guess CE have more Tor users than 9x/Me.
--- eventdns.c.was Tue May 25 04:57:58 2010
+++ eventdns.c Tue Jul 20 13:00:56 2010
@@ -3227,7 +3227,6 @@
}
#define SERVICES_KEY L"System\\CurrentControlSet\\Services\\"
-#define WIN_NS_9X_KEY SERVICES_KEY L"VxD\\MSTCP"
#define WIN_NS_NT_KEY SERVICES_KEY L"Tcpip\\Parameters"
static int
@@ -3269,16 +3268,6 @@
TRY(interfaces_key, "DhcpNameServer");
RegCloseKey(interfaces_key);
RegCloseKey(nt_key);
- } else {
- HKEY win_key = 0;
- if (RegOpenKeyExW(HKEY_LOCAL_MACHINE, WIN_NS_9X_KEY, 0,
- KEY_READ, &win_key) != ERROR_SUCCESS) {
- log(EVDNS_LOG_DEBUG, "Couldn't open registry key, %d", (int)GetLastError());
- return -1;
- }
- TRY(win_key, "NameServer");
- RegCloseKey(win_key);
- }
if (found == 0) {
log(EVDNS_LOG_WARN,"Didn't find any nameservers.");
Amen.
**Trac**:
**Username**: mingw-sanNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/1789Wake-up from Hibernation Occurs Day 1 Each Month2020-06-13T14:05:41ZTracWake-up from Hibernation Occurs Day 1 Each MonthThis is happening on several relays, on both 64-bit and 32-bit CentOS Linux.
Apr 18 12:48:15.014 [notice] Configured hibernation. This interval begins at 2010-04-18 00:00:00 and ends at 2010-04-19 00:00:00. We have no prior estimate f...This is happening on several relays, on both 64-bit and 32-bit CentOS Linux.
Apr 18 12:48:15.014 [notice] Configured hibernation. This interval begins at 2010-04-18 00:00:00 and ends at 2010-04-19 00:00:00. We have no prior estimate for bandwidth, so we will start out awake and hibernate when we exhaust our quota.
Apr 18 13:04:04.244 [notice] Configured hibernation. This interval begins at 2010-04-18 00:00:00 and ends at 2010-04-19 00:00:00. We have no prior estimate for bandwidth, so we will start out awake and hibernate when we exhaust our quota.
Apr 19 00:00:00.995 [notice] Configured hibernation. This interval began at 2010-04-19 00:00:00; the scheduled wake-up time was 2010-04-19 00:00:00; we expect to exhaust our quota for this interval around 2010-04-20 00:00:00; the next interval begins at 2010-04-20 00:00:00 (all times local)
Apr 19 10:55:19.797 [notice] Configured hibernation. This interval began at 2010-04-01 00:00:00; the scheduled wake-up time was 2010-04-01 00:00:00; we expect to exhaust our quota for this interval around 2010-05-01 00:00:00; the next interval begins at 2010-05-01 00:00:00 (all times local)
Apr 21 01:39:36.221 [notice] Configured hibernation. This interval began at 2010-04-01 00:00:00; the scheduled wake-up time was 2010-04-01 00:00:00; we expect to exhaust our quota for this interval around 2010-05-01 00:00:00; the next interval begins at 2010-05-01 00:00:00 (all times local)
Apr 22 21:11:26.494 [notice] Configured hibernation. This interval began at 2010-04-01 00:00:00; the scheduled wake-up time was 2010-04-01 00:00:00; we expect to exhaust our quota for this interval around 2010-05-01 00:00:00; the next interval begins at 2010-05-01 00:00:00 (all times local)
Apr 24 22:00:39.128 [notice] Configured hibernation. This interval began at 2010-04-01 00:00:00; the scheduled wake-up time was 2010-04-01 00:00:00; we expect to exhaust our quota for this interval around 2010-05-01 00:00:00; the next interval begins at 2010-05-01 00:00:00 (all times local)
Apr 25 01:37:16.835 [notice] Configured hibernation. This interval began at 2010-04-01 00:00:00; the scheduled wake-up time was 2010-04-03 20:22:28; we expect to exhaust our quota for this interval around 2010-04-27 11:45:28; the next interval begins at 2010-05-01 00:00:00 (all times local)
Apr 27 09:33:10.377 [notice] Bandwidth soft limit reached; commencing hibernation.
May 01 00:00:00.636 [notice] Configured hibernation. This interval began at 2010-05-01 00:00:00; the scheduled wake-up time is 2010-05-06 15:25:09; we expect to exhaust our quota for this interval around 2010-05-18 16:29:09; the next interval begins at 2010-06-01 00:00:00 (all times local)
May 01 00:00:00.667 [notice] Accounting period ended. Commencing hibernation until 2010-05-06 15:25:09 GMT
May 02 19:38:30.791 [notice] Configured hibernation. This interval began at 2010-05-01 00:00:00; the scheduled wake-up time is 2010-05-06 15:25:09; we expect to exhaust our quota for this interval around 2010-05-18 16:29:09; the next interval begins at 2010-06-01 00:00:00 (all times local)
May 02 19:38:31.263 [notice] Commencing hibernation. We will wake up at 2010-05-06 15:25:09 local time.
May 06 15:25:09.423 [notice] Hibernation period ended. Resuming normal activity.
May 08 22:06:49.155 [notice] Bandwidth soft limit reached; commencing hibernation.
Jun 01 00:00:00.981 [notice] Configured hibernation. This interval began at 2010-06-01 00:00:00; the scheduled wake-up time was 2010-06-01 00:00:00; we expect to exhaust our quota for this interval around 2010-07-01 00:00:00; the next interval begins at 2010-07-01 00:00:00 (all times local)
Jun 01 00:00:01.052 [notice] Hibernation period ended. Resuming normal activity.
Jun 02 10:59:45.826 [notice] Configured hibernation. This interval began at 2010-06-01 00:00:00; the scheduled wake-up time was 2010-06-01 00:00:00; we expect to exhaust our quota for this interval around 2010-07-01 00:00:00; the next interval begins at 2010-07-01 00:00:00 (all times local)
Jun 05 07:24:03.517 [notice] Bandwidth soft limit reached; commencing hibernation.
Jun 07 00:39:45.337 [notice] Configured hibernation. This interval began at 2010-06-01 00:00:00; the scheduled wake-up time was 2010-06-01 00:00:00; we expect to exhaust our quota for this interval around 2010-07-01 00:00:00; the next interval begins at 2010-07-01 00:00:00 (all times local)
Jun 07 00:39:46.019 [notice] Bandwidth soft limit reached; commencing hibernation.
Jun 20 17:38:44.317 [notice] Configured hibernation. This interval began at 2010-06-01 00:00:00; the scheduled wake-up time was 2010-06-01 00:00:00; we expect to exhaust our quota for this interval around 2010-07-01 00:00:00; the next interval begins at 2010-07-01 00:00:00 (all times local)
Jun 20 17:38:47.640 [notice] Bandwidth soft limit reached; commencing hibernation.
Jul 01 00:00:00.388 [notice] Configured hibernation. This interval began at 2010-07-01 00:00:00; the scheduled wake-up time is 2010-07-01 04:07:55; we expect to exhaust our quota for this interval around 2010-07-31 22:47:55; the next interval begins at 2010-08-01 00:00:00 (all times local)
Jul 01 00:00:00.528 [notice] Accounting period ended. Commencing hibernation until 2010-07-01 04:07:55 GMT
Jul 01 04:07:55.607 [notice] Hibernation period ended. Resuming normal activity.
Jul 08 07:12:20.943 [notice] Bandwidth soft limit reached; commencing hibernation.
Jul 15 00:12:31.450 [notice] Configured hibernation. This interval began at 2010-07-01 00:00:00; the scheduled wake-up time was 2010-07-01 04:07:55; we expect to exhaust our quota for this interval around 2010-07-31 22:47:55; the next interval begins at 2010-08-01 00:00:00 (all times local)
Jul 15 00:12:32.688 [notice] Bandwidth soft limit reached; commencing hibernation.
Aug 01 00:00:00.152 [notice] Configured hibernation. This interval began at 2010-08-01 00:00:00; the scheduled wake-up time was 2010-08-01 00:00:00; we expect to exhaust our quota for this interval around 2010-09-01 00:00:00; the next interval begins at 2010-09-01 00:00:00 (all times local)
Aug 01 00:00:00.184 [notice] Hibernation period ended. Resuming normal activity.
**Trac**:
**Username**: BarkerJrTor: 0.2.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/3039git 29e0d708 broke LastWritten state entry2020-06-13T14:10:13ZRoger Dingledinegit 29e0d708 broke LastWritten state entryIn Tor 0.2.2.14-alpha, we added two bugs:
A) The LastWritten element of our state became the time of the *previous* time we wrote the file, rather than the time of this writing
B) When we fail to write the state file, we set LastWritte...In Tor 0.2.2.14-alpha, we added two bugs:
A) The LastWritten element of our state became the time of the *previous* time we wrote the file, rather than the time of this writing
B) When we fail to write the state file, we set LastWritten to -1, which is no good when we hand it to format_iso_time() in read_bandwidth_usage().
This bug was discovered while looking at #2077.Tor: 0.2.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/4133nodelist_assert_ok(): Bug: nodelist.c:397: nodelist_assert_ok: Assertion md->...2020-06-13T14:13:31ZTracnodelist_assert_ok(): Bug: nodelist.c:397: nodelist_assert_ok: Assertion md->held_by_node == 1 failed; aborting.[08:45:57] Tor Software Error - The Tor software encountered an internal bug. Please report the following error message to the Tor developers at bugs.torproject.org: "nodelist_assert_ok(): Bug: nodelist.c:397: nodelist_assert_ok: Asserti...[08:45:57] Tor Software Error - The Tor software encountered an internal bug. Please report the following error message to the Tor developers at bugs.torproject.org: "nodelist_assert_ok(): Bug: nodelist.c:397: nodelist_assert_ok: Assertion md->held_by_node == 1 failed; aborting.
"
**Trac**:
**Username**: yupingVidalia: 0.2.15https://gitlab.torproject.org/legacy/trac/-/issues/23501Refactor rep_hist_format_hs_stats() to add noise when counters are initialised2020-06-13T15:13:42ZteorRefactor rep_hist_format_hs_stats() to add noise when counters are initialisedThis makes the code shorter, and the security guarantees easier to reason about (it's how experimental privcount does it).
See #23414 for background.This makes the code shorter, and the security guarantees easier to reason about (it's how experimental privcount does it).
See #23414 for background.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/23061crypto_rand_double() should produce all possible outputs on platforms with 32...2020-06-13T15:16:34Zteorcrypto_rand_double() should produce all possible outputs on platforms with 32-bit intOn 32-bit platforms, crypto_rand_double() only produces 1 in every 2 million possible values between 0 and 1.
This happens because:
* crypto_rand_double() divides a random unsigned int by UINT_MAX
* an unsigned int on 32-bit platforms i...On 32-bit platforms, crypto_rand_double() only produces 1 in every 2 million possible values between 0 and 1.
This happens because:
* crypto_rand_double() divides a random unsigned int by UINT_MAX
* an unsigned int on 32-bit platforms is 32 bits
* the mantissa on a double is 53 bits
So crypto_rand_double() doesn't fill the lower 21 bits with random values.
This makes the rep_hist_format_hs_stats() noise more predictable on 32-bit platforms.
This fix shouldn't affect the unit tests, because they pass on 64-bit.Tor: unspecified