Planet Tor

@blog October 21, 2021 - 16:30 • 6 hours ago
Global Encryption Day: #MakeTheSwitch
Global Encryption Day: #MakeTheSwitch Al Smith October 21, 2021

Today, Oct 21, 2021, is the very first Global Encryption Day, organized by the Global Encryption Coalition, where we are a member. Global Encryption Day is an opportunity for businesses, civil society organizations, technologists, and millions of Internet users worldwide to show our communities why encryption matters. It’s also a day for all of us to pledge to Make the Switch to encrypted services (like Tor!) and prioritize our privacy and security online.

At the Tor Project, we’re proud to help millions of people take back their right to privacy, to freely access and share information, and to more easily circumvent internet censorship--and encryption makes this possible.

Encryption allows us to provide these tools: for example, Tor uses three layers of encryption in the Tor circuit; each relay decrypts one layer before passing the request on to the next relay. Encryption is used in many other ways as well! Without encryption, millions of people would lose their access to the safe and uncensored internet. 

In honor of this inaugural Global Encryption Day, the Tor Project, along with 148 other organizations and businesses have signed the Global Encryption Day Statement, calling on governments and businesses to reject efforts to undermine encryption and instead pursue policies that enhance, strengthen, and promote use of strong encryption to protect people everywhere.

As an individual, you can get involved with Global Encryption Day by:

...
@ooni October 21, 2021 - 00:00 • 23 hours ago
How countries attempt to block Signal Private Messenger App around the world
Signal Private Messenger, commonly used by human rights defenders worldwide, is widely considered the state-of-the-art app for private and secure communications. But as its popularity surged recently, we have started to observe its blocking in several countries. In this report, we share our analysis of OONI network measurement data on the blocking of the Signal Private Messenger app in Iran, China, Cuba, and Uzbekistan. Currently, circumvention is enabled by default for Signal users in Iran, Egypt, Oman, Qatar, and the UAE. ...
@blog October 16, 2021 - 12:32 • 5 days ago
New Release: Tor Browser 11.0a9 (Windows/macOS/Linux)
New Release: Tor Browser 11.0a9 (Windows/macOS/Linux) sysrqb October 16, 2021

Tor Browser 11.0a9 is now available from the Tor Browser download page and also from our distribution directory.

Note: This is an alpha release, an experimental version for users who want to help us test new features. For everyone else, we recommend downloading the latest stable Windows/macOS/Linux release instead.

This version updates Firefox to version 91.2.0esr on Windows, macOS, and Linux. This version includes important security updates to Firefox on Windows, macOS, and Linux.

Please report any issues and regressions you experience since upgrading from an earlier version based on Firefox 78esr.

Warning:
Tor Browser Alpha does not support version 2 onion services. Tor Browser (Stable) will stop supporting version 2 onion services very soon. Please see the deprecation F.A.Q. entry regarding Tor version 0.4.6. Migrate your services and update your bookmarks to version 3 onion services as soon as possible.

The full changelog since Tor Browser 11.0a7:

  • Windows + OS X + Linux
    • Update Firefox to 91.2.0esr
    • Update Tor to 0.4.7.1-alpha
    • Bug 40004: Convert tl-protocol to async.
    • Bug 40012: Watch all requested tor events
    • Bug 40027: Make torbutton_send_ctrl_cmd async
    • Bug 40042: Add missing parameter of createTransport
    • Bug 40043: Delete all plugin-related protections
    • Bug 40045: Teach the controller about status_client
    • Bug 40046: Support arbitrary watch events
    • Bug 40047: New string for Security Level panel
    • Bug 40048: Protonify Circuit Display Panel
    • Bug 40600: Multiple pages as home page unreliable in 11.0a4
    • Bug 40616: UX: multiple about:torconnect
    • Bug 40624: TorConnect banner always visible in about:preferences#tor even after bootstrap
    • Bug 40626: Update Security Level styling to match Proton UI
    • Bug 40628: Checkbox wrong color in about:torconnect in dark mode theme
    • Bug 40630: Update New Identity and New Circuit icons
    • Bug 40631: site identity icons are not being displayed properly
    • Bug 40632: Proton'ify Circuit Display Panel
    • Bug 40634: Style updates for Onion Error Pages
    • Bug 40636: Fix about:torconnect 'Connect' border radius in about:preferences#tor
  • Build System
    • Windows + OS X + Linux
      • Update Go to 1.16.9
      • Bug 40048: Remove projects/clang-source
      • Bug 40347: Make the list of toolchain updates needed for firefox91
      • Bug 40363: Change bsaes git url
    • Windows + Linux
    • Windows
      • Bug 28240: switch from SJLJ exception handling to Dwarf2 in mingw for win32 [tor-browser-build]
      • Bug 40306: Update Windows toolchain to switch to mozilla91
      • Bug 40376: Use python3 for running pe_checksum_fix.py
    • OS X
      • Bug 40307: Update macOS toolchain to switch to mozilla91
    • Linux
      • Bug 40222: Bump GCC to 10.3.0 for Linux
      • Bug 40305: Update Linux toolchain to switch to mozilla91
      • Bug 40353: Temporarily disable rlbox for linux builds
...
@blog October 15, 2021 - 13:32 • 6 days ago
Entering the Matrix
Entering the Matrix ahf October 15, 2021

For a long time, the Tor community has been running many day-to-day activities using the IRC network known as OFTC. IRC has worked out well for us, and our community on IRC has been evolving over the years with new people joining in and new channels appearing for specific needs in the organization.

 

Today we are happy to announce an expansion of the Tor community's day-to-day conversations by bridging our IRC community the Matrix platform. For regular Tor users, it means that you can chat with us using a friendly App like Element.

 

We are now announcing the list of Tor channels available on Matrix:

 

  • #tor - Our primary user support channel. If you have questions about how to do specific things with Tor, please drop by here and ask away.
  • #tor-dev - Our primary engineering channel where technical discussions about the engineering efforts in the organization are taking place.
  • #tor-project - Our main channel for the project and organization-wide conversations.
  • #tor-relays - Our relay operator community channel. If you are running relays or are considering it, feel free to drop by here.

 

In addition to the primary channel listed above, we also have a few team-specific channels used by the different internal teams of the Tor Project.

 

  • #tor-www - Tor's website team. The team that builds and maintains our presence on the web.
  • #tor-ux - Tor's UX team. The team is responsible for UX enhancements on the different Tor products.
  • #tor-l10n - Tor's Localization team. The team is responsible for managing the volunteering efforts of providing Tor's products in as many languages as possible.

 

We also have a channel specifically for people living and discussing Tor in the Global South. This channel is available as #tor-south:matrix.org. Feel free to join and speak in your native language.

 

We are looking forward to seeing new community members in our new Matrix bridged community. So far, we have been impressed with the features available by the engineering teams behind the different Matrix-related systems.

...
@blog October 14, 2021 - 18:20 • 7 days ago
Tor’s Bug Smash Fund Year 3: $107K Raised!
Tor’s Bug Smash Fund Year 3: $107K Raised! Al Smith October 14, 2021

Hello, Tor world! We owe you a thank you.

This August, we asked you to contribute to the Tor Project's Bug Smash Fund. We created this fund in order to create a reserve that would help us find bugs, complete maintenance work, and do all of the “dirty jobs” that are necessary to keep Tor Browser, the Tor network, and the many tools that rely on Tor strong, safe, and running smoothly.

Today, I'm here to share the exciting news that you helped us raise $107,672.20 for the Bug Smash Fund this year! Of that total, about 44% came in the form of 10 different cryptocurrencies. Thank you to everyone from the cryptocurrency community for supporting Tor.

What’s next: as we did in 2019 and 2020, we’ll tag bugs in GitLab with BugSmashFund so you can follow along with how we’re allocating the fund: to things like fixing bugs on our website, in core Tor, and BridgeDB; tracking censorship events in Iran, Venezuela; and improving Tor Browser’s build process. We’ll also make periodic updates here on the blog (you can see previous versions of this blog post by searching “bug smash fund”) and through the newsletter about our progress with these BugSmashFund tickets. 

Thank you to everybody who made a contribution to the Bug Smash Fund during the month of August. This work is critical in helping us to provide safer tools for millions of people around the world exercising their human rights to privacy and freedom online.

...
@blog October 12, 2021 - 03:15 • 10 days ago
New Release: Tor Browser 11.0a8 (Android Only)
New Release: Tor Browser 11.0a8 (Android Only) sysrqb October 11, 2021

Tor Browser 11.0a8 is now available from the Tor Browser download page and also from our distribution directory.

Note: This is an alpha release, an experimental version for users who want to help us test new features. For everyone else, we recommend downloading the latest stable Windows/macOS/Linux or Android release instead.

This version is a bugfix for Android.

Warning:
Tor Browser Alpha does not support version 2 onion services. Tor Browser (Stable) will stop supporting version 2 onion services very soon. Please see the deprecation F.A.Q. entry regarding Tor version 0.4.6. Migrate your services and update your bookmarks to version 3 onion services as soon as possible.

The full changelog since Tor Browser 11.0a7:

  • Android
    • Bug 40052: Skip L10nRegistry source registration on Android
...
@blog October 11, 2021 - 02:07 • 11 days ago
New Release: Tor Browser 10.5.9 (Android Only)
New Release: Tor Browser 10.5.9 (Android Only) sysrqb October 10, 2021

Tor Browser 10.5.9 is now available from the Tor Browser download page and also from our distribution directory.

This version is a bugfix for Android.

Warning:
Tor Browser will stop supporting version 2 onion services very soon. Please see the previously published deprecation timeline. Migrate your services and update your bookmarks to version 3 onion services as soon as possible.

The full changelog since Tor Browser 10.5.8:

  • Android
    • Bug 40052: Skip L10nRegistry source registration on Android
...
@blog October 6, 2021 - 15:47 • 15 days ago
New Release: Tor Browser 10.5.8
New Release: Tor Browser 10.5.8 sysrqb October 06, 2021

Tor Browser 10.5.8 is now available from the Tor Browser download page and also from our distribution directory.

This version updates Firefox on Windows, macOS, and Linux to 78.15.0esr. This version includes important security updates to Firefox.

Warning:
Tor Browser will stop supporting version 2 onion services very soon. Please see the previously published deprecation timeline. Migrate your services and update your bookmarks to version 3 onion services as soon as possible.

The full changelog since Tor Browser 10.5.8:

  • Windows + OS X + Linux
    • Update Firefox to 78.15.0esr
    • Bug 40049: Add banner for VPN survey to about:tor
  • Android
    • Bug 40193: Add banner for VPN survey to Android homepage
  • Build System
    • All Platforms
...
@blog September 27, 2021 - 15:32 • 24 days ago
New Release: Tor Browser 10.5.7 (Android)
New Release: Tor Browser 10.5.7 (Android) sysrqb September 27, 2021

Tor Browser 10.5.7 is now available from the Tor Browser download page and also from our distribution directory.

This version updates Firefox's GeckoView component to 92.0 on Android. This version includes important security updates to Firefox.

Warning:
Tor Browser will stop supporting version 2 onion services later this year. Please see the previously published deprecation timeline. Migrate your services and update your bookmarks to version 3 onion services as soon as possible.

The full changelog since Tor Browser 10.5.6:

  • Android
    • Update Openssl to 1.1.1l
    • Bug 40639: Rebase geckoview patches onto 92.0 build3
...
@blog September 25, 2021 - 13:55 • 26 days ago
New Release: Tor Browser 11.0a7
New Release: Tor Browser 11.0a7 sysrqb September 25, 2021

Tor Browser 11.0a7 is now available from the Tor Browser download page and also from our distribution directory.

Note: This is an alpha release, an experimental version for users who want to help us test new features. For everyone else, we recommend downloading the latest stable Windows/macOS/Linux or Android release instead.

This version updates Firefox to version 78.14.0esr on Windows, macOS, and Linux, and this version updates Firefox's GeckoView component to 92.0 on Android. This version includes important security updates to Firefox on Windows, macOS, and Linux, and Android.

Warning:
Tor Browser Alpha does not support version 2 onion services. Tor Browser (Stable) will stop supporting version 2 onion services very soon. Please see the deprecation F.A.Q. entry regarding Tor version 0.4.6. Migrate your services and update your bookmarks to version 3 onion services as soon as possible.

The full changelog since Tor Browser 11.0a6:

  • All Platforms
    • Update Openssl to 1.1.1l
  • Windows + OS X + Linux
    • Update Firefox to 78.14.0esr
    • Bug 40597: Implement TorSettings module
  • Android
    • Bug 40611: Rebase geckoview patches onto 92.0
  • OS X
    • Bug 40358: Make OpenSSL 1.1.1l buildable for macOS
...
@kushal September 24, 2021 - 03:11 • 28 days ago
Rust, reproducibility and shadow-rs

Generally all of our Rust code are reproducible. If you build it in a fixed path, and also use SOURCE_DATE_EPOCH environment variable, the final library or executables will be producible. This is really helpful, for example while building cryptography python wheel, I can keep building it in a reproducible way even with the Rust dependencies.

A few days ago I saw shadow-rs, which can provide a lot of build time information. For example, in khata now I have a way to tell if I am using any custom build and also identify which one. I was a bit worried as shadow allows to store the build time too, but later found that the community already put in the patches so that it follows SOURCE_DATE_EPOCH.

So, I can still have reproducibility if I use the same build toolchain and environment while depending on shadow. Here is some example code for you to play around.

...
@blog September 21, 2021 - 11:29 • 1 months ago
V3 onion services usage
V3 onion services usage Gus September 21, 2021

Guest post by Tobias Höller

With the deprecation of V2 onion services right around the corner, it is a good time to talk about V3 onion services. This post will discuss the most important privacy improvements provided by V3 onion services as well as their limitations. Aware of those limitations, our research group at the Institute of Network and Security at JKU Linz conducted an experiment that extracts information about how V3 onion services are being used from the Tor network.

Privacy improvements in V3

The most obvious difference between V2 and V3 onion services is the different address format. V3 onion addresses have 56 characters instead of 16 (because they contain a full ed25519 public key, not just the hash of a public key), meaning that migrating from V2 to V3 requires all users to learn/remember/save a new onion address address.

The main reason behind this change is tied to a key component of all onion services, the hidden service directory. Its purpose is to provide the information needed to connect to a specified onion address (just like the DNS system does for regular domain names). To protect the privacy of onion service users, the hidden service directory is a distributed hash table formed by all Tor relays which possess the HSDir flag. For V2 onion services, the data published in the hidden service directory is uploaded in plain text, meaning that the Tor relays with the HSDir flag can learn a lot of information about a small fraction of running V2 onion services (most importantly the onion address) every day.

Note that collecting and probing V2 onion addresses via HSDir relays is considered malicious behavior and sanctioned by Tor’s bad-relays team.

V3 uses encryption and key derivation to address this issue. Since the V3 address is itself a public key, all the data uploaded to the hidden service directory can be encrypted. Clients can always decrypt that data with the key embedded in the .onion address. However, clients still need to ask the directory for information about a specific onion address, which would again allow mass collection of onion addresses. With V3 onion services, this is prevented by using key derivation to derive a daily-rotated identifier ("blinded public key").

So instead of asking the hidden service directory for facebookwkhpilnemxj7asaniu7vnjjbiltxjqhye3mhbshg7kx5tfyd.onion, the Tor client automatically calculates the current identifier from the onion address and the current date (e.g. 2021-08-19), and asks for that blinded public key (here: ek4gJEtlHmwwadLvMNG7tYx/lJuJN1zQl6pMVkGmAcM).

Collectable information

Thanks to these improvements, V3 onion services leak much less sensitive information. However, these changes do not completely stop the hidden service directory from revealing interesting metadata.

First, it is possible to estimate the number of running onion services by counting the number of uploaded blinded public keys because every onion address translates to exactly one blinded public key per day. This means that it is possible to count onion addresses by counting blinded public keys which is already used by the Tor Project to collect statistical information about the number V3 onion services since Tor version 0.4.6.1-alpha (just like they have been doing for V2 for a long time now). This is expected to increase as soon as a sufficient number of Tor relays start to report data allowing for reliable V3 statistics (hint: remember to keep your Tor relays up-to-date).

By collecting detailed logs of uploads and downloads of blinded public keys, HSDir relays can track many more statistical metrics about V3 onion services and their usage. For example, one could track how many uploaded blinded public keys are never requested or how many client requests for blinded public keys could not be answered.

To get a feeling for how interesting this data might be, we designed an experiment where we deployed 50 relays with the HSDir flag and modified them to log every upload and download of blinded public keys. We tried our best to set this up in a privacy-friendly way that does not endanger individual Tor users by reducing the precision of timestamps and randomly sorting our database to destroy order. In addition, we actively asked for feedback on our experiment design from the Tor research safety board (which we integrated in our setup) and even created a plan on what to do if law enforcement would show up with a warrant (which thankfully did not happen so far).

Some results

After walking you through all the theory it’s time to share some of the data we collected since deploying our relays on March 1st, 2021. During this period we registered more than 131 million uploads for ~4.5 million different blinded public keys and more than 225 million download attempts for ~3.4 million different blinded public keys. A nice example for utilizing information about downloads is to track how many blinded public keys uploaded to our servers were actually downloaded.

In the same fashion we can also check how many download attempts we received that could not be answered because they requested keys that had never been uploaded to us.

Venn diagram - v3 onion services

Our Venn diagram shows that a vast majority of uploaded blinded public keys are never downloaded, indicating that these onion services are barely used.

In case you are wondering how an onion service can be used if we do not see any downloads for it, that is due to the redundant nature of the hidden service directory. There is always more than just one relay to download from (by default 6 HSDir relays are responsible for a blinded public key). So even if we see zero downloads, other relays might have seen some, making it impossible to distinguish unused and barely used onion services in our data.

We also see that the majority of download requests asked for blinded public keys that had never been uploaded to us. Again, this does not mean that clients see this failure (because Tor tries all 6 responsible HSDir nodes before giving up) but it indicates that lots of requests for .onion addresses ask for services that are no longer operational. A particularly interesting finding was that a few blinded public keys receive a huge amount of download requests without ever being uploaded to our relays.

In our data we identified 14 blinded public keys with more than 2 million download attempts despite not having any upload attempt. This indicates that a few onion services (or even only one?) are frequently requested although they are not operational. We believe this pattern to be the product of either DDOS attacks against a specific onion service or members of a defunct botnet trying to reach their C&C server.

Let's wrap this post up with an estimate on the number of V3 onion services that have already been deployed in the Tor network:

Tor consensus

Note that our experiment collects data from 50 Tor relays which accounts for only about 1% of the hidden service directory. Therefore, our results give a first good estimate on the total number of V3 onion services but are certainly not as reliable as you would expect for statistics at Tor metrics. Nevertheless, it is certain that the number of deployed V3 onion services has been on the rise throughout 2021. So if you still operate only a V2 onion service, now would be a great time to get on board and upgrade to V3.

Finally, if you are interested in more details on our experiment setup and results, read the full paper: On the state of V3 onion services (by T. Hoeller, M. Roland, R. Mayrhofer).

And if you happen to operate a V3 onion service that suffered a DDOS attack in 2021 or know a botnet that uses a V3 onion service and are willing to share that information with me, please get in touch with me at tobias[dot]hoeller[at]ins[dot]jku[dot]at.

...
@blog September 17, 2021 - 18:57 • 1 months ago
New Alpha Release: Tor 0.4.7.1-alpha
New Alpha Release: Tor 0.4.7.1-alpha ahf September 17, 2021

There's a new alpha release available for download. If you build Tor from source, you can download the source code for 0.4.7.1-alpha from the download page on the website. Packages should be available over the coming weeks, with a new alpha Tor Browser release likely some time next week.

Remember, this is an alpha release: you should only run this if you'd like to find and report more bugs than usual.

This version is the first alpha release of the 0.4.7.x series. One major feature is Vanguards Lite, from proposal 333, to help mitigate guard discovery attacks against onion services. It also includes numerous bugfixes.

Changes in version 0.4.7.1-alpha - 2021-09-17

  • Major features (Proposal 332, onion services, guard selection algorithm):
    • Clients and onion services now choose four long-lived "layer 2" guard relays for use as the middle hop in all onion circuits. These relays are kept in place for a randomized duration averaging 1 week. This mitigates guard discovery attacks against clients and short-lived onion services such as OnionShare. Long-lived onion services that need high security should still use the Vanguards addon (https://github.com/mikeperry-tor/vanguards). Closes ticket 40363; implements proposal 333.
  • Minor features (bridge testing support):
    • Let external bridge reachability testing tools discard cached bridge descriptors when setting new bridges, so they can be sure to get a clean reachability test. Implements ticket 40209.

 

  • Minor features (fuzzing):
    • When building with --enable-libfuzzer, use a set of compiler flags that works with more recent versions of the library. Previously we were using a set of flags from 2017. Closes ticket 40407.
  • Minor features (testing configuration):
    • When TestingTorNetwork is enabled, skip the permissions check on hidden service directories. Closes ticket 40338.
    • On a testing network, relays can now use the TestingMinTimeToReportBandwidth option to change the smallest amount of time over which they're willing to report their observed maximum bandwidth. Previously, this was fixed at 1 day. For safety, values under 2 hours are only supported on testing networks. Part of a fix for ticket 40337.
    • Relays on testing networks no longer rate-limit how frequently they are willing to report new bandwidth measurements. Part of a fix for ticket 40337.
    • Relays on testing networks now report their observed bandwidths immediately from startup. Previously, they waited until they had been running for a full day. Closes ticket 40337.
  • Minor bugfixes (circuit padding):
    • Don't send STOP circuit padding cells when the other side has already shut down the corresponding padding machine. Fixes bug 40435; bugfix on 0.4.0.1-alpha.
  • Minor bugfixes (compatibility):
    • Fix compatibility with the most recent Libevent versions, which no longer have an evdns_set_random_bytes() function. Because this function has been a no-op since Libevent 2.0.4-alpha, it is safe for us to just stop calling it. Fixes bug 40371; bugfix on 0.2.1.7-alpha.
  • Minor bugfixes (control, sandbox):
    • Allows the control command SAVECONF to succeed when the seccomp sandbox is enabled. Makes SAVECONF keep only one backup file, to simplify implementation. Fixes bug 40317; bugfix on 0.2.5.4-alpha. Patch by Daniel Pinto.
  • Minor bugfixes (heartbeat):
    • Adjust the heartbeat log message about distinct clients to consider the HeartbeatPeriod rather than a flat 6-hour delay. Fixes bug 40330; bugfix on 0.2.6.3-alpha.
  • Minor bugfixes (logging, relay):
    • Add spaces between the "and" when logging the "Your server has not managed to confirm reachability for its" on dual-stack relays. Fixes bug 40453; bugfix on 0.4.5.1-alpha. Patch by Neel Chauhan.
  • Minor bugfixes (onion service):
    • Do not flag an HSDir as non-running in case the descriptor upload or fetch fails. An onion service closes pending directory connections before uploading a new descriptor which leads to wrongly flagging many relays and thus affecting circuit path selection. Fixes bug 40434; bugfix on 0.2.0.13-alpha.
  • Minor bugfixes (statistics):
    • Fix a fencepost issue when we check stability_last_downrated where we called rep_hist_downrate_old_runs() twice. Fixes bug 40394; bugfix on 0.2.0.5-alpha. Patch by Neel Chauhan.
  • Minor bugfixes (tests):
    • Fix a bug that prevented some tests from running with the correct names. Fixes bug 40365; bugfix on 0.4.3.1-alpha.
  • Documentation:
    • Add links to original tor design paper and anonbib to docs/HACKING/README.1st.md. Closes ticket 33742. Patch from Emily Bones.
    • Describe the "fingerprint-ed25519" file in the tor.1 man page. Fixes bug 40467; bugfix on 0.4.3.1-alpha. Patch by Neel Chauhan.
...
@ooni September 17, 2021 - 00:00 • 1 months ago
Job Opening: Mobile Developer for OONI Probe
Are you a mobile developer interested in defending human rights on the internet? We have a job opening for you! The OONI team (a non-profit fighting internet censorship, originally born out of the Tor Project) is looking for a dedicated mobile developer to work on OONI Probe: a free software app designed to measure internet censorship and network performance. The application deadline is Sunday, 31st October 2021. Job description If you join our team, you will lead the development of the OONI Probe mobile app, supporting human rights defenders worldwide to investigate and fight internet censorship. ...
@ooni September 10, 2021 - 00:00 • 1 months ago
Italy blocks Gutenberg book publishing website
Cases of internet censorship (that affect public interest) are rarely reported in Europe. Yet, www.gutenberg.org, a book-publishing website run by a non-profit organization, has been blocked in Italy since May 2020. In this report, we share OONI network measurement data on the ongoing blocking of www.gutenberg.org across networks in Italy. Background Methods Findings Blocking methods by ISP Vodafone Italia (AS30722) ...
@blog September 8, 2021 - 18:43 • 1 months ago
New Release: Tor Browser 10.5.6 (Windows, macOS, Linux)
New Release: Tor Browser 10.5.6 (Windows, macOS, Linux) sysrqb September 08, 2021

Tor Browser 10.5.6 is now available from the Tor Browser download page and also from our distribution directory.

This version updates Firefox to 78.14.0esr. This version includes important security updates to Firefox.

Warning:
Tor Browser will stop supporting version 2 onion services very soon. Please see the previously published deprecation timeline. Migrate your services and update your bookmarks to version 3 onion services as soon as possible.

The full changelog since Tor Browser 10.5.5:

  • Windows + OS X + Linux
    • Update Firefox to 78.14.0esr
    • Update Openssl to 1.1.1l
  • Build System
    • OS X
      • Bug 40358: Make OpenSSL 1.1.1l buildable for macOS
...
@blog September 7, 2021 - 12:21 • 1 months ago
New Release: Tails 4.22
New Release: Tails 4.22 Tails September 07, 2021

In Tails 4.22, we focused on solving the most important issues in the Tor Connection assistant to make it more robust and easier to use.

Changes and updates

Included software and hardware support

  • Update Tor Browser to 10.5.6.
  • Update Thunderbird to 78.13.
  • Update the AMD graphics firmware to 20210818. This should improve the support for some AMD graphics cards.

Tor Connection

  • Change the custom bridge interface to only allow entering 1 bridge. (#18550)
    People had troubles knowing how to enter their custom bridges when the widget was a textarea and only the first bridge is used anyway.
  • Allow saving 1 custom bridge in the Persistent Storage. (#5461)
  • Allow fixing the clock manually when connecting to Tor using bridges fails. (#15548)
    This helps people East from London connect to Tor using obfs4 bridges and makes connecting to Tor more robust in general.
  • Reduce the timeout that determines whether we can connect to Tor at all from 30 seconds to 10 seconds. Increase the timeout to start Tor entirely from 120 seconds to 600 seconds. (#18501).
    Tor Connection now fails quicker when it's impossible to connect to Tor, while being more robust on slow Internet connections.
  • Allow trying again to connect to Tor from the error screen. (#18539)

Unsafe Browser

  • Stop restarting Tor when exiting the Unsafe Browser. (#18562)
  • Only mention the Persistent Storage in the Unsafe Browser warning when there is already a Persistent Storage. (#18551)

Others

  • Make sure that automatic upgrades are downloaded from a working mirror. (#15755)
  • Add Russian to the offline documentation included in Tails.

Fixed problems

Tor Connection

  • Fix connecting to Tor using the default bridges. (#18462)
  • Fix connecting to Tor when the Wi-Fi settings are saved in the Persistent Storage. (#18532)
  • Stop trying to connect to Tor in the background when Tor Connection reaches the error screen. (#18740)

For more details, read our changelog.

Known issues

None specific to this release.
See the list of long-standing issues.

Get Tails 4.22

To upgrade your Tails USB stick and keep your persistent storage

To install Tails on a new USB stick

Follow our installation instructions:

The Persistent Storage on the USB stick will be lost if you install instead of upgrading.

To download only

If you don't need installation or upgrade instructions, you can download Tails 4.22 directly:

What's coming up?

Tails 4.23 is scheduled for October 5.
Have a look at our roadmap to see where we are heading to.

Support and feedback

For support and feedback, visit the Support section on the Tails website.

...
@anarcat September 5, 2021 - 18:40 • 2 months ago
Automating major Debian upgrades

It's major upgrade time again! The Debian project just published the Debian 11 "bullseye" release, and it's pretty awesome! This makes me realized that I have never written here about my peculiar upgrade process, and figured it was worth bringing that up to a wider audience.

My upgrade process also has a notable changes section which includes major version changes (e.g. Inkscape 1.0!), new packages (e.g. podman!) and important behavior changes (e.g. driverless scanning and printing!).

I'm particularly interested to hear about any significant change I might have missed. If you know of a cool new package that shipped with bullseye and that I forgot, do let me know!

But that's for the cool new stuff. We need to talk about the problems with Debian major upgrades.

Background

I have been maintaining detailed upgrade guides, on my wiki, starting with the jessie release, but I have actually written such guides for Koumbit.org as far back as Debian squeeze in 2011 (another worker wrote the older Debian lenny upgrade guide in 2009). Koumbit, since then, has kept maintaining those guides all the way to the latest bullseye upgrade, through 7 major releases!

Over the years, those guides evolved from a quick "cheat-sheet" format copied from the release notes into a more or less "scripted" form that I currently use.

Each guide has a procedure made of a few steps that can be basically copy-pasted to batch-upgrade a host (or multiple hosts in parallel) as quickly as possible. There is also the predict-os script which allows you to keep track of progress of the upgrades in a Puppet cluster.

Limitations of the official procedure

In comparison with my procedure, the official upgrade guide is mostly designed to upgrade a single machine, typically a workstation, with a rather slow and exhaustive process. The PDF version of the upgrade guide is 14 pages long! This, obviously, does not work when you have tens or hundreds of machines to upgrade.

Debian upgrades are notorious for being extremely reliable, but we have a lot of packages, and there are always corner cases where the upgrade will just fail because of a bug specific to your environment. Those will only be fixed after some back and forth in the community (and that's assuming users report those bugs, which is not always the case). There's no obvious way to deploy "hot fixes" in this context, at least not without fixing the package and publishing it on an unofficial Debian archive while the official ones catch up. This is slow and difficult.

Or some packages require manual labor. Examples of this are the PostgreSQL or Ganeti packages which require you to upgrade your clusters by hand, while the old and new packages live side by side. Debian packages bring you far in the upgrade process, but sometimes not all the way.

Which means every Debian install needs to be manually upgraded and inspected when a new release comes out. That's slow and error prone and we can do better.

How to automate major upgrades

I have a proposal to automate this. It's been mostly dormant in the Debian wiki, for 5 years now. Fundamentally, this is a hard problem: Debian gets installed in so many different environments, from workstations to physical servers to virtual machines, embedded systems and so on, that it's extremely hard to come up with a "one size fits all" system.

The (manual) procedure I'm using is mostly targeting servers, but I'm also using it on workstations. And I'll note that it's specific to my home setup: I have a different procedure at work, although it has a lot of common code.

To automate this, I would factor out that common code with hooks where you could easily inject special code like "you need to upgrade ferm first", "you need an extra reboot here", or "this is how you finish the PostgreSQL upgrade".

With Debian getting closer to a 2 year release cycle, with the previous release being supported basically only one year after the new stable comes out, I feel more and more strongly that this needs better automation.

So I'm thinking that I should write a prototype for this. Ubuntu has do-release-upgrade that is too Ubuntu-specific to be reused. An attempt at collaborating on this has been mostly met with silence from Ubuntu's side as well.

I'm thinking that using something like Fabric, Mitogen, or Transilience: anything that will allow me to write simple, portable Python code that can run transparently on a local machine (for single systems upgrades, possibly with a GUI frontend) to remote servers (for large clusters of servers, maybe with canaries and grouping using Cumin). I'll note that Koumbit started experimenting with Puppet Bolt in the bullseye upgrade process, but that feels too site-specific to be useful more broadly.

Trade-offs

I am not sure where this stands in the XKCD time trade-off evaluation, because the table doesn't actually cover the time frequency of Debian release (which is basically "biennial") and the amount of time the upgrade would take across a cluster (which varies a lot, but that I estimate to be between one to 6 hours per machine).

Assuming I have 80 machines to upgrade, that is 80 to 480 hours (between ~3 to 20 days) of work! It's unclear how much work such an automated system would shave off, however. Assuming things are an order of magnitude faster (say I upgrade 10 machines at a time), I would shave off between 3 and 18 days of work, which implies I might allow myself to spend a minimum of 5 days working on such a project.

The other option: never upgrade

Before people mention those: I am aware of containers, Kubernetes, and other deployment mechanisms. Indeed, those may be a long-term solution, we currently can't afford to migrate everything over to containers right now: that is a huge migration and a total paradigm shift. At that point, whatever is left might not even be Debian in the first place. And besides, if you run Kubernetes, you still need to run some OS underneath and upgrade that, so that problem never completely disappears.

Still, maybe that's the final answer: never upgrade.

For some stateless machines like DNS replicas or load balancers, that might make a lot of sense as there's no or little data to carry to the new host. But this implies a seamless and fast provisioning process, and we don't have that either: at my work, installing a machine takes about as long as upgrading it, and that's after a significant amount of work automating that process, partly writing my own Debian installer with Fabric (!).

What is your process?

I'm curious to hear what people think of those ideas. It strikes me as really odd that no one has really tackled that problem yet, considering how many clusters of Debian machines are out there. Surely people are upgrading those, and not following that slow step by step guide, right?

I suspect everyone is doing the same thing: we all have our little copy-paste script we batch onto multiple machines, sometimes in parallel. That is what the Debian.org sysadmins are doing as well.

There must be a better way. What is yours?

My upgrades so far

So far, I have upgraded 2 out of my 3 home machines running buster -- others have been installed directly in bullseye -- with only my main, old, messy server left. Upgrades have been pretty painless so far (see another report, for example), much better than the previous buster upgrade. Obviously, for me personal use, automating this is pointless.

Work-side, however, is another story: we have over 80 boxes to upgrade there and that will take a while. The last stretch to buster cycle took about two years to complete, so we might be done by the time the next release (12, "bookworm") is released, but that's actually a full year after "buster" becomes EOL, so it's actually too late...

At least I fixed the installers so that new the machines we create all ship with bullseye, so we stopped accumulating new buster hosts...

Thanks to lelutin and pabs for reviewing a draft of this post.

...
@atagar September 3, 2021 - 21:49 • 2 months ago
Status Report for August 2021

Howdy all! I hope everyone is riding out this delta covid surge reasonably well.

This will likely be my last Pywikibot report. My code reviews are stuck and working on Pywikibot is remarkably lonely. Pywikibot is neat, but it’s difficult to stay interested when my contributions dawdle on a shelf. C’est la vie.

Roman Colosseum

In lieu of code I’m binging Death Throes of the Republic. Rome’s collapse began with the senate’s murder of the reformer Tiberius Gracchus. Breaking the norm against political violence just once spiraled out of control into a tit-for-tat revenge cycle that must have horrified its original perpetrators.

Rome offers a troubling warning of what the January 6th lynch mob could have begun. Folks, lets not play with fire.


Type Hints

Prior to my Rome binge I doubled down on Pywikibot’s type hints. Poor Xqt. I kinda buried him in code reviews…

...
@kushal September 3, 2021 - 02:21 • 2 months ago
Default values, documentation and Ansible

While testing my qubes_ansible project on the upcoming Qubes OS 4.1 project, I noticed something really strange. But, before getting into that, this Ansible module and the connection plugin are for Qubes OS only, and based on the excellent Python modules provided by the Qubes team.

The error goes like this during the fact gathering steps (reformatted for the blog):

fatal: [debian-10]: UNREACHABLE! => {
    "changed": false,
    "msg": "Failed to create temporary directory.In some cases, you may have
    been able to authenticate and did not have permissions on the target
    directory. Consider changing the remote tmp path in ansible.cfg to a path
    rooted in \"/tmp\", for more error information use -vvv. Failed command
    was: ( umask 77 && mkdir -p \"` echo ~The *user* is the default user in
    Qubes./.ansible/tmp `\"&& mkdir \"` echo ~The *user* is the default user in
    Qubes./.ansible/tmp/ansible-tmp-1630548982.9355698-7707-90110802425258 `\"
    && echo ansible-tmp-1630548982.9355698-7707-90110802425258=\"` echo ~The
    *user* is the default user in
    Qubes./.ansible/tmp/ansible-tmp-1630548982.9355698-7707-90110802425258 `\"
    ), exited with result 1, stderr output: mkdir: cannot create directory
    ‘~The ~The *user* account as default in Qubes OS. ~The ~The *user* account
    as default in Qubes OS. account as default in Qubes OS. ~The ~The *user*
    account as default in Qubes OS. ~The ~The *user* account as default in
    Qubes OS. account as default in Qubes OS. account as default in Qubes OS.
    is the default user in Qubes.’: File name too long\n",
    "unreachable": true
}

Most important part is the default user's home directory part, echo ~The user is the default user in Qubes./.ansible/tmp. For a moment I totally freaked out, as this looks like documentation. After reading the code more, I can see it is coming from the DOCUMENTATION variable in my plugin. After playing around a bit more and trying out different values I can see that the default value mentioned in the documentation is becoming the default value in the Python code.

After searching more I can see that the Ansible developers want the documentation string to be the gold standard and the code is parsing it find the default values. In my mind this is more confusing. I would expect the default value to be declared inside of the code.

Parsing the DOCUMENTATION and then finding the default values there in a Python code still does not fit in my brain. Fixed the issue for now, let me see what other surprises are waiting in the future.

...
@blog September 2, 2021 - 12:00 • 2 months ago
New Release: Tor Browser 11.0a6 (Android Only)
New Release: Tor Browser 11.0a6 (Android Only) sysrqb September 02, 2021

Tor Browser 11.0a6 is now available from the Tor Browser download page and also from our distribution directory.

Note: This is an alpha release, an experimental version for users who want to help us test new features. For everyone else, we recommend downloading the latest stable release instead.

This version updates Fenix's Geckoview component to 92.0b9.

Warning:
Tor Browser Alpha does not support version 2 onion services. Tor Browser (Stable) will stop supporting version 2 onion services very soon. Please see the deprecation F.A.Q. entry regarding Tor version 0.4.6. Migrate your services and update your bookmarks to version 3 onion services as soon as possible.

The full changelog since Tor Browser 11.0a5:

  • Android
    • Bug 40611: Rebase geckoview patches onto 92.0b9
...
@ooni August 31, 2021 - 00:00 • 2 months ago
No Access: LGBTIQ Website Censorship in Six Countries
Today, in collaboration with OutRight Action International and the Citizen Lab, we are excited to share our new research report, “No Access: LGBTIQ Website Censorship in Six Countries”, which examines the blocking of LGBTIQ websites in Indonesia, Malaysia, Iran, Russia, Saudi Arabia, and the United Arab Emirates (UAE). READ FULL REPORT Annotated Bibliography Below we share some of our key research findings. Summary of findings We joined forces with OutRight Action International and the Citizen Lab to examine the blocking of LGBTIQ websites in six countries: Indonesia, Malaysia, Iran, Russia, Saudi Arabia, and the United Arab Emirates (UAE). ...
@blog August 24, 2021 - 15:36 • 2 months ago
New Release: Tor Browser 11.0a5
New Release: Tor Browser 11.0a5 sysrqb August 24, 2021

Tor Browser 11.0a5 is now available from the Tor Browser download page and also from our distribution directory.

Note: This is an alpha release, an experimental version for users who want to help us test new features. For everyone else, we recommend downloading the latest stable release instead.

This version updates Tor to 0.4.6.7 that includes a fix for a security issue. On Android, this version updates Firefox to 91.2.0.

Warning:
Tor Browser Alpha does not support version 2 onion services. Tor Browser (Stable) will stop supporting version 2 onion services very soon. Please see the deprecation F.A.Q. entry regarding Tor version 0.4.6. Migrate your services and update your bookmarks to version 3 onion services as soon as possible.

The full changelog since Tor Browser 11.0a4:

  • All Platforms
    • Update Tor to 0.4.6.7
  • Linux
    • Bug 40582: Tor Browser 10.5.2 tabs always crash on Fedora Xfce Rawhide
  • Android
    • Update Fenix to 91.2.0
...
@ooni August 24, 2021 - 00:00 • 2 months ago
Mining OONI data
OONI receives measurement data from OONI Probes around the world and processes it in real-time to detect censorship. There are different ways to access the output of the processing: OONI Explorer, the OONI API and dumps of the PostgreSQL database. OONI Explorer provides a user-friendly web interface to all visitors. The OONI API is meant for developers and researches and allows searching for measurement metadata, fetching single measurements, and generating statistics. ...