{5} Accepted, Active Tickets by Owner (Full Description) (72 matches)

The existing GoodBadISP tables need sorting into the new format. All opinions, feedback and communications to that ISP must go in the correct section on ISPCorrespondence page to keep the primary page clean and to the point since it will grow substantially over time.

The new format should be available soon after this ticket is posted as it will be done for the US hosts (good experiences).

The Tor Browser User Manual on ​https://tb-manual.torproject.org/windows/en-US/ needs a section covering

a) where to find the source, b) how it is licensed, and c) where and how to report bugs.

Cheers,

The two text files currently in the doc directory are doc/HACKING and doc/TUNING. The latter is the only one that deals with relay operation, and its subject is oddly specific: increasing the maximum number of file descriptors. If we're going to put critical documentation in the codebase, I think it would also be worthwhile to have a basic hardening guide. It could include suggestions like:

• allowing only public key non-root SSH login
• using a firewall
• keeping your system up-to-date
• not running any other programs (especially networked ones)
• considering hardened or security-focused OS choices

Nick suggested that most of the actual information be contained in referenced links, which I agree with. There's no good reason to duplicate effort when there are, for example, so many good SSH hardening guides.

Let me know what you think, or if you have any contributions. If this is generally considered a good idea, I can start writing a draft.

With enabled HTTPS Everywhere, ​http://www.o2online.de/microsite/o2-netz/live-check/ does not load additional JavaScript from a non-SSL CDN

I do use my @tpo email address for many communications outside torproject lists or @tpo people.

Lately, I discovered that many of my emails were silent drop by the remote server or put in SPAM. And that was because the person came back to me asking where was my email. For instance, gmail sometimes put it in the SPAM still because we lack DKIM/SPF so it hurts our reputation.

Th reason why is quite simple: I use my own SMTP server to send the emails while forging the From address.

It would honestly be of a great help if we could simply have an authenticated SMTP server that I could use with let say my LDAP account for sending emails with my @tpo and not being worried that it gets dropped...

The steps required for this change are:

1. [x] create a new field (emailPassword?) in the LDAP schema (done)
2. [x] setup a separate email server to accept submissions and keep mail servers aware that not only eugeni sends email
3. [ ] hook up the password field as authentication in Postfix in the server (probably through ud-generate?)
4. [ ] test with TPA users that can modify their own password directly through LDAP
5. [ ] update the web interface (to support changing the field as well?)
6. [ ] optionally, update the mail gateway to support changes to the field
7. [ ] do tests with the users in this ticket, and if this works, propagate to all current LDAP users
8. [ ] create LDAP accounts for more users who want to use the system
9. [ ] add monitoring loops, with (say) Google, Hotmail, Yahoo and Riseup to ensure delivery works across servers

We should also make a design document to follow along.

our puppet bootstrap works, but it involves copy-pasting long lines of code. see if we can improve this somehow. maybe we could hardcode the puppetmaster cert to avoid one side of the process.

at least we could wrap it in a script on the puppetmaster to simplify *that* side.

also consider what's the current state of the art in that area.

Testing on a Samsungs Galaxy S5 mini I realized there is overlapping text on ​https://newsletter.torproject.org in the Archive section (the dates overlap with text so that the result is hardly readable). See attachment for how this looks like.

While testing a fix for #11879, Kathy and I noticed that if the bootstrap process is interrupted by setting DisableNetwork=1 via the control port, Tor waits about a minute after DisableNetwork is set back to 0 before continuing network activity. We observed this problem on a Mac OS 10.8.5 system. Possibly related tickets: #9229, #11069.

Once release candidates for Tor Browser 4.5 are available, this should be reproducible by following these steps:

1. Start Tor Browser and click "Connect".
2. Click "Open Settings" in the connection progress window to interrupt the bootstrap process.
3. Click "Connect" again. Notice that there is a delay before the bootstrap makes more progress.

We are also able to reproduce it using Tor 0.2.6.6 and a manual (telnet) control port connection. Follow these steps (control port authentication is up to you):

1. Remove all cached Tor data and start Tor like this:

./tor --defaults-torrc torrc-defaults -f torrc DisableNetwork 1

2. Make a control port connection and issue this command:

SETCONF DisableNetwork=0

3. Wait for bootstrapping to reach 25-50% and then do:

SETCONF DisableNetwork=1

4. Re-enable network access:

SETCONF DisableNetwork=0 Notice that there is a delay before the bootstrap makes more progress.

We used the torrc-defaults file that ships with Tor Browser 4.5a5:

# If non-zero, try to write to disk less frequently than we would otherwise.
AvoidDiskWrites 1
# Where to send logging messages.  Format is minSeverity[-maxSeverity]
# (stderr|stdout|syslog|file FILENAME).
Log notice stdout
# Bind to this address to listen to connections from SOCKS-speaking
# applications.
SocksPort 9150
ControlPort 9151
CookieAuthentication 1
## fteproxy configuration
ClientTransportPlugin fte exec PluggableTransports/fteproxy.bin --managed

## obfs4proxy configuration
ClientTransportPlugin obfs2,obfs3,obfs4,scramblesuit exec PluggableTransports/obfs4proxy

## flash proxy configuration
#
# Change the second number here (9000) to the number of a port that can
# receive connections from the Internet (the port for which you
# configured port forwarding).
ClientTransportPlugin flashproxy exec PluggableTransports/flashproxy-client --register :0 :9000

## meek configuration
ClientTransportPlugin meek exec PluggableTransports/meek-client-torbrowser -- PluggableTransports/meek-client

Our torrc is also from Tor Browser and it just contains a few paths:

DataDirectory /Users/.../tb-11879.app/TorBrowser/Data/Tor
GeoIPFile /Users/.../tb-11879.app/TorBrowser/Data/Tor/geoip
GeoIPv6File /Users/.../tb-11879.app/TorBrowser/Data/Tor/geoip6

I will attach some log output.

In #8243 we started requiring Stable flag for becoming HSDirs, but this is still not hard enough for motivated adversaries. Hence we need to make it even harder for a relay to become HSDir, so that only relays that have been around for long get the flag. After prop224 gets deployed, there will be less incentive for adversaries to become HSDirs since they won't be able to harvest onion addresses.

Until then, our current plan is to increase the bandwidth and uptime required to become an HSDir to something almost unreasonable. For example requiring an uptime of over 6 months, or maybe requiring that the relay is in the top 1/4th of uptimes on the network.

The parameter WarnUnsafeSocks does not work as specified in the documentation, no warning is logged in the log file when a connection is done to an ip address.

If WarnUnsafeSocks 1 (default) is set there is no warning in the log file. If you look at the code for log_unsafe_socks_warning, the only case where an error is logged is when safe_socks is true. safe_socks is true only when SafeSocks parameter is set, but not when WarnUnsafeSocks is set.

The code should be

if (safe_socks || options->WarnUnsafeSocks) {

instead of

if (safe_socks) {

Bug #11236 is caused by translated search engine strings. We should make sure those strings are not translated.

When an OR connection ​acting as a server changes to state OR_CONN_STATE_OR_HANDSHAKING_V3, it does so by setting conn->base_.state directly and not using connection_or_change_state(), so afaict this state change is never passed to pubsub or to the channel object.

On the other hand, when changing to that same state ​when acting as a client, it does use connection_or_change_state() as expected.

This seems to me to be a bug, but maybe there was a good reason for doing it this way. Also it seems no one has complained about it since the code was added, so having it changed doesn't seem to be important. But documenting here anyways since someone may want to take a look at it at some point.

i have been thinking on how to use our resources more wisely regarding the translations and the websites.

THE PROBLEM

• At this moment we are building our websites many branches anew each time we push changes to our translations repository, even with languages still not enabled on production.

This results on a situation when, if there is people translating the support portal for example to Malayalam, which is still not published, and therefore making changes to the translation repository, the website is rebuild several times when there have been no actual changes to it (the pages for the actual website show still no Malayalam translations)

On the other hand, the quick updates are very useful for translators, and they use the staging version of the site a lot, learning to test their translations and thus fixing problems by themselves.

• The translations configuration gets on the way with the development process

It makes work on staging hard, because there are a lot of changes in the configuration files (databags/alternatives.ini, $website.lektorproject, .htaccess, configs/i18n.ini) that should not get in the production website.

The local and jenkins builds get longer, as people using staging will have to compile all this languages too.

• The content of the staging site gets outdated, and translators are translating newer content that is not updated on staging

As it is so hard to merge master changes to staging, the staging website gets outdated on other code and is not useful anymore as a quick preview site.

SOLUTION

So I propose to:

• new branches for translators, called translations, that get updated when the dedicated branch at ​https://gitweb.torproject.org/translation.git/ is updated, and follow master closely, differing from it only in changes to the configuration files (databags/alternatives.ini, $website.lektorproject, .htaccess, configs/i18n.ini).

• the following scheduling in lektor-jenkins-translation branches:
  • master/staging/develop: when there is a change on this branches, we pull the new translations from the translation repo, and update all together
  • translations: we rebuild when there are changes on the website repo, AND changes on the translation repo branch as well

If we want to update the translations in branches master/staging/develop, we should be able to do it simply by triggering a build from the web interface.

This way we can reduce the builds and make development less cumbersome, while also providing a quick preview of their changes to active translators.

We can also prevent accidentally publishing incomplete languages, or removing languages from the 'preview' website.

So, for this to be implemented we need to:

• Make sure that the 'translations' branches are updated when their corresponding branch at ​https://gitweb.torproject.org/translation.git/ gets updated.
• Stop building the master/develop/staging builds each time there is a commit in their corresponding ​https://gitweb.torproject.org/translation.git/ branch, and only build when a commit is pushed to lektor itself.
• Remove extra languages in staging and develop, and leave them only in translations.

Please let me know what you think

We got a report on HackerOne by sumitthehacker:

i want to report a text injection and a misconfiguration of the 404 page

the bug exists at :

https://www.torproject.org/test/%2f../It%20has%20been%20changed%20by%20a%20new%20one%20https://www.Attacker.com%20so%20go%20to%20the%20new%20one%20since%20this%20one

as you can see attacker text is included
"It has been changed by a new one https://www.attacker.com so go to the new one since this one was not found on this server."

It would be useful for visitors to our web pages to have access to content that:

• goes into more depth than a FAQ entry
• is more formal than a blog post
• is less comprehensive than a reference manual section
• is more stable than a wiki page

These pages would form sort of a knowledge base or resource section.

From ndjson formatted PATHspider results, rewrite them as an exit list that can be consumed by check.tpo.

​https://metrics.torproject.org/dirbytes.html shows that on average about 1gbit/s is spent serving directory information.

But the investigations in #33018 show that moria1 by itself is pushing about 135mbit/s, and I hear gabelmoo is doing even more than that.

The text under the graph says "directory mirrors", so maybe we are leaving out dir auths in this graph? In that case, it would be cool to change it to one of those layered graphs so you can see how much of the total is dir auths and how much of the total are other relays.

Or maybe we're somehow not adding up the right things? Step zero is to spot-check the current data and the current graphs and become convinced that indeed we're presenting the right data.

Originally reported in https://trac.torproject.org/projects/tor/ticket/33018#comment:3

Setting my phone to disable data access and/or enable airplane mode seems to cause the transproxy iptables rules created by OrBot to get silently flushed. After re-enabling, all apps access everything without tor, until I go into the orbot config screen to cause it to reapply them.

OrBot should listen for these network disable/loss/disconnect events if possible, and reinstate the iptables rules after this happens.

Someone should also test if switching from cell data to+from wifi also triggers this iptables reset. I have not tested that yet.

This is about the bug discussed with 'n8fr8' on #guardianproject at freenode. So, the relay functionality you said was broken and needs to be fixed for 'orbot' on smartphones. I checked with the orbot version '0.2.3.10-alpha-orbot-1.0.7-FINAL' and you have checked with the 'dev branch of the code' as you said (i suppose that means you have checked with latest version of code by compiling and running the latest updated version from git; i will do it too and let you know again). But none seemed to work. In fact, you said you were getting a more significant crash, when you enabled relaying on smartphone for dev branch of code. You also thought if the problem is: whether the Relay conflict is with transproxying/root or with Tor client connection in general. But, i'm not sure if it later seemed not to be the problem. Then, you told me to change the torrc file on my android phone, as you said that orbot is not setting the relay values properly which might be the reason for orbot not working as a relay on smartphone. So, I will do that and let you know about it. I will also keep checking '​https://guardianproject.info/builds/Orbot/' to see if any new dev/debug release is posted. Thankyou so very much for all your help, Mr.Nathan.

There's some kind of problem with permissions in Orbot. I'm not sure if this happens only to me, but when I try to start Tor, it cannot access cache/control_auth_cookie. I can chmod it every time, but it is a bit annoying.

In #30687, we created a single-counter token bucket token_bucket_ctr.

token_bucket_rw_adjust() calls rate_per_sec_to_rate_per_step(rate), but token_bucket_ctr_adjust() does not.

I suggest we fix this bug by moving rate_per_sec_to_rate_per_step(rate) into token_bucket_cfg_init(). And we should add some documentation that explains the difference between rate and burst.

Gaba, this is sponsor 31-must, because it is a bug fix on sponsor 31 code that has already been merged.

I'm running tor on Gentoo Hardened. The bug exists in 0.2.6.7 and 0.2.7.1-alpha. tor crashes within seconds of starting, before any clients can connect I think.

Jul 14 13:13:07.000 [notice] Tor 0.2.7.1-alpha (git-df76da0f3bfd6897) opening log file.
Jul 14 13:13:07.182 [notice] Tor v0.2.7.1-alpha (git-df76da0f3bfd6897) running on Linux with Libevent 2.0.22-stable, OpenSSL 1.0.1p and Zlib 1.2.8.
Jul 14 13:13:07.182 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Jul 14 13:13:07.182 [notice] This version is not a stable Tor release. Expect more bugs than usual.
Jul 14 13:13:07.182 [notice] Read configuration file "/etc/tor/torrc".
Jul 14 13:13:07.187 [notice] Opening Socks listener on 127.0.0.1:9050
Jul 14 13:13:07.187 [notice] Opening Socks listener on 127.0.0.1:9056
Jul 14 13:13:07.187 [notice] Opening Socks listener on 127.0.0.1:9055
Jul 14 13:13:07.187 [notice] Opening Control listener on 127.0.0.1:9015
Jul 14 13:13:07.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip.
Jul 14 13:13:07.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6.
Jul 14 13:13:07.000 [notice] Bootstrapped 0%: Starting

============================================================ T= 1436875987
(Sandbox) Caught a bad syscall attempt (syscall socket)
/usr/bin/tor(+0x142148)[0x4bb7bc8148]
/lib64/libc.so.6(socket+0x7)[0x3adc706ea07]
/lib64/libc.so.6(socket+0x7)[0x3adc706ea07]
/lib64/libc.so.6(+0xf16a0)[0x3adc70686a0]
/lib64/libc.so.6(__vsyslog_chk+0x3ef)[0x3adc7068aff]
/lib64/libc.so.6(__syslog_chk+0x89)[0x3adc7068df9]
/usr/bin/tor(+0x135bb0)[0x4bb7bbbbb0]
/usr/bin/tor(tor_log+0xd0)[0x4bb7bbc680]
/usr/bin/tor(control_event_bootstrap+0x1e4)[0x4bb7b7ba74]
/usr/bin/tor(do_main_loop+0x84)[0x4bb7abe234]
/usr/bin/tor(tor_main+0x16c5)[0x4bb7ac1225]
/lib64/libc.so.6(__libc_start_main+0x114)[0x3adc6f97134]
/usr/bin/tor(+0x34519)[0x4bb7aba519]

$ uname -r
3.18.9-hardened

This bug has been reported downstream: ​https://bugs.gentoo.org/show_bug.cgi?id=550302. It occurs with the following torrc:

#
# Minimal torrc so tor will work out of the box
#
User tor
PIDFile /var/run/tor/tor.pid
Log notice syslog
Log notice file /var/log/tor/log
DataDirectory /var/lib/tor/data
SandBox 1

SocksPort 9050
SocksPort 9056 IsolateDestAddr IsolateDestPort
SocksPort 9055

ControlPort 9015
CookieAuthentication 1

By commenting out "Sandbox 1" or unsetting it, tor will obviously run without crashing.

Guardian Project has maintained a wrapper build system for building tor for Android since the beginning. Since many more people are now building tor for Android, I'm working to upstream as much of that as possible. The goal is that the requirements for building on Android can be fulfilled by tor's own configure.ac.

The first change is to remove the unnecessary ./configure --enable-android option.

• Android NDK compilers define __ANDROID__ so that can be used for Android-only code without adding anything in configure.ac, (following the standard pattern like __APPLE__, __linux__, __FreeBSD__, _WIN32, etc.
• android/log.h and __android_log_write() are always present if building for Android, so this would be like testing for printf() on UNIX.

Then move the Android config into configure.ac reusing the ./configure --enable-android flag. A working sketch for that is here: https://trac.torproject.org/projects/tor/ticket/28766#comment:6

The last piece is including a Java JNI wrapper in tor, enabled by ./configure --enable-jni. This lets us run tor as an Android Service, which is the Android equivalent of a UNIX daemon (UNIX daemons are not really supported on Android and using them is quite problematic). This JNI API should be generic enough to be useable in Java in general, though that's not a priority for us.

I'll add patches for merging once we agree on these details. I have this all working already on my machine.

I noticed recently plenty of 'unrecognized' relay_extended messages for node-Tor project while everything was working fine in the past after I updated the code and made it modular (and some abnormal delays to establish circuits), see also ​http://peersm.com/peersm2 this is temporary but I had to put a lot of debug stuff to find out what was going on

Finally I figured out why: unlike what is writen in the main Tor specs the hash is calculated not only with the real payload of the relay_extended messages but includes also the padding (apparently starting with 00000000, not sure where it comes from neither where it is specified)

This looks quite strange, what is the rationale for this, is it a bug, why is it not documented and does it impact other types of messages?

Follow up to #31841.

We should set a time limit for each individual unit test, and fail it if it takes too long.

We might also want to timelimit checks as well.

We can set a time limit on entire shell commands using the "timelimit" command. But we will need to write test code to do it per-unit test.

In #32213, I regenerated the practracker file, and then manually committed the over-broad exceptions.

It would be helpful if we had a --regen-overbroad option to practracker, that automatically regenerated the improvements we have made.

I feel like this should be easy, it's a combination of --regen and --list-overbroad. But I don't know the practracker design well enough to do it cleanly.

As far as I can tell, Firefox produces mixed-content warnings on an https page that references resources (images, scripts, etc) via http, even if HTTPS Everywhere can rewrite all of those http URLs to use https. (HTTPS Everywhere does rewrite resource requests, right?)

Ideally, if HTTPS Everywhere successfully rewrites every http request from a page to an https request, the page should not generate a mixed content warning. (Though I'd still like to see some indication that the page was only secure due to HTTPS Everywhere, so I know to report the insecure resources to the site owner.)

When you drag the httpse icon from the urlbar to 'menu_bar.view.toolbars.customize' window you lose the 'menu_bar.tools.https_everywhere' drop down menu content for httpse, though the menu item itself is still there. At that point, the only way to configure httpse is via 'about:addons'. Or of course to restore the icon to the urlbar.

Seems to me the drop down menu content should remain regardless of where the icon is, or is not.

FF 10.0.3 ESR HTTPS-E v2.1

We just had a bug reported about a securecookie rule that applied to all of MIT (including pages that don't support HTTPS at all!) and was breaking logins.

However, the ruleset in question didn't appear in the active rules menu, because no rewrite rule was triggered on the page in question -- only a securecookie. This made the problem take slightly longer to debug and made it harder for affected users to work around. The existing logic for deciding which rules are "active" on the current pages seems to be triggered solely by rewrite rules.

Since securecookie rules affect page rendering and can even break it, rulesets containing them should also show up in the active rules menu when they were applied to a resource on the current page.

We almost missed a memory safety bug in #31012, because our CI doesn't run our tools. We should write some quick tool tests, and run them in our CI.

The control-spec lists some tor/ URLs as GETINFO dir/ keys: ​https://gitweb.torproject.org/torspec.git/tree/control-spec.txt#n807 (The reference to section 4.4 in dir-spec is also wrong, it should be Appendix B.)

But some newer URLs are missing, for example, consensus-microdesc: ​https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n3862

We could refactor the GETINFO dir/ code to redirect all requests to the tor/ URL.

Currently, we do not expose any information about non-tunneled directory connections to controllers. Should we?

Almost all visited URLs are saved in /data/data/org.torproject.torbrowser_alpha/files/mozilla/profile.default/browser.db-wal. Clearing private data from the settings or pressing the 'Quit' button does not delete that file. So basically all browsing history is still stored after clearing private data. After clearing private data in the settings, it does say that some private data could not be deleted but if 'Site settings' is unchecked, it doesn't say that anymore. So normally we'd think that only site settings are not cleared.

this is an (old-style) onionoo frontend going only to the old backends. cf. #31659.

This is the final phase of my great PT shutdown process cleanup as a follow up to #15545.

Now that there's a portable mechanism to signal termination to PTs (close the stdin), we should change the PT shutdown process to allow graceful termination to look like this:

1. Close stdin (and on U*IX, send a SIGTERM, PT behavior here is equivalent).
2. Wait for a grace period (~1 sec?)
3. If the child still is not dead, send a SIGKILL/TerminateProcess(). (Failsafe)

This fixes #9330 in that, PTs that wish to trap a graceful shutdown on Windows have a way to do so, despite the final stage of the process killing the PT in the most violent way possible as a failsafe (realistically, PTs should exit shortly after step 1).