Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2016-05-12T23:39:04Zhttps://gitlab.torproject.org/legacy/trac/-/issues/18148extra chars in default bridge line2016-05-12T23:39:04ZNima Fatemiextra chars in default bridge linethere's a tiny bit of extra chars at the end of one of the bridge lines that might cause errors when it's picked.there's a tiny bit of extra chars at the end of one of the bridge lines that might cause errors when it's picked.Nathan FreitasNathan Freitashttps://gitlab.torproject.org/legacy/trac/-/issues/22551F-Droid's Orfox APK file not updated to Tor Browser 7.0 yet2020-06-15T23:44:48ZcypherpunksF-Droid's Orfox APK file not updated to Tor Browser 7.0 yetThe rebranded Tor Browser, dubbed "Orfox", which is just TBB with some tiny patches against it for differences between Android's "Bionic" libc and the glibc that normal Tor Browser uses, is a year out of date.
Expected behaviour: when h...The rebranded Tor Browser, dubbed "Orfox", which is just TBB with some tiny patches against it for differences between Android's "Bionic" libc and the glibc that normal Tor Browser uses, is a year out of date.
Expected behaviour: when https://blog.torproject.org/blog/tor-browser-70-released was posted saying that Tor Browser for Android had been updated to disable RtspMediaResource (meaning https://trac.torproject.org/projects/tor/ticket/19078 was fixed), it should be possible to get the updated version.
Actual behaviour: it is not possible to get the update
Steps to reproduce: replace proprietary backdoored Google Play with F-Droid. See official Tor blog advertising an update for Android, with no way to get said update.
Many journalists and whistleblowers in third world countries can't afford a laptop and therefor must rely on Orfox. For their sake please try to at least release updates when critical zero day vulnerabilities come out. Your work is very appreciated, please keep at it.
There's no Orfox component to choose, presumably because it's almost exactly the same codebase as Tor Browser, so I'm putting this under Tor Browser.Nathan FreitasNathan Freitashttps://gitlab.torproject.org/legacy/trac/-/issues/2662Gibberbot does not stay signed in2011-03-06T05:05:11ZcypherpunksGibberbot does not stay signed inGibberbot should have an option to stay signed in. I keep getting logged out after leaving the app in the background...Gibberbot should have an option to stay signed in. I keep getting logged out after leaving the app in the background...Nathan FreitasNathan Freitashttps://gitlab.torproject.org/legacy/trac/-/issues/11366Hidden service cannot be created2014-06-06T15:57:34ZTracHidden service cannot be createdHidden service creation and activation no longer works in the latest Orbot. Tested all the way up to 13.0.6 (nightly).
I've started a small HTTP server (KWS for Android) on port 8888 and set port 8888 in the "Hidden Services Ports" fie...Hidden service creation and activation no longer works in the latest Orbot. Tested all the way up to 13.0.6 (nightly).
I've started a small HTTP server (KWS for Android) on port 8888 and set port 8888 in the "Hidden Services Ports" field and checked "Hidden Service Hosting". The hostname and private_key files are created (checked from root shell) but the service is not accessible.
Manually adding the service to app_bin/torrc and re-running tor makes the hidden service appear. I added this:
HiddenServiceDir /data/data/org.torproject.android/app_data/
HiddenServicePort 8888 127.0.0.1:8888
If I understand the Orbot sources correctly, the line it tries to add when enabling a service is
HiddenServicePort 8888 **0.0.0.0**:8888 (not sure if that makes a difference)
The ".Onion Hostname" field is _never_ populated, once again if I understand the sources correctly the getHiddenServiceHostname() private method in TorService is never called (in the latest version from Git).
Finally, when using the REQUEST_HS_PORT intent to trigger this externally, I get the dialog asking me to confirm the activation of the hidden service, then Orbot hangs altogether and must be force-killed.
I suspect this is due to the fact that the enableHiddenServicePort method in the Orbot class (https://gitweb.torproject.org/orbot.git/blob/HEAD:/src/org/torproject/android/Orbot.java#l357) is called from https://gitweb.torproject.org/orbot.git/blob/HEAD:/src/org/torproject/android/Orbot.java#l444 upon pressing the Accept button, on the UI thread, so the UI hangs while waiting for the hidden service to be created (and due to the defect above, it never returns).
**Trac**:
**Username**: drazvanNathan FreitasNathan Freitashttps://gitlab.torproject.org/legacy/trac/-/issues/3254Implement newnym2013-10-16T18:53:36ZJacob AppelbaumImplement newnymIt would be really useful to have newnym support in Orbot.It would be really useful to have newnym support in Orbot.Nathan FreitasNathan Freitashttps://gitlab.torproject.org/legacy/trac/-/issues/7171Improve Orbot's user experience for handling blocked access to the Tor network2016-04-07T11:36:58ZKarsten LoesingImprove Orbot's user experience for handling blocked access to the Tor network(Re-using text from Nathan here.)
Improve user experience for handling blocked access to Tor network or bridges, and prompt to user to try obfsproxy. The interesting thing that you can do on Android is tell whether the user generally h...(Re-using text from Nathan here.)
Improve user experience for handling blocked access to Tor network or bridges, and prompt to user to try obfsproxy. The interesting thing that you can do on Android is tell whether the user generally has an "Internet" connection or not, meaning they have good connectivity, an IP address, etc. The state we're looking for is when the Internet is good, but Tor is stuck at 10% bootstrapping, or some other typical fingerprint of Tor network blockage. Orbot has solid bridge/obfsproxy support, but right now it is not exposed to users who don't know about it.Nathan FreitasNathan Freitashttps://gitlab.torproject.org/legacy/trac/-/issues/23289Improving HS reachability for Orbot/Android users2020-06-13T15:12:52ZNathan FreitasImproving HS reachability for Orbot/Android usersOrbot received a pull request here: https://github.com/n8fr8/orbot/pull/83 with proposed modifications to improve reachability of an HS running on the device. We asked Michael Rogers from the Briar Project to review this proposal, since ...Orbot received a pull request here: https://github.com/n8fr8/orbot/pull/83 with proposed modifications to improve reachability of an HS running on the device. We asked Michael Rogers from the Briar Project to review this proposal, since his team has done the most with HS on mobile. The PR details and his comments are inline below.
While these improvements seem worthwhile from a usability perspective, there are concerns about impact on anonymity, as always.
****
The issue at the moment is that while the device is sleeping for long
periods of time, it is possible for the HS to become unreachable as a
result of Tor detecting a clock jump of length greater than
`NUM_JUMPED_SECONDS_BEFORE_WARN` (100 seconds) upon waking up, which
then closes all circuits. Another issue is that if the device was woken
up by incoming network traffic, the device only stays awake for about a
second before going back to sleep, which isn't enough time for Tor to
rebuild the intro circuits, and thus the HS is no longer reachable until
Tor is able to rebuild the circuits.
I attempt to improve this situation in two ways:
1. Increase `NUM_JUMPED_SECONDS_BEFORE_WARN` from 100 seconds to 600
seconds to avoid triggering the clock-jumped-close-all-circuits code
every time the device wakes up from sleep.
2. Add a new command (`MARKCONNFORWAKELOCK`) and event (`WAKELOCK`) to
the control port to allow Tor to synchronously signal Orbot to hold wake
lock on behalf of Tor (since it isn't possible to hold a wake lock from
native code). A wake lock is acquired at the start of a event callback,
then released when libevent returns from its event loop when there are
no active events. This prevents the device from sleeping when Tor still
has work to do.
****
Comments from Michael@BriarProject:
Thanks for passing this on. I've also been looking into this problem
lately. Comments inline below.
On 11/08/17 12:00, Nathan of Guardian wrote:
1. Increase `NUM_JUMPED_SECONDS_BEFORE_WARN` from 100 seconds to 600
seconds to avoid triggering the clock-jumped-close-all-circuits code
every time the device wakes up from sleep.
Is there something that makes 600 seconds qualitatively better than 100
seconds, or is this just a workaround for short sleeps?
2. Add a new command (`MARKCONNFORWAKELOCK`) and event (`WAKELOCK`) to
the control port to allow Tor to synchronously signal Orbot to hold wake
lock on behalf of Tor (since it isn't possible to hold a wake lock from
native code). A wake lock is acquired at the start of a event callback,
then released when libevent returns from its event loop when there are
no active events. This prevents the device from sleeping when Tor still
has work to do.
I like the underlying idea here, but this way of implementing it seems
risky.
The problem is that Tor is driven by two kinds of events: incoming
network traffic and libevent timers. When the device is asleep, incoming
traffic will briefly wake it, so you can grab a wake lock until Tor
finishes its work. But if a libevent timer expires during sleep, the
device won't be woken. The timer will be handled next time the device
wakes for some other reason.
I think this is a potential risk to anonymity, because it will result in
externally visible behaviour, such as circuit teardowns, happening in
correlated bursts when the device wakes up. And those bursts can be
triggered by sending traffic to the device.
Tor expects timers to run at the scheduled time. That's why it panics
and tears everything down if the clock jumps by 100 seconds. Suppressing
that panic response seems like a bad idea. More generally, ignoring the
assumption behind the panic response seems like a bad idea.
What would be a better idea?
Briar holds a wake lock whenever Tor is connected to the network, but
that kills the battery, so we have to find another way.
If we could put Tor into some kind of "idle mode", where it would shut
down all circuit building and other timer-driven behaviour, then it
might be safe to let the device sleep until it was woken by incoming
traffic. We could ask the guard for keepalives, say once every five
minutes, to ensure that periodic tasks like fetching the consensus and
uploading HS descriptors would have a chance to run even if there was no
incoming traffic. But those tasks would still happen in bursts, so it
seems to me that there would still be a risk to anonymity.
We might be able to reduce the burstiness if Tor could tell the
controller the time of the next consensus fetch or descriptor upload,
and the controller could use an alarm to wake the device at that time,
regardless of network traffic. Doze mode adds some restrictions here -
whitelisted apps can set an alarm every nine minutes, which might be
enough. The alarm could also be used to check the time of the last
keepalive, to detect dead guard connections.
I think doing this right is going to require significant input from the
Tor devs, first of all to see what we can safely get away with in terms
of sleep, and then perhaps to implement an idle mode and supporting
controller commands if it looks like a good idea.Tor: unspecifiedNathan FreitasNathan Freitashttps://gitlab.torproject.org/legacy/trac/-/issues/8882Include Arabic translation for Orbot strings.xml2014-04-16T06:06:25ZSheriefInclude Arabic translation for Orbot strings.xmlArabic Translation for Orbot strings.xml was revised (twice) and completed, Please include it.Arabic Translation for Orbot strings.xml was revised (twice) and completed, Please include it.Nathan FreitasNathan Freitashttps://gitlab.torproject.org/legacy/trac/-/issues/5244Infinite Flickering after Orientation Change in Orbot2020-06-13T02:08:13ZTracInfinite Flickering after Orientation Change in OrbotWhen using Orbot in normal mode and vertical orientation, then changing it to horizontal, Orbot UI starts to flicker indefinitely and is completely unusable.
If you change the orientation back to vertical, it might go back to normal or ...When using Orbot in normal mode and vertical orientation, then changing it to horizontal, Orbot UI starts to flicker indefinitely and is completely unusable.
If you change the orientation back to vertical, it might go back to normal or might still be flickering (though vertically this time)
I am using a test build of Orbot (0.2.3.11-alpha-1.0.7.3-ALPHA-2) which n8fr8 provided for me (it has the Arabic strings I translated added to it). Running on Galaxy Nexus ICS.
**Trac**:
**Username**: VoulnetNathan FreitasNathan Freitashttps://gitlab.torproject.org/legacy/trac/-/issues/4444Iptables-binary bundled with Orbot segfaults on Android 2.3.52014-05-12T19:20:23ZTracIptables-binary bundled with Orbot segfaults on Android 2.3.5The iptables-binary that comes with the current release of Orbot (0.2.2.25-alpha-orbot-1.0.5.1, missing in the version-combobox of this bugtracker?) segfaults immediately in my environment:
- Galaxy S2
- XXKI4-based ROM (CheckRom RevoHD...The iptables-binary that comes with the current release of Orbot (0.2.2.25-alpha-orbot-1.0.5.1, missing in the version-combobox of this bugtracker?) segfaults immediately in my environment:
- Galaxy S2
- XXKI4-based ROM (CheckRom RevoHD 2.0)
=> Android 2.3.5
- Siyah-Kernel 2.2b4
As the iptables-binary of e.g. Droidwall works perfectly well, it might be a linking problem.
Replacing Orbots iptables-binary with the one from Droidwall enables all expected functions (transparent proxying etc.).
Stacktrace is attached. I called "iptablesorig --list" (renamed the binary) manually from a terminal to provide this information.
**Trac**:
**Username**: olifeeNathan FreitasNathan Freitashttps://gitlab.torproject.org/legacy/trac/-/issues/11414jtorctl: Make TorControlConnection thread-safe2014-08-11T20:35:30ZTracjtorctl: Make TorControlConnection thread-safeThis patch makes TorControlConnection thread-safe. In particular it prevents concurrent calls to sendAndWaitForResponse() from leaking threads.
**Trac**:
**Username**: akwizgranThis patch makes TorControlConnection thread-safe. In particular it prevents concurrent calls to sendAndWaitForResponse() from leaking threads.
**Trac**:
**Username**: akwizgranNathan FreitasNathan Freitashttps://gitlab.torproject.org/legacy/trac/-/issues/11415jtorctl: Throw checked exceptions instead of unchecked exceptions2014-08-11T20:35:07ZTracjtorctl: Throw checked exceptions instead of unchecked exceptionsjtorctl throws unchecked RuntimeExceptions if it receives an error response or malformed response from Tor - users of the library have to catch these without being warned by the API. This patch converts jtorctl's RuntimeException subclas...jtorctl throws unchecked RuntimeExceptions if it receives an error response or malformed response from Tor - users of the library have to catch these without being warned by the API. This patch converts jtorctl's RuntimeException subclasses into IOException subclasses. This is safer for users of the library and better conveys what's happened (an IO error).
**Trac**:
**Username**: akwizgranNathan FreitasNathan Freitashttps://gitlab.torproject.org/legacy/trac/-/issues/1280Lack of a web browser with HTTPS proxy support may cause confusion2010-05-26T15:02:29ZPatrick McDonaldLack of a web browser with HTTPS proxy support may cause confusionIn the Tor on Android page, it recommends users of Android 1.6 systems use ProxySurf to use Tor. Since ProxySurf does not support proxy HTTPS and the "Are you using Tor" page only supports HTTPS. This may lead to confusion that Orbot i...In the Tor on Android page, it recommends users of Android 1.6 systems use ProxySurf to use Tor. Since ProxySurf does not support proxy HTTPS and the "Are you using Tor" page only supports HTTPS. This may lead to confusion that Orbot is not proxying correctly when it really is. Either an HTTP service for the "Are you using Tor" page or a note in the documentation would be most helpful.
[Automatically added by flyspray2trac: Operating System: All]Nathan FreitasNathan Freitashttps://gitlab.torproject.org/legacy/trac/-/issues/10584Let advance user to edit Orbot's torrc file2016-04-07T11:48:03ZTracLet advance user to edit Orbot's torrc fileI want to make my Orbot to use "HidServAuth", because some hidden website
requires to add this. So, please let advanced user to add something like
"HidServAuth" into their config file(using GUI/CLI).
**Trac**:
**Username**: ikurua22I want to make my Orbot to use "HidServAuth", because some hidden website
requires to add this. So, please let advanced user to add something like
"HidServAuth" into their config file(using GUI/CLI).
**Trac**:
**Username**: ikurua22Nathan FreitasNathan Freitashttps://gitlab.torproject.org/legacy/trac/-/issues/5700Make/modify VoIP applications to work better on Tor2020-06-15T23:14:41ZKarsten LoesingMake/modify VoIP applications to work better on TorDepending on how hard it will be to make Tor handle VoIP applications people already want to use (#5699), we should explore how much mileage we can get out of making our own or modifying existing VoIP applications to work better on Tor. ...Depending on how hard it will be to make Tor handle VoIP applications people already want to use (#5699), we should explore how much mileage we can get out of making our own or modifying existing VoIP applications to work better on Tor. One example here is Roger's "push to talk" not-actually-realtime-but-close VoIP wishlist item that Nathan is working on.Nathan FreitasNathan Freitashttps://gitlab.torproject.org/legacy/trac/-/issues/18219Many "non-tor-apps" fail connections while transparent proxying enabled in Orbot2016-02-04T18:51:14ZTracMany "non-tor-apps" fail connections while transparent proxying enabled in OrbotHi
Many android apps that are not designed to work with tor frequently fail connections while transparent proxying is enabled. For example firefox and chromium often say "cannot create secure connection" or "site could not be loaded". Mo...Hi
Many android apps that are not designed to work with tor frequently fail connections while transparent proxying is enabled. For example firefox and chromium often say "cannot create secure connection" or "site could not be loaded". Most times, the bug disappears after 2-3 times refreshing the page, but ofter the sites are not loaded correctly then.
Other apps cannot connect to the internet at all. (Eg. NasaPic)
Im on rooted (Superuser) CopperheadOS (hardened Android based on AOSP 6.0.1 marshmallow) on a Nexus 5.
I installed Orbot from your FDroid-repo and granted it root for transparent proxy (proxy all applications).
Do you need more information? Im not sure, whether its an Issue caused by CopperheadOS or by Orbot. I remember using Orbot on CM12 without these issues.
**Trac**:
**Username**: vanitasvitaeNathan FreitasNathan Freitashttps://gitlab.torproject.org/legacy/trac/-/issues/1814Need to setup an Android Market account2010-08-21T12:49:53ZNathan FreitasNeed to setup an Android Market accounthttp://market.android.com/publish
Requires a Google Account, and a $25 one-time payment.
This will be the official Tor Project account for releasing the Orbot application into the market.http://market.android.com/publish
Requires a Google Account, and a $25 one-time payment.
This will be the official Tor Project account for releasing the Orbot application into the market.Android (Orbot): 1.0Nathan FreitasNathan Freitashttps://gitlab.torproject.org/legacy/trac/-/issues/18293new port; new day - a dedication to george torwell2016-05-12T23:46:27ZNima Fateminew port; new day - a dedication to george torwellPlease see https://github.com/mrphs/orbot/commit/5eb628b03a22d188990873fcf199518e69db3db1Please see https://github.com/mrphs/orbot/commit/5eb628b03a22d188990873fcf199518e69db3db1Nathan FreitasNathan Freitashttps://gitlab.torproject.org/legacy/trac/-/issues/11489obfsclient integration for orbot2014-04-24T13:42:31ZYawning Angelobfsclient integration for orbotIn order to support more than obfs2, orbot should switch to using obfsclient from obfsproxy. I have attached a preliminary set of patches that accomplish this, based off `8d73be655e84879e56369546cdefa7c8d84fa4ac`.
To be done:
* obfspr...In order to support more than obfs2, orbot should switch to using obfsclient from obfsproxy. I have attached a preliminary set of patches that accomplish this, based off `8d73be655e84879e56369546cdefa7c8d84fa4ac`.
To be done:
* obfsproxy is still build and included as an asset.
* The obfsclient binary built with debugging information is gigantic, stripping after build is recommended.
* UI work for pluggable transport protocol selection.
Please let me know if there are any questions.Nathan FreitasNathan Freitashttps://gitlab.torproject.org/legacy/trac/-/issues/15819orbot2016-04-07T11:13:41ZTracorbot
--Doesn't connect properly,though I've used it before.only on orbot
**Trac**:
**Username**: vendettascarf23
--Doesn't connect properly,though I've used it before.only on orbot
**Trac**:
**Username**: vendettascarf23Nathan FreitasNathan Freitas