The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2022-04-05T02:28:34Zhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/20628More locales for Tor Browser2022-04-05T02:28:34ZArthur EdelsteinMore locales for Tor BrowserSeveral locales for torbutton in Transifex are fully or almost fully translated, but we aren't including these in our ./import_translations.sh script in torbutton.
And we would probably like to release some of these as Tor Browsers as w...Several locales for torbutton in Transifex are fully or almost fully translated, but we aren't including these in our ./import_translations.sh script in torbutton.
And we would probably like to release some of these as Tor Browsers as well.https://gitlab.torproject.org/tpo/core/tor/-/issues/7216networkstatus_check_consensus_signature() shouldn't warn because of missing c...2020-07-23T18:00:06ZNick Mathewsonnetworkstatus_check_consensus_signature() shouldn't warn because of missing certsIf you're first bootstrapping and enough of your certificate downloads fail at least twice, you might see something like:
> A consensus needs 5 good signatures from recognized authorities for us to accept it. This one has 0 (). It has ...If you're first bootstrapping and enough of your certificate downloads fail at least twice, you might see something like:
> A consensus needs 5 good signatures from recognized authorities for us to accept it. This one has 0 (). It has 1 signatures from authorities we don't recognize. We were unable to check 7 of the signatures, because we were missing the keys.
That's not too helpful, especially to a new user.
From IRC, with irrelevant stuff omitted:
```
19:45 < armadev> if it warns about a consensus that it might not warn about
once it has certs, and once it gets certs it checks again, it
seems that the warn is a bug
19:47 <@nickm> armadev: Hm. You're saying that if we can't verify the
consensus, and missing certs might enable us to do so, the
warnings should instead be "Hey I've tried to download
certificates and it didn't work yet, trying more?"
19:47 <@nickm> or no warning
19:48 < armadev> i was saying no warning
19:49 < armadev> assuming we later warn if we fail to fetch the certs we
wanted, and we warn if we later don't like the consensus we
can now check
19:50 <@nickm> sounds okay. May I copy+paste some of the stuff you've said to
make a new ticket, or do you want to open one?
19:50 < armadev> go for it
19:51 < armadev> this is especially relevant because the case where you don't
have the certs yet means you're probably a new user starting
tor for the first time, nervously looking at the message log
```Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/7356Make channel state test macros2020-06-27T14:05:18ZAndrea ShepardMake channel state test macrosWe check for conditions like if (!(circ->n_chan->state == CHANNEL_STATE_CLOSING || circ->n_chan->state == CHANNEL_STATE_CLOSED || circ->n_chan->state == CHANNEL_STATE_ERROR)) a lot; there should be more concise test macros.We check for conditions like if (!(circ->n_chan->state == CHANNEL_STATE_CLOSING || circ->n_chan->state == CHANNEL_STATE_CLOSED || circ->n_chan->state == CHANNEL_STATE_ERROR)) a lot; there should be more concise test macros.Tor: 0.2.6.x-finalrl1987rl1987https://gitlab.torproject.org/tpo/core/tor/-/issues/7457Add client-side log indicator that an obfsbridge works2021-06-18T18:25:22ZGeorge KadianakisAdd client-side log indicator that an obfsbridge worksBridge operators can be reasonably sure that obfsproxy works for them since they see the `Registered server transport` log message.
OTOH, clients can't be sure whether their obfsproxy works or whether they connected to a bridge with obf...Bridge operators can be reasonably sure that obfsproxy works for them since they see the `Registered server transport` log message.
OTOH, clients can't be sure whether their obfsproxy works or whether they connected to a bridge with obfsproxy.
I think we should add PT information to one of the "connected to bridge" log messages.
Specifically, to:
```
log_notice(LD_DIR, "Learned fingerprint %s for bridge %s"
```
or to
```
log_notice(LD_DIR, "new bridge descriptor '%s' (%s): %s"
```
IIUC the latter will appear in the logs everytime we connect to a bridge, even if we knew the bridge fingerprint.Alexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/7479Replace more linked lists with queue.h implementations2021-09-16T14:36:00ZNick MathewsonReplace more linked lists with queue.h implementationsWe've got linked lists scattered through our source. Now that we have a queue.h implementation, it would be neat to use that instead.
This is something we can (and should!) do piecemeal; let's not try to do it all with one big patch.We've got linked lists scattered through our source. Now that we have a queue.h implementation, it would be neat to use that instead.
This is something we can (and should!) do piecemeal; let's not try to do it all with one big patch.https://gitlab.torproject.org/tpo/tpa/gitlab-lobby/-/issues/5secrets should not be in public version control2022-05-30T19:11:49ZNick Mathewsonsecrets should not be in public version controlInstead of having the secrets put in a settings.py file, they should be in some other file that settings.py references. This other file should not be under version control in our public repository.Instead of having the secrets put in a settings.py file, they should be in some other file that settings.py references. This other file should not be under version control in our public repository.https://gitlab.torproject.org/tpo/core/tor/-/issues/7480cached_resolve_t expiration is overengineered2021-09-16T14:36:00ZNick Mathewsoncached_resolve_t expiration is overengineeredThere are two misfeatures in the way we expire pending and cached DNS requests—maybe three.
1. We schedule expiration with a priority queue. That's probably over-engineered. Instead, we could just walk the hash table periodically and ...There are two misfeatures in the way we expire pending and cached DNS requests—maybe three.
1. We schedule expiration with a priority queue. That's probably over-engineered. Instead, we could just walk the hash table periodically and remove expired entries. If we choose an appropriate interval, we shouldn't lose too much CPU to walking the hash table.
2. We can't remove or re-order entries in the priority queue before they expire. That means that when a pending cached_resolve_t gets its answers/errors and becomes done, we don't currently remove it: instead we make a copy of it to represent the done cached_resolve_t, put that in the priority queue too, and wait for the pending one to expire on its own. How silly.
3. Pending DNS requests probably don't need to be scheduled for expiration at all: we already have timeout logic in evdns.c to ensure that a DNS request that doesn't complete will get treated as an error. I don't think we need a separate means to expire them.https://gitlab.torproject.org/tpo/core/tor/-/issues/7486Divergent behavior for over-long length on begin cells2020-07-23T18:11:10ZNick MathewsonDivergent behavior for over-long length on begin cellsWhen we get some other kind of error when parsing a begin cell, we send back an end cell. But if the error is an over-long length, we do nothing and just mark the connection. That's probably not right; if it is, it should be commented....When we get some other kind of error when parsing a begin cell, we send back an end cell. But if the error is an over-long length, we do nothing and just mark the connection. That's probably not right; if it is, it should be commented.
I needed to add extra code to keep the current behavior in the ipv6_exits branch; it would be neat to rip that out.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/7590[PATCH] New option LocalOutboundBindAddress2021-06-18T18:25:22ZTrac[PATCH] New option LocalOutboundBindAddressLocalOutboundBindAddress works just like OutboundBindAddress, but instead of excluding connections to loopback addresses, it affects only connections to loopback addresses.
(This is a patch to the git head.)
[1/2] https://lists.torproj...LocalOutboundBindAddress works just like OutboundBindAddress, but instead of excluding connections to loopback addresses, it affects only connections to loopback addresses.
(This is a patch to the git head.)
[1/2] https://lists.torproject.org/pipermail/tor-dev/2012-November/004177.html
[2/2] https://lists.torproject.org/pipermail/tor-dev/2012-November/004176.html
**Trac**:
**Username**: achttps://gitlab.torproject.org/tpo/core/tor/-/issues/7730Remove doc/TODO*2020-06-27T14:05:06ZNick MathewsonRemove doc/TODO*We no longer seem to use or even look at doc/TODO in Tor; we've transitioned more or less completely to trac. All that remains to do is see if there are more entries there which we should turn into tickets, and then remove them from mas...We no longer seem to use or even look at doc/TODO in Tor; we've transitioned more or less completely to trac. All that remains to do is see if there are more entries there which we should turn into tickets, and then remove them from master.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/7755circuit_t::timestamp_dirty should be cleaned up2022-06-17T13:10:29ZRobert Ransomcircuit_t::timestamp_dirty should be cleaned up`circuit_t::timestamp_dirty` is used in multiple bizarre ways, which should be reverse-engineered, documented, and cleaned up (probably by replacing it with multiple fields, each with a name which reflects its actual meaning and/or purpo...`circuit_t::timestamp_dirty` is used in multiple bizarre ways, which should be reverse-engineered, documented, and cleaned up (probably by replacing it with multiple fields, each with a name which reflects its actual meaning and/or purpose). See also the legacy/trac#7157 review discussion.
Also, is there a good reason for it to be in `circuit_t`, not `origin_circuit_t`? (Any use of it on `or_circuit_t`s (or even on service-side rendezvous `origin_circuit_t`s) would have different semantics.)https://gitlab.torproject.org/tpo/core/tor/-/issues/7789Also display configuration file (torrc) location when running as Windows service2022-06-16T18:09:33ZTracAlso display configuration file (torrc) location when running as Windows serviceWhen normal running TOR on Windows, it prompts the reading configuration file location such as
```
Dec 23 05:31:11.523 [notice] Read configuration file "C:\Users\<USERNAME>\AppData\Roaming\tor\torrc".
```
But TOR does not prompt this lo...When normal running TOR on Windows, it prompts the reading configuration file location such as
```
Dec 23 05:31:11.523 [notice] Read configuration file "C:\Users\<USERNAME>\AppData\Roaming\tor\torrc".
```
But TOR does not prompt this location when running as Windows Service, and the torrc file is usually in a totally different location when running as service. TOR just prompt this service is started in command line.
```
D:\tor>tor --service start
Service started successfully
```
so it is hard to find which torrc file it is reading. Need a fix on this issue to make it a litter easier.
**Trac**:
**Username**: mosesofmasonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/7798Use directory guards even when consensus isn't live2021-06-18T18:21:27ZNick MathewsonUse directory guards even when consensus isn't liveOur initial directory guard implementation only works when we have a live consensus to find out the directory guards' IP addresses. So it's an improvement, but it's hardly a perfect solution.
We should instead remember our guards' IP a...Our initial directory guard implementation only works when we have a live consensus to find out the directory guards' IP addresses. So it's an improvement, but it's hardly a perfect solution.
We should instead remember our guards' IP addresses in our state file, and try to use our directory guards even when we don't have a consensus. This will require consideration about handling our guards being down and handling the network being down.https://gitlab.torproject.org/tpo/core/tor/-/issues/7869ntor-onion-key is padded with an equal sign2021-07-09T17:22:51ZRobert Ransomntor-onion-key is padded with an equal signReplying to [sonu](legacy/trac#7867):
>
```
ntor-onion-key Od2Sj3UXFyDjwESLXk6fhatqW9z/oBL/vAKJ+tbDqUU=
```
The unnecessary “`=`” at the end of that string needs to go away **now**, or every Tor client will have to download a thousand ...Replying to [sonu](legacy/trac#7867):
>
```
ntor-onion-key Od2Sj3UXFyDjwESLXk6fhatqW9z/oBL/vAKJ+tbDqUU=
```
The unnecessary “`=`” at the end of that string needs to go away **now**, or every Tor client will have to download a thousand or so of them every week forever.Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/7890meaningless error message displayed by tor at start up2020-06-27T14:04:59ZTracmeaningless error message displayed by tor at start upDuring tor start up, I get the following gem: "No specified non-excluded exit routers seem to be running: can't choose an exit."
The first one who could decipher that for me will get a pat on the back.
I figured out the cause, eventua...During tor start up, I get the following gem: "No specified non-excluded exit routers seem to be running: can't choose an exit."
The first one who could decipher that for me will get a pat on the back.
I figured out the cause, eventually - I have restricted tor to use exit node (via ExitNodes), but that node was unavailable for some reason.
**Trac**:
**Username**: mr-4Tor: 0.3.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/21455newwin: Inconsistent New Window height on multiple monitors (Windows)2024-03-12T09:04:47ZTracnewwin: Inconsistent New Window height on multiple monitors (Windows)(1) "New Window" or Ctrl+N creates a new window slightly offset from the current window, but the size of the new window is determined by the primary display (instead of the display the window is on).
If the primary display is larger, th...(1) "New Window" or Ctrl+N creates a new window slightly offset from the current window, but the size of the new window is determined by the primary display (instead of the display the window is on).
If the primary display is larger, this can push part of the window off the top of the display (e.g. primary 1920x1200, secondary 1280x1024: New Window on secondary display gets pushed off the top so only half the URL bar is visible).
(2) Dragging a tab out of a window with multiple tabs creates a new window sized differently than "New Window", this new window is sized according to the display it is on.
This is in 6.5 and 7.0a1 but not 6.08
**Trac**:
**Username**: pjw0https://gitlab.torproject.org/tpo/core/tor/-/issues/7952Control port method to get the exit policy2020-06-27T14:04:57ZDamian JohnsonControl port method to get the exit policyPresently controllers can GETCONF the ExitPolicy, but not get the actual exit policy we're running with. It would be nice if it was exposed via the control port.
Here's what I ended up writing in stem to get around this...
https://gitw...Presently controllers can GETCONF the ExitPolicy, but not get the actual exit policy we're running with. It would be nice if it was exposed via the control port.
Here's what I ended up writing in stem to get around this...
https://gitweb.torproject.org/stem.git/commitdiff/716f8a6
```
19:23 < armadev> atagar: re f0ae1eaee, where were you seeing exit policies with redundant lines?
tor tries to get rid of redundant lines too. i wonder if it doesn't do it well
enough, or doesn't do it pervasively enough?
19:24 < armadev> atagar: ...perhaps tor doesn't export its exit policy to the control port at all
19:43 < atagar> armadev: I don't think that it does, so I wrote a method for getting it...
19:43 < atagar> https://gitweb.torproject.org/stem.git/commitdiff/716f8a693e9b814da5e2c9df551dbe6768f4f324
19:43 < atagar> It would be nicer to fetch via the control port though. :)
19:43 < armadev> for these cases, it would be great if you opened a tor ticket to say what you want
exported
19:44 < atagar> ok, will do
19:44 < armadev> i guess there should be a balance between how much work tor does, and how much
work the controller does
19:44 < armadev> but in general, if the argument can go "each controller would have to implement
this thing itself, which is best done in tor", then it should go into tor
```Tor: 0.2.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/7956Tor uses Roaming (remote) %APPDATA% instead of %LOCALAPPDATA%2021-07-09T17:21:59ZcypherpunksTor uses Roaming (remote) %APPDATA% instead of %LOCALAPPDATA%[First tor-bug post, hope I got this right...]
The Windows tor.exe -- all current versions, standalone expert bundle and TBB/etc bundles -- has outdated Windows Explorer COM interface code to get the user's %APPDATA% location. This loca...[First tor-bug post, hope I got this right...]
The Windows tor.exe -- all current versions, standalone expert bundle and TBB/etc bundles -- has outdated Windows Explorer COM interface code to get the user's %APPDATA% location. This location can be local or roaming (remote).
Remote data gives many more opportunities for adversaries to mess with Tor Windows users, especially when they are using a domained enterprise.
The solution is below. Until this is fixed, Windows Tor users should never use Tor on a Windows network.
The Windows version of Tor calls the Windows Explorer 'shell' special folder COM APIs, to obtain the location for %APPDATA%. App data can be local or roaming.
On my box, %USERPROFILE%\AppData\* has 3 directories where apps install files, Local, LocalLow, and Roaming, where about 55% of the apps use Local, 5% uses LocalLow, and 40% use Remote.
Tor uses Roaming ("%USERPROFILE%\AppData\Roaming\tor).
Roaming means that it gets remoted to other systems, which is probably a bad thing for Tor user data. The point of Roaming profiles is to let user data migrate to multiple boxes, and the remoting of that data happens with SMBs. So, Remote user data might be sniffable over the network, hopefully this is encrypted.
Depending on how enterprise is configured, Remote user data also
probably means replication/backups of that data in the domain
controller's Active Directory box. So the user's Tor data is available over multiple SMB hosts, making things easier for attackers.
This bug was probably added to Tor in 0.2.1.11-alpha - 2009-01-20:
----snip----
- Add a new --enable-local-appdata configuration switch to change
the default location of the datadir on win32 from APPDATA to
LOCAL_APPDATA. In the future, we should migrate to LOCAL_APPDATA
entirely. Patch from coderman.
----snip----
Tor explicitly checks the location. in or/config.c's get_windows_conf_root(), in it's use of the Windows Explorer COM APIs SHGetSpecialFolderLocation() and SHGetPathFromIDList(), using this definition of the APP_DATA flag:
----snip----
/* Find X:\documents and settings\username\application data\ .
* We would use SHGetSpecialFolder path, but that wasn't added
* until IE4.
*/
#ifdef ENABLE_LOCAL_APPDATA
#define APPDATA_PATH CSIDL_LOCAL_APPDATA
#else
#define APPDATA_PATH CSIDL_APPDATA
#endif
----snip----
First, this comment is wrong on many levels. It begins with "X:" (instead of "C:") which would likely be remote, not local. It talks about IE4 which shipped aeons ago, maybe time to revisit this hesitation. And you you *do* use this COM API, anyway.
I am pretty sure that it is the above definitions that're causing you to install the Roaming data location on my Win7 box.
CSIDL_LOCAL_APPDATA == FOLDERID_LocalAppData
CSIDL_APPDATA == FOLDERID_RoamingAppData
I am not great at Autotools, but I don't believe anyone is setting
ENABLE_LOCAL_APPDATA, so the directive might be 0. It is defined/used in config.ac and orconfig.h.in.
----snip----
/* Defined if we default to host local appdata paths on Windows */
#undef ENABLE_LOCAL_APPDATA
----snip----
I don't understand why this Windows-centric feature needs to be abstracted with GNU/autotools in the first place. Can Erin's Mac OSX-based, MinGW cross-compiled Autotools determine that I'm running WinXP or Win7, etc? This abstraction, using legacy APIs, is probably why this bug has been there since 2009.
Tor already abstracts this Windows-centric code into it's own function, it would be clearer if you removed all the autotools absraction to the Windows Special Folder COM API that Tor uses, IMO.
Also, this function doesn't check this return code, and assumes to be true:
strlcpy(p,get_windows_conf_root(),MAX_PATH);
Also, in this Windows-centric error codepath, there is no warning to the
user, AFAICT:
if (!SUCCEEDED(result)) {
return NULL;
}
Also, elsewhere in get_windows_conf_root(), there are 2 comments, with potentially-open questions. Here are updated comments stated more clearly. Replace:
/* Convert the path from an "ID List" (whatever that is!) to a path. */
with:
/* Windows Explorer, aka 'Windows 'shell', uses IDLists to access various things, including special folders. We need to convert this COM-based explorer-centric array list to a Windows path. */
And replace:
/* Now we need to free the memory that the path-idl was stored in.
* In typical Windows fashion, we can't just call 'free()' on it. */
with:
/* Windows explorer special folders APIs are COM APIs, not Win32 or C runtime library calls. To use special folders, we have to use the COM memory mgmt APIs, to allocate, and now release that memory. Read the SDK ShObj.h or MSDN for more info. */
Note also that you are using legacy, deprecated version of the Special folders API, there have been revisions, apparently during Vista and Win7. The newer API has more features than the one you're using, including the local/roaming granularity. I think f you explicitly stick to local data, I think you can stick with legacy APIs.
You can't just test this with one version of Windows, you'll need to test with each version you are supporting.
More info:
http://msdn.microsoft.com/en-us/library/windows/desktop/bb762181%28v=vs.85%29.aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/dd378457%28v=vs.85%29.aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/bb762494%28v=vs.85%29.aspx
http://technet.microsoft.com/en-us/library/cc766489.aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/bb776779%28v=vs.85%29.aspx
http://www.blogtechnika.com/what-is-application-data-folder-in-windows-7/
http://superuser.com/questions/150012/what-is-the-difference-between-local-and-roaming-folders
http://superuser.com/questions/21458/why-are-there-directories-called-local-locallow-and-roaming-under-users-user
http://social.technet.microsoft.com/Forums/en/w7itprogeneral/thread/b4fd7ac2-8ad9-4a06-8c28-3f7993aa0272
http://blogs.technet.com/b/fdcc/archive/2009/07/08/fdcc-vista-application-development-requirements.aspx
http://social.msdn.microsoft.com/Forums/en/windowsgeneraldevelopmentissues/thread/8fa38285-e4f5-43f9-ab0b-8fe184d476f9
http://technet.microsoft.com/en-us/library/cc778976.aspx
Thanks,
Leehttps://gitlab.torproject.org/tpo/core/tor/-/issues/8002Mis-count of CPUs2020-06-27T14:04:55ZTracMis-count of CPUsOn start-up Tor v0.2.3.25/Linux says:
"[notice] Wow! I detected that you have 64 CPUs. I will not autodetect any more than 16, though. If you want to configure more, set NumCPUs in your torrc"
This is in a CentOS6/OpenVZ VPS with onl...On start-up Tor v0.2.3.25/Linux says:
"[notice] Wow! I detected that you have 64 CPUs. I will not autodetect any more than 16, though. If you want to configure more, set NumCPUs in your torrc"
This is in a CentOS6/OpenVZ VPS with only a single virtual CPU. Tor config param NumCPUs is not used.
It turns out that OpenVZ, since version rhel6/042stab061.2, lists all the *host* CPUs in /sys/devices/system/cpu/. It is this number of processors that is returned by the sysconf(_SC_NPROCESSORS_CONF) that Tor uses in ~/tor-0.2.3.25/src/common/compat.c to determine CPU count.
From the command line:
# getconf _NPROCESSORS_ONLN
1
Programmatically:
$ /tmp/main
sysconf() says: 64
Wow, too many CPUs: 64
I know that there's not much you can do about a sysconf() that lies. I want to get this on the record, though, for the sake of Tor's future auto-scaling.
**Trac**:
**Username**: tmpname0901Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/8037Specialy crafter microdesc could trigger to flush up to 16MB uninited heap al...2020-06-27T14:04:54ZcypherpunksSpecialy crafter microdesc could trigger to flush up to 16MB uninited heap allocated memory to mediamicrodescs_parse_from_string() and so on func do not count string as null terminated and allows to process "string" with zero byte in middle. md->body = tor_strndup(cp, md->bodylen) duplicate only partial of such string. dump_microdescri...microdescs_parse_from_string() and so on func do not count string as null terminated and allows to process "string" with zero byte in middle. md->body = tor_strndup(cp, md->bodylen) duplicate only partial of such string. dump_microdescriptor() flushes all bodylen of md's body to disk. Specially crafted bytes append to valid md sent by directory cache could lead to flush up to 16MB of memory data to media. Tor tries to clear sensitive data on free(), but some non cleared memory still no need to write in plain text to media.Tor: 0.2.4.x-final