Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2013-12-17T18:47:44Zhttps://gitlab.torproject.org/legacy/trac/-/issues/10421gnutls_handshake() failed after using Tor Browser2013-12-17T18:47:44ZTracgnutls_handshake() failed after using Tor BrowserAfter using Tor Browser, I can't use apt-get update and git pull. I downloaded Tor Browser source(I didn't install it) and opened it and used it. After using Tor browser I've noticed that I can't use git pull and apt-get update because o...After using Tor Browser, I can't use apt-get update and git pull. I downloaded Tor Browser source(I didn't install it) and opened it and used it. After using Tor browser I've noticed that I can't use git pull and apt-get update because of this error:
gnutls_handshake() failed: A TLS packet with unexpected length was received.
Err https://private-ppa.launchpad.net precise/main i386 Packages
I've even changed gnutls to openssl but it still didn't work.
Unknown SSL protocol error in connection to gerrit.wikimedia.org:443 while accessing https://gerrit.wikimedia.org/r/p/mediawiki/core.git/info/refs
fatal: HTTP request failed
I stopped Tor and restarted my computer but nothing fixed.
Ubutnu 64bit 12.04
Vidalia 0.2.21
Tor 0.2.3.25
**Trac**:
**Username**: omidhTor: 0.2.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/9077tor cant instsll in linux2013-06-16T16:40:36ZTractor cant instsll in linuxHello sir , i triad install tor in my vps linux , And i got error , someting like :
-------------------------------
root@vps [/etc/yum.repos.d]# yum install tor
Loaded plugins: fastestmirror ...Hello sir , i triad install tor in my vps linux , And i got error , someting like :
-------------------------------
root@vps [/etc/yum.repos.d]# yum install tor
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
* addons: mirrors.greenmountainaccess.net
* base: centos.mirrors.tds.net
* extras: mirror.ubiquityservers.com
* updates: yum.singlehop.com
http://deb.torproject.org/torproject.org/rpm/centos5/repodata/repomd.xml: [Errno
14] HTTP Error 404: Not Found
Trying other mirror.
Error: Cannot retrieve repository metadata (repomd.xml) for repository: torproje
ct. Please verify its path and try again
------------------------------------------
How to resolve these issue ?
B/R
**Trac**:
**Username**: a3lanjoTor: 0.2.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/9020Update to June GeoIP database2020-06-13T14:29:35ZKarsten LoesingUpdate to June GeoIP databasePlease review my branch [geoip-jun2013](https://gitweb.torproject.org/karsten/tor.git/shortlog/refs/heads/geoip-jun2013) and merge it into maint-0.2.2 and subsequent maintained branches.
Also, please merge my branch [geoip-manual-update...Please review my branch [geoip-jun2013](https://gitweb.torproject.org/karsten/tor.git/shortlog/refs/heads/geoip-jun2013) and merge it into maint-0.2.2 and subsequent maintained branches.
Also, please merge my branch [geoip-manual-update-jun2013](https://gitweb.torproject.org/karsten/tor.git/shortlog/refs/heads/geoip-manual-update-jun2013) into master. MaxMind removed a couple 'A1' ranges that we don't have to fix manually anymore.Tor: 0.2.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/8868Update to May GeoIP database2020-06-13T14:29:07ZKarsten LoesingUpdate to May GeoIP databasePlease review my branch [geoip-may2013](https://gitweb.torproject.org/karsten/tor.git/shortlog/refs/heads/geoip-may2013) and merge it into maint-0.2.2 and subsequent maintained branches.
Also, please merge my branch [geoip-manual-update...Please review my branch [geoip-may2013](https://gitweb.torproject.org/karsten/tor.git/shortlog/refs/heads/geoip-may2013) and merge it into maint-0.2.2 and subsequent maintained branches.
Also, please merge my branch [geoip-manual-update-may2013](https://gitweb.torproject.org/karsten/tor.git/shortlog/refs/heads/geoip-manual-update-may2013) into master. MaxMind changed a couple 'A1' ranges that the automatic substitution algorithm couldn't fix and that I had to fix manually. I also tweaked the cleanup script to catch more cases when our manual substitutions need an update.Tor: 0.2.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/8661Update to April GeoIP database2020-06-13T14:28:35ZKarsten LoesingUpdate to April GeoIP databasePlease review my branch [geoip-apr2013](https://gitweb.torproject.org/karsten/tor.git/shortlog/refs/heads/geoip-apr2013) and merge it into maint-0.2.2 and subsequent maintained branches.
Also, please merge my branch [geoip-manual-update...Please review my branch [geoip-apr2013](https://gitweb.torproject.org/karsten/tor.git/shortlog/refs/heads/geoip-apr2013) and merge it into maint-0.2.2 and subsequent maintained branches.
Also, please merge my branch [geoip-manual-update-apr2013](https://gitweb.torproject.org/karsten/tor.git/shortlog/refs/heads/geoip-manual-update-apr2013) into master. MaxMind changed twelve 'A1' ranges that the automatic substitution algorithm couldn't fix and that I had to fix manually.Tor: 0.2.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/8429Update to March GeoIP database2020-06-13T14:28:05ZKarsten LoesingUpdate to March GeoIP databasePlease review my branch [geoip-mar2013](https://gitweb.torproject.org/karsten/tor.git/shortlog/refs/heads/geoip-mar2013) and merge it into maint-0.2.2 and subsequent maintained branches.
Also, please merge my branch [geoip-manual-update...Please review my branch [geoip-mar2013](https://gitweb.torproject.org/karsten/tor.git/shortlog/refs/heads/geoip-mar2013) and merge it into maint-0.2.2 and subsequent maintained branches.
Also, please merge my branch [geoip-manual-update-mar2013](https://gitweb.torproject.org/karsten/tor.git/shortlog/refs/heads/geoip-manual-update-mar2013) into master. MaxMind added fourteen new 'A1' ranges that the automatic substitution algorithm couldn't fix and that I had to fix manually.Tor: 0.2.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/8186Update to February GeoIP database2020-06-13T14:27:17ZKarsten LoesingUpdate to February GeoIP databasePlease review my branch [geoip-feb2013](https://gitweb.torproject.org/karsten/tor.git/shortlog/refs/heads/geoip-feb2013) and merge it into maint-0.2.2 and subsequent maintained branches.
Also, please merge my branch [geoip-manual-update...Please review my branch [geoip-feb2013](https://gitweb.torproject.org/karsten/tor.git/shortlog/refs/heads/geoip-feb2013) and merge it into maint-0.2.2 and subsequent maintained branches.
Also, please merge my branch [geoip-manual-update](https://gitweb.torproject.org/karsten/tor.git/shortlog/refs/heads/geoip-manual-update) into master. MaxMind took out an erroneous assignment range in their latest database, so we don't have to correct that anymore. There's a comment in that file saying this, so not worth a ChangeLog entry, IMO.Tor: 0.2.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/7863Update to January GeoIP database2020-06-13T14:26:11ZKarsten LoesingUpdate to January GeoIP databasePlease review my branch [geoip-jan2013](https://gitweb.torproject.org/karsten/tor.git/shortlog/refs/heads/geoip-jan2013) and merge it into maint-0.2.2 and subsequent maintained branches.Please review my branch [geoip-jan2013](https://gitweb.torproject.org/karsten/tor.git/shortlog/refs/heads/geoip-jan2013) and merge it into maint-0.2.2 and subsequent maintained branches.Tor: 0.2.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/7692Backport A1-less GeoIP database2020-06-13T14:25:30ZKarsten LoesingBackport A1-less GeoIP databaseWe should backport the new A1-less GeoIP database file that got recently merged into master (#6266) to previous maintained branches. Two questions:
- Should we only backport changes to the geoip file ([35d09dd](https://gitweb.torproje...We should backport the new A1-less GeoIP database file that got recently merged into master (#6266) to previous maintained branches. Two questions:
- Should we only backport changes to the geoip file ([35d09dd](https://gitweb.torproject.org/tor.git/commit/35d09dd), [c718921](https://gitweb.torproject.org/tor.git/commit/c718921)), or should we also include the deanonymind.py script, manual assignment overrides in geoip-manual, and README.geoip ([2bf195d](https://gitweb.torproject.org/tor.git/commit/2bf195d)) explaining how we created that new geoip file?
- Should we backport geoip updates to all previous maintained branches (including 0.2.2.x), or will that make package maintainers sad?
Once I know what to backport, I can prepare a branch.Tor: 0.2.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/7139Tor involuntarily sets TLS session tickets2020-06-13T14:23:41ZnextgensTor involuntarily sets TLS session ticketsThis is bad for at least two reasons:
1) performance: It increases the size (~160bytes) of the ChangeCipherSpec message during the handshake; it also makes the server encrypt and hmac the ticket
2) security: It has implications regardi...This is bad for at least two reasons:
1) performance: It increases the size (~160bytes) of the ChangeCipherSpec message during the handshake; it also makes the server encrypt and hmac the ticket
2) security: It has implications regarding the PFS interval (no immediate security concern here as the server certificates are ephemeral; MAX_SSL_KEY_LIFETIME_INTERNAL = 2h atm) and exposes more attack surface than strictly necessary (Tor doesn't use the tickets in any case: that's why it disables the session-cache)
To disable session-tickets altogether (TLS1+ feature), one should use:
SSL_CTX_set_options(... , ...|SSL_OP_NO_TICKET)Tor: 0.2.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/7131Tor Ignores Exit nodes2020-06-13T14:23:40ZTracTor Ignores Exit nodesHello
I'm using Vidalia 0.2.20 and Tor 0.2.2.39 . I need to get an IP address of specificc country only (UK). Here is my torrc file:
AvoidDiskWrites 1
ControlPort 9051
DataDirectory C:/Users/Laptop/Downloads/Tor Browser/Data/Tor
DirReq...Hello
I'm using Vidalia 0.2.20 and Tor 0.2.2.39 . I need to get an IP address of specificc country only (UK). Here is my torrc file:
AvoidDiskWrites 1
ControlPort 9051
DataDirectory C:/Users/Laptop/Downloads/Tor Browser/Data/Tor
DirReqStatistics 0
ExitNodes YoureOnCCTV,TorLand2,st0nerhenge,c00psTOR,EnfluraneNode,TorShub
GeoIPFile .\Data\Tor\geoip
HashedControlPassword 16:01E9EBA51F15EF2D60117897AE951A21F06EF564F2606C2E6339C4A8D1
Log notice stdout
SocksListenAddress 127.0.0.1
StrictNodes 1
Exitnodes are only UK relays. And I also have strictNodes 1.
But when Start the Tor, it connects to all other relays like normally, and picks a random country. Why does it ignore ExitNodes?
**Trac**:
**Username**: yuriyTor: 0.2.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/7018Reporting Error Log Entry: Tried to set up a relay bridge2013-03-11T17:52:18ZcypherpunksReporting Error Log Entry: Tried to set up a relay bridgeI was selecting "help censored users use the tor network" and received the following error:
[Tue Oct 2 13:35:49 2012] Tor Software Error - The Tor software encountered an internal bug. Please report the following error message to the To...I was selecting "help censored users use the tor network" and received the following error:
[Tue Oct 2 13:35:49 2012] Tor Software Error - The Tor software encountered an internal bug. Please report the following error message to the Tor developers at bugs.torproject.org: "set_options(): Bug: Acting on config options left us in a broken state. Dying.
Linux Macmini 3.2.0-23-generic !#36-Ubuntu SMP Tue Apr 10 !20:41:14 UTC 2012 i686 i686 i386 GNU/LinuxTor: 0.2.2.x-finalErinn ClarkErinn Clarkhttps://gitlab.torproject.org/legacy/trac/-/issues/6984use after free crash after "eventdns rejected address [scrubbed]"2020-06-13T14:23:10ZTracuse after free crash after "eventdns rejected address [scrubbed]"Running multiple tor nodes, they crash multiple times per day. The only thing in the logfile is:
Sep 27 12:08:34.784 [warn] eventdns rejected address [scrubbed]
I enabled debugging and MALLOC_OPTIONS on OpenBSD and got the following:
...Running multiple tor nodes, they crash multiple times per day. The only thing in the logfile is:
Sep 27 12:08:34.784 [warn] eventdns rejected address [scrubbed]
I enabled debugging and MALLOC_OPTIONS on OpenBSD and got the following:
Sep 27 12:08:34.783 [debug] int connection_edge_process_relay_cell(cell_t *, circuit_t *, edge_connection_t *, crypt_path_t *)(): circ-level sendme at non-o
, packagewindow 526.
Sep 27 12:08:34.783 [debug] void circuit_resume_edge_reading(circuit_t *, crypt_path_t *)(): resuming
Sep 27 12:08:34.783 [debug] int connection_or_process_cells_from_inbuf(or_connection_t *)(): 53: starting, inbuf_datalen 0 (0 pending in tls object).
Sep 27 12:08:34.783 [debug] void conn_write_callback(int, short, void *)(): socket 1117 wants to write.
Sep 27 12:08:34.784 [debug] int flush_chunk_tls(tor_tls_t *, buf_t *, chunk_t *, size_t, size_t *)(): flushed 512 bytes, 0 ready to flush, 0 remain.
Sep 27 12:08:34.784 [debug] int connection_handle_write_impl(connection_t *, int)(): After TLS write of 512: 0 read, 586 written
Sep 27 12:08:34.784 [debug] int connection_or_flush_from_first_active_circuit(or_connection_t *, int, time_t)(): Made a circuit inactive.
Sep 27 12:08:34.784 [debug] void conn_read_callback(int, short, void *)(): socket 53 wants to read.
Sep 27 12:08:34.784 [debug] int connection_read_to_buf(connection_t *, ssize_t *, int *)(): 53: starting, inbuf_datalen 0 (0 pending in tls object). at_most
4.
Sep 27 12:08:34.784 [debug] int connection_read_to_buf(connection_t *, ssize_t *, int *)(): After TLS read of 512: 549 read, 0 written
Sep 27 12:08:34.784 [debug] int connection_or_process_cells_from_inbuf(or_connection_t *)(): 53: starting, inbuf_datalen 512 (0 pending in tls object).
Sep 27 12:08:34.784 [debug] int circuit_receive_relay_cell(cell_t *, circuit_t *, cell_direction_t)(): Sending away from origin.
Sep 27 12:08:34.784 [debug] int connection_edge_process_relay_cell(cell_t *, circuit_t *, edge_connection_t *, crypt_path_t *)(): Now seen 33189527 relay ce
ere (command 1, stream 39854).
Sep 27 12:08:34.784 [debug] int connection_exit_begin_conn(cell_t *, circuit_t *)(): Creating new exit connection.
Sep 27 12:08:34.784 [debug] int connection_exit_begin_conn(cell_t *, circuit_t *)(): about to start the dns_resolve().
Sep 27 12:08:34.784 [debug] int dns_resolve_impl(edge_connection_t *, int, or_circuit_t *, char **)(): Launching [scrubbed].
Sep 27 12:08:34.784 [info] int launch_resolve(edge_connection_t *)(): Launching eventdns request for [scrubbed]
Sep 27 12:08:34.784 [info] eventdns: Resolve requested.
Sep 27 12:08:34.784 [warn] eventdns rejected address [scrubbed].
Sep 27 12:08:34.784 [debug] void dns_cancel_pending_resolve(const char *)(): Failing all connections waiting on DNS resolve of [scrubbed]
Sep 27 12:08:34.784 [debug] int connection_edge_end(edge_connection_t *, uint8_t)(): No circ to send end on conn (fd -1).
Sep 27 12:08:34.784 [debug] int relay_send_command_from_edge(streamid_t, circuit_t *, uint8_t, const char *, size_t, crypt_path_t *)(): delivering 3 cell ba
d.
Sep 27 12:08:34.784 [debug] void append_cell_to_circuit_queue(circuit_t *, or_connection_t *, cell_t *, cell_direction_t, streamid_t)(): Made a circuit acti
Sep 27 12:08:34.784 [debug] void append_cell_to_circuit_queue(circuit_t *, or_connection_t *, cell_t *, cell_direction_t, streamid_t)(): Primed a buffer.
Sep 27 12:08:34.784 [debug] int connection_or_flush_from_first_active_circuit(or_connection_t *, int, time_t)(): Made a circuit inactive.
Sep 27 12:08:34.784 [debug] int connection_or_process_cells_from_inbuf(or_connection_t *)(): 53: starting, inbuf_datalen 0 (0 pending in tls object).
Sep 27 12:08:34.784 [debug] void conn_write_callback(int, short, void *)(): socket 1117 wants to write.
tor in free(): error: chunk is already free 0x202974900
Abort trap
I do not have a core.
**Trac**:
**Username**: dhillTor: 0.2.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/6811Crash bug in tor_timegm2020-06-13T17:59:32ZNick MathewsonCrash bug in tor_timegmIt looks like the assertion in tor_timegm is triggerable with bad inputs, according to asn. That's no good: we call it on untrusted inputs from directory objects.
Latest version of my preferred fix is in branch "timegm_assert_v2". It ...It looks like the assertion in tor_timegm is triggerable with bad inputs, according to asn. That's no good: we call it on untrusted inputs from directory objects.
Latest version of my preferred fix is in branch "timegm_assert_v2". It needs a little cleanup and a changes file. It might not be minimal.Tor: 0.2.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/6690compare_tor_addr_to_addr_policy assertion error2020-06-13T14:22:03ZTraccompare_tor_addr_to_addr_policy assertion errorOccasionally, usually after tor fetches its directory microdescriptors or when I "wake" tor up after a long time of inactivity, I get the following error:
compare_tor_addr_to_addr_policy(): Bug: policies.c:716: compare_tor_addr_to_addr...Occasionally, usually after tor fetches its directory microdescriptors or when I "wake" tor up after a long time of inactivity, I get the following error:
compare_tor_addr_to_addr_policy(): Bug: policies.c:716: compare_tor_addr_to_addr_policy: Assertion port != 0 failed; aborting.
After which tor exits. This didn't happen before (and I have been with this version of tor for a long time), though I've had this error twice in a week now, so thought to report it.
**Trac**:
**Username**: mr-4Tor: 0.2.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/6657tor 0.2.2.38 release notes list extra item2020-06-13T14:21:58Zweasel (Peter Palfrader)tor 0.2.2.38 release notes list extra itemThe release notes of 0.2.2.38 say, among other things:
```
- Avoid read-from-freed-memory and double-free bugs that could occur
when a DNS request fails while launching it. Fixes bug 6480;
bugfix on 0.2.0.1-alpha.
```
However,...The release notes of 0.2.2.38 say, among other things:
```
- Avoid read-from-freed-memory and double-free bugs that could occur
when a DNS request fails while launching it. Fixes bug 6480;
bugfix on 0.2.0.1-alpha.
```
However, that change was not part of 0.2.2.38, so the corresponding entry should be removed from changelog and release notes.Tor: 0.2.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/6537Possible timing side-channel in router selection2020-06-13T14:21:44ZNick MathewsonPossible timing side-channel in router selectionRobert Ransom found a possible timing side-channel in how we select routers by bandwidth: we finish faster if we're selecting a router earlier in the list than we do if we select a router later in the list. If this timing information is...Robert Ransom found a possible timing side-channel in how we select routers by bandwidth: we finish faster if we're selecting a router earlier in the list than we do if we select a router later in the list. If this timing information is available on the wire, it could be used to tell which nodes a client is selecting based on how long it takes to pick them.
This is probably not an end-of-the-world attack, since:
* There is a lot of noise in client timing information, especially in this case, since after picking a circuit we do a bunch of crypto, pk, and network ops too.
* For exit nodes at least, we pick them at circuit_establish_circuit(), before we send any data to the network.
* The timing information isn't likely to be finegrained enough to leak particular nodes; rather, if it is available at all, it is likelier to leak which general segment of the node list was selected.
Nevertheless, this isn't something we should even risk exposing, and there might be other factors here too that I'm not analyzing right. Better safe than sorry. Let's fix this one.Tor: 0.2.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/6530Out-of-bounds read in networkstatus_parse_vote_from_string()2020-06-13T14:21:44ZGeorge KadianakisOut-of-bounds read in networkstatus_parse_vote_from_string()```
tok = find_by_keyword(tokens, K_NETWORK_STATUS_VERSION);
tor_assert(tok);
if (tok->n_args > 1) {
int flavor = networkstatus_parse_flavor_name(tok->args[1]);
if (flavor < 0) {
log_warn(LD_DIR, "Can't parse document...```
tok = find_by_keyword(tokens, K_NETWORK_STATUS_VERSION);
tor_assert(tok);
if (tok->n_args > 1) {
int flavor = networkstatus_parse_flavor_name(tok->args[1]);
if (flavor < 0) {
log_warn(LD_DIR, "Can't parse document with unknown flavor %s",
escaped(tok->args[2]));
goto err;
}
ns->flavor = flav = flavor;
}
```
`networkstatus_parse_vote_from_string()` validates the **second**
argument of `network-status-version` which is the flavor of the
consensus. If the flavor is invalid it log_warn()s the **third**
argument which is not guaranteed to exist. This means that `escaped()` receives a non-allocated section of memory as its argument and treats it as a pointer to a string; this should lead to a segfault.Tor: 0.2.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/6221Review every commit of Sebastian2020-06-13T14:20:36ZcypherpunksReview every commit of SebastianHe introduced many backdoors that looking like stupid bug for clueless person. Once he introduced crash bug around ipv6 stuff for dirauth, and next to claims bugfix on another version like it wasn't his bug that leads to crashes.He introduced many backdoors that looking like stupid bug for clueless person. Once he introduced crash bug around ipv6 stuff for dirauth, and next to claims bugfix on another version like it wasn't his bug that leads to crashes.Tor: 0.2.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/6220Review every commit of weasel2020-06-13T14:20:36ZcypherpunksReview every commit of weaselYou should to review commits. I assume it has backdoor.You should to review commits. I assume it has backdoor.Tor: 0.2.2.x-final