Planet Tor

@kushal October 21, 2020 - 06:34 • a day ago
Fixing errors on my blog's feed

For the last few weeks, my blog feed was not showing up in the Fedora Planet. While trying to figure out what is wrong, Nirik pointed me to the 4 errors in the feed according to the W3C validator. If you don't know, I use a self developed Rust application called khata for my static blog. This means I had to fix these errors.

  • Missing guid, just adding the guid to the feed items solved this.
  • Relative URLs, this had to be fixed via the pulldown_cmark parser.
  • Datetime error as error said "not RFC822" value. I am using chrono library, and was using to_rfc2822 call. Now, creating by hand with format RFC822 value.
  • There is still one open issue dependent on the upstream fix.

The changes are in the git. I am using a build from there. I will make a release after the final remaining issue is fixed.

Oh, I also noticed how bad the code looks now as I can understand Rust better :)

Also, the other Planets, like Python and Tor, are still working for my feed.

...
@blog October 21, 2020 - 04:13 • a day ago
New Release: Tor Browser 10.5a2
New Release: Tor Browser 10.5a2 sysrqb October 20, 2020

Tor Browser 10.5a2 for Desktop platforms is now available from the Tor Browser Alpha 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.

Tor Browser 10.5a2 ships with Firefox 78.4.0esr, updates NoScript to 11.1.3, and OpenSSL to 1.1.1h. This release includes important security updates to Firefox.

Note: Tor Browser 10.5 does not support CentOS 6.

Note: We encountered updater issues for all alpha users that have been auto-updating the alpha series for months. We changed the accepted MAR channel ID to torbrowser-torproject-alpha as we are on an alpha channel. The assumption was that enough time passed since we changed it last time to torbrowser-torproject-release,torbrowser-torproject-alpha but it turns out that change did not get applied. Workaround: change the torbrowser-torproject-release in your update-settings.ini (in the Browser's code directory, which depends on you operating system) file to torbrowser-torproject-alpha and the update should get applied successfully. Alternatively, downloading a fresh alpha copy of Tor Browser works as well. Sorry for the inconvenience.

Note: Now Javascript on the Safest security level is governed by NoScript again. It was set as false when on Safest in 9.5a9. The javascript.enabled preference was reset to true beginning in Tor Browser 10.5a1 for everyone using Safest and you must re-set it as false if that is your preference.

The full changelog since Tor Browser 10.5a1 is:

  • Windows + OS X + Linux
    • Update Firefox to 78.4.0esr
    • Update NoScript to 11.1.3
    • Update OpenSSL to 1.1.1h
    • Update Tor Launcher to 0.2.26
      • Translations update
    • Bug 31767: Avoid using intl.locale.requested preference directly
    • Bug 33954: Consider different approach for Bug 2176
    • Bug 40011: Rename tor-browser-brand.ftl to brand.ftl
    • Bug 40012: Fix about:tor not loading some images in 82
    • Bug 40013: End of year 2020 Fundraising campaign
    • Bug 40016: Fix onion pattern for LTR locales
    • Bug 40139: Update Onboarding icon for 10.0
    • Bug 40148: Disable Picture-in-Picture until we investigate and possibly fix it
    • Bug 40166: Disable security.certerrors.mitm.auto_enable_enterprise_roots
    • Bug 40192: Backport Mozilla Bug 1658881
    • Translations update
  • Windows
    • Bug 40140: Videos stop working with Tor Browser 10.0 on Windows
  • Build System
    • Windows + OS X + Linux
      • Update Go to 1.14.10
      • Bug 40104: Use our TMPDIR when creating our .mar files
    • Linux
      • Bug 40118: Add missing libdrm dev package to firefox container
    • Windows
...
@blog October 20, 2020 - 17:42 • 2 days ago
New Release: Tor Browser 10.0.2
New Release: Tor Browser 10.0.2 sysrqb October 20, 2020

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

This release updates Firefox to 78.4.0esr and NoScript to 11.1.3. This release includes important security updates to Firefox.

Note: Now Javascript on the Safest security level is governed by NoScript again. It was set as false when on Safest in 9.5a9. The javascript.enabled preference was reset to true for everyone using Safest beginning in Tor Browser 10.0 and you must re-set it as false if that is your preference.

The full changelog since Tor Browser 10.0.1 is:

  • Windows + OS X + Linux
    • Update Firefox to 78.4.0esr
    • Update NoScript to 11.1.3
    • Bug 40192: Backport Mozilla Bug 1658881
    • Translations update
  • Linux
...
@anarcat October 19, 2020 - 15:08 • 3 days ago
SSH 2FA with Google Authenticator and Yubikey

About a lifetime ago (5 years), I wrote a tutorial on how to configure my Yubikey for OpenPGP signing, SSH authentication and SSH 2FA. In there, I used the libpam-oath PAM plugin for authentication, but it turns out that had too many problems: users couldn't edit their own 2FA tokens and I had to patch it to avoid forcing 2FA on all users. The latter was merged in the Debian package, but never upstream, and the former was never fixed at all. So I started looking at alternatives and found the Google Authenticator libpam plugin. A priori, it's designed to work with phones and the Google Authenticator app, but there's no reason why it shouldn't work with hardware tokens like the Yubikey. Both use the standard HOTP protocol so it should "just work".

After some fiddling, it turns out I was right and you can authenticate with a Yubikey over SSH. Here's that procedure so you don't have to second-guess it yourself.

Installation

On Debian, the PAM module is shipped in the google-authenticator source package:

apt install libpam-google-authenticator

Then you need to add the module in your PAM stack somewhere. Since I only use it for SSH, I added this line on top of /etc/pam.d/sshd:

auth required pam_google_authenticator.so nullok

I also used no_increment_hotp debug while debugging to avoid having to renew the token all the time and have more information about failures in the logs.

Then reload ssh (not sure that's actually necessary):

service ssh reload

Creating or replacing tokens

To create a new key, run this command on the server:

google-authenticator -c

This will prompt you for a bunch of questions. To get them all right, I prefer to just call the right ones on the commandline directly:

google-authenticator --counter-based --qr-mode=NONE --rate-limit=1 --rate-time=30 --emergency-codes=1 --window-size=3

Those are actually the defaults, if my memory serves me right, except for the --qr-mode and --emergency-codes (which can't be disabled so I only print one). I disable the QR code display because I won't be using the codes on my phone, but you would obviously keep it if you want to use the app.

Converting to a Yubikey-compatible secret

Unfortunately, the encoding (base32) produced by the google-authenticator command is not compatible with the token expected by the ykpersonalize command used to configure the Yubikey (base16 AKA "hexadecimal", with a fixed 20 bytes length). So you need a way to convert between the two. I wrote a program called oath-convert which basically does this:

read base32
add padding
convert to hex
print

Or, in Python:

def convert_b32_b16(data_b32):
    remainder = len(data_b32) % 8
    if remainder > 0:
        # XXX: assume 6 chars are missing, the actual padding may vary:
        # https://tools.ietf.org/html/rfc3548#section-5
        data_b32 += "======"
    data_b16 = base64.b32decode(data_b32)
    if len(data_b16) < 20:
        # pad to 20 bytes
        data_b16 += b"\x00" * (20 - len(data_b16))
    return binascii.hexlify(data_b16).decode("ascii")

Note that the code assumes a certain token length and will not work correctly for other sizes. To use the program, simply call it with:

head -1 .google_authenticator | oath-convert

Then you paste the output in the prompt:

$ ykpersonalize -1 -o oath-hotp -o append-cr -a
Firmware version 3.4.3 Touch level 1541 Program sequence 2
 HMAC key, 20 bytes (40 characters hex) : [SECRET GOES HERE]

Configuration data to be written to key configuration 1:

fixed: m:
uid: n/a
key: h:[SECRET REDACTED]
acc_code: h:000000000000
OATH IMF: h:0
ticket_flags: APPEND_CR|OATH_HOTP
config_flags: 
extended_flags: 

Commit? (y/n) [n]: y

Note that you must NOT pass the -o oath-hotp8 parameter to the ykpersonalize commandline, which we used to do in the Yubikey howto. That is because Google Authenticator tokens are shorter: it's less secure, but it's an acceptable tradeoff considering the plugin is actually maintained. There's actually a feature request to support 8-digit codes so that limitation might eventually be fixed as well.

Thanks to the Google Authenticator people and Yubikey people for their support in establishing this procedure.

...
@kushal October 19, 2020 - 06:29 • 3 days ago
Update hell due to not updating for a long time

SecureDrop right now runs on Ubuntu Xenial. We are working on moving to Ubuntu Focal. Here is the EPIC on the issue tracker.

While I was creating the Docker development environment on Focal, I noticed our tests were failing with the following message:

Traceback (most recent call last):                                                                                            
  File "/opt/venvs/securedrop-app-code/bin/pytest", line 5, in <module>              
    from pytest import console_main
  File "/opt/venvs/securedrop-app-code/lib/python3.8/site-packages/pytest/__init__.py", line 5, in <module>
    from _pytest.assertion import register_assert_rewrite
  File "/opt/venvs/securedrop-app-code/lib/python3.8/site-packages/_pytest/assertion/__init__.py", line 8, in <module>
    from _pytest.assertion import rewrite
  File "/opt/venvs/securedrop-app-code/lib/python3.8/site-packages/_pytest/assertion/rewrite.py", line 31, in <module>
    from _pytest.assertion import util
  File "/opt/venvs/securedrop-app-code/lib/python3.8/site-packages/_pytest/assertion/util.py", line 14, in <module>
    import _pytest._code
  File "/opt/venvs/securedrop-app-code/lib/python3.8/site-packages/_pytest/_code/__init__.py", line 2, in <module>
    from .code import Code
  File "/opt/venvs/securedrop-app-code/lib/python3.8/site-packages/_pytest/_code/code.py", line 29, in <module>
    import pluggy
  File "/opt/venvs/securedrop-app-code/lib/python3.8/site-packages/pluggy/__init__.py", line 16, in <module>
    from .manager import PluginManager, PluginValidationError
  File "/opt/venvs/securedrop-app-code/lib/python3.8/site-packages/pluggy/manager.py", line 6, in <module>
    import importlib_metadata
  File "/opt/venvs/securedrop-app-code/lib/python3.8/site-packages/importlib_metadata/__init__.py", line 471, in <module>
    __version__ = version(__name__)
  File "/opt/venvs/securedrop-app-code/lib/python3.8/site-packages/importlib_metadata/__init__.py", line 438, in version
    return distribution(package).version
  File "/opt/venvs/securedrop-app-code/lib/python3.8/site-packages/importlib_metadata/__init__.py", line 411, in distribution
    return Distribution.from_name(package)
  File "/opt/venvs/securedrop-app-code/lib/python3.8/site-packages/importlib_metadata/__init__.py", line 179, in from_name
    dists = resolver(name)
  File "<frozen importlib._bootstrap_external>", line 1382, in find_distributions
  File "/usr/lib/python3.8/importlib/metadata.py", line 466, in find_distributions
    found = cls._search_paths(context.name, context.path)
AttributeError: 'str' object has no attribute 'name'
make: *** [Makefile:238: test-focal] Error 1


Found out that pluggy dependency is too old. We update all application dependencies whenever there is a security update, but that is not the case with the development or testing requirements. These requirements only get installed on the developers' systems or in the CI. Then I figured that we are using a version of pytest 3 years old. That is why the code refuses to run on Python3.8 on Focal.

The update hell

Now, to update pluggy, I also had to update pytest and pytest-xdist, and that initial issue solved. But, this broke testinfra. Which we use in various molecule scenarios, say to test a staging or production server configurations or to test the Debian package builds. As I updated testinfra, molecule also required an update, which broke due to the old version of molecule in our pinned dependency. Now, to update I had to update molecule.yml and create.yml file for the different scenarios and get molecule-vagrant 0.3. Now, after I can run the molecule scenarios, I noticed that our old way of injecting variables to the pytest namespace via pytest_namespace function does not work. That function was dropped in between. So, had to fix that as the next step. This whole work is going on a draft PR, and meanwhile, some new changes merged with a new scenario. This means I will be spending more time to rebase properly without breaking these scenarios. The time takes to test each one of them, which frustrates me while fixing them one by one.

Lesson learned for me

We should look into all of our dependencies regularly and keep them updated. Otherwise, if we get into a similar situation again, someone else has to cry in a similar fashion :) Also, this is difficult to keep doing in a small team.

...
@anarcat October 18, 2020 - 21:30 • 4 days ago
CDPATH replacements

after reading this post I figured I might as well bite the bullet and improve on my CDPATH-related setup, especially because it does not work with Emacs. so i looked around for autojump-related alternatives that do.

What I use now

I currently have this in my .shenv (sourced by .bashrc):

export CDPATH=".:~:~/src:~/dist:~/wikis:~/go/src:~/src/tor"

This allows me to quickly jump into projects from my home dir, or the "source code" (~/src), "work" (src/tor), or wiki checkouts (~/wikis) directories. It works well from the shell, but unfortunately it's very static: if I want a new directory, I need to edit my config file, restart shells, etc. It also doesn't work from my text editor.

Shell jumpers

Those are commandline tools that can be used from a shell, generally with built-in shell integration so that a shell alias will find the right directory magically, usually by keeping track of the directories visited with cd.

Some of those may or may not have integration in Emacs.

autojump

fasd

z

fzf

Emacs plugins not integrated with the shell

Those projects can be used to track files inside a project or find files around directories, but do not offer the equivalent functionality in the shell.

projectile

elpy

  • home page
  • elpy has a notion of projects, so, by default, will find files in the current "project" with C-c C-f which is useful

bookmarks.el

  • built-in
  • home page
  • "Bookmarks record locations so you can return to them later"

recentf

  • built-in
  • home page
  • "builds a list of recently opened files. This list is is automatically saved across sessions on exiting Emacs - you can then access this list through a command or the menu"

references

https://www.emacswiki.org/emacs/LocateFilesAnywhere

...
@blog October 14, 2020 - 02:44 • 9 days ago
New Release: Tor Browser 10.0.1
New Release: Tor Browser 10.0.1 sysrqb October 13, 2020

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

This release updates NoScript to 11.1.1 and fixes some bugs, including the issue of watching Youtube videos on Windows.

The full changelog since Tor Browser 10.0 is:

  • Windows + OS X + Linux
    • Update NoScript to 11.1.1
    • Update Tor Launcher to 0.2.26
    • Bug 31767: Avoid using intl.locale.requested pref directly
    • Bug 40013: End of year 2020 Fundraising campaign
    • Bug 40016: Fix onion pattern for LTR locales
    • Bug 40139: Update Onboarding icon for 10.0
    • Bug 40148: Disable Picture-in-Picture until we investigate and possibly fix it
    • Translations update
  • Windows
    • Bug 40140: Videos stop working with Tor Browser 10.0 on Windows
  • Build System
    • Windows + OS X + Linux
      • Bump Go to 1.14.9
      • Bump openssl to 1.1.1h
    • Windows
...
@kushal October 13, 2020 - 04:32 • 10 days ago
Updates from Johnnycanencrypt development in last few weeks

In July this year, I wrote a very initial Python module in Rust for OpenPGP, Johnnycanencrypt aka jce. It had very basic encryption, decryption, signing, verification, creation of new keys available. It uses https://sequoia-pgp.org library for the actual implementation.

I wanted to see if I can use such a Python module (which does not call out to the gpg2 executable) in the SecureDrop codebase.

First try (2 weeks ago)

Two weeks ago on the Friday, when I sat down to see if I can start using the module, within a few minutes, I understood it was not possible. The module was missing basic key management, more more refined control over creation, or expiration dates.

On that weekend, I wrote a KeyStore using file-based keys as backend and added most of the required functions to try again.

The last Friday

I sat down again; this time, I had a few friends (including Saptak, Nabarun) on video along with me, and together we tried to plug the jce inside SecureDrop container for Focal. After around 4 hours, we had around 5 failing tests (from 32) in the crypto-related tests. Most of the basic functionality was working, but we are stuck for the last few tests. As I was using the file system to store the keys (in simple .sec or .pub files), it was difficult to figure out the existing keys when multiple processes were creating/deleting keys in the same KeyStore.

Next try via a SQLite based KeyStore

Next, I replaced the KeyStore with an SQLite based backend. Now multiple processes can access the keys properly. With a few other updates, now I have only 1 failing test (where I have to modify the test properly) in that SecureDrop Focal patch.

While doing this experiment, I again found the benefits of writing the documentation of the library as I developed. Most of the time, I had to double-check against it to make sure that I am doing the right calls. I also added one example where one can verify the latest (10.0) Tor Browser download via Python.

In case you already use OpenPGP encryption in your tool/application, or you want to try it, please give jce a try. Works on Python3.7+. I tested on Linux and macOS, and it should work on Windows too. I have an issue open on that, and if you know how to do that, please feel free to submit a PR.

...
@blog October 12, 2020 - 15:52 • 10 days ago
Anti-censorship team report: September 2020
Anti-censorship team report: September 2020 Philipp Winter October 12, 2020

Tor's anti-censorship team writes monthly reports to keep the world updated on its progress. This blog post summarizes the anti-censorship work we got done in September 2020. Let us know if you have any questions or feedback!

Snowflake

  • Merged a contribution from Peter Gerber to consider more IP address ranges local, for the purpose of stripping from SDP offers sent to the broker.

Rdsys

  • Built an HTTP streaming API between rdsys's backend and its distributors that allows distributors to receive resource updates (e.g. a bridge changing its IP address) in real-time.

  • Implemented a registration API that allows standalone-proxies (i.e. without a corresponding Tor bridge) to register themselves:
    https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/4

  • Added lots of unit tests. Rdsys's domain logic is 72.1% tested.

  • Experimented with reCAPTCHA support in rdsys. We could port BridgeDB's HTTPS distributor to rdsys and replace our Gimp-generated CAPTCHAs with Google's reCAPTCHA. To prevent exposing our users to Google, we would have to set up a reverse proxy, so Google only gets to see our machine's IP address. This is possible but messy to build.

  • Started brainstorming Salmon's user interface; in particular how we can best integrate it in Tor Browser:
    https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/7

  • Started writing up rdsys's design and architecture. The goal is to eventually publish a technical blog post that discusses how we built rdsys.

Bridgestrap

Miscellaneous

Outreach

...
@blog October 9, 2020 - 21:33 • 13 days ago
Join the Tor Localization Hackathon November 6 - 9
Join the Tor Localization Hackathon November 6 - 9 Gus October 09, 2020

Between November 6 and 9, the Tor Project and Localization Lab will host the first edition of Tor Project's localization hackathon, the Tor L10n Hackaton. A hackathon is an event where a community hangs out and works together to update, fix, and collaborate on a project. The L10n Hackathon is a totally remote and online event.

In this localization hackathon we're going to work exclusively on the localization of our latest resource, the Tor Community portal. The Community portal is organized into sections: Training, Outreach, Onion Services, Localization, User Research, and Relay Operations. Each section helps users understand how they can get involved in each of these activities to build and strengthen the community supporting the Tor Project.

Localization of Tor Browser and the Community portal are important. Only a minority of internet users are native or second-language speakers of English, however censorship and surveillance are global challenges that affect us all on a daily basis. Ensuring Tor Browser and Tor resources are available in as many languages as possible removes a large barrier to access for those in need of a more secure, anonymous online presence and those who would like to contribute to Tor Project. Tor Browser is currently available to download in 28 languages, and our main website can be read in 11 languages. To support users and build community in all of these languages, it's important to also have the Tor website, Support portal and Community portal localized.

 

During the event, we will have a live Q&A with Tor Project core contributors and open only for the hackathon participants.

Join us!

To participate in the Tor L10n Hackaton

  1. Read and agree to the Tor Project Code of Conduct.
  1. Register to get event updates and gain access to our l10n communication channel, where we will be collaborating throughout the virtual event.
  1. Create an account and join Transifex.
  1. Take a look at the Tor Project localization resources to get up to speed on the Tor Project terminology, translation style, and tone. Check out our Glossary!
  1. This isn't a requirement, but: If you talk about the the hackathon on social media, we're using #TorL10nHackathon.

For more details on how you can contribute, check out the Localization section in the Community portal and the Localization Lab wiki.

We are a small nonprofit with a big mission, and we sincerely appreciate your help getting our documentation up to speed. We look forward to working with you soon.

...
@ooni October 9, 2020 - 00:00 • 14 days ago
OONI Probe ASN Incident Report
Last week we noticed that some OONI measurements were available on OONI Explorer under a report ID containing a valid Autonomous System Number (ASN), even though the raw JSON data contained zero as the ASN (i.e. encoded as AS0). We initially thought that this was caused by a bug in our API code, but it actually turned out to be an OONI Probe bug in our probe engine (which powers the OONI Probe apps). ...
@blog October 8, 2020 - 17:16 • 14 days ago
New Release: Tor Browser 10.0a8 (Android Only)
New Release: Tor Browser 10.0a8 (Android Only) sysrqb October 08, 2020

Android Tor Browser 10.0a8 is now available from the Tor Browser Alpha 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.

We are happy to announce the first alpha for Android users based on Fenix 81. The Desktop version was released at the end of September.

Over the last four months we adjusted our toolchains, finished our proxy audit, re-implemented the user interfaces, and fixed a lot of issues that came down on us due to the switch from Firefox 68esr to Fenix.

Tor Browser 10.0a8 ships with Fenix 81.1.2 (see Mozilla's blog post for more information about this new browser). As this is the first alpha version based on Fenix we expect more bugs than usual. Please report them (with steps to reproduce), either here or on Gitlab, or essentially with any other means that would reach us. We are in particular interested in potential proxy bypasses which our proxy audit missed.

Note: We are aware of two reproducibility issues in this version. The first issue is coming from the ordering of symbols. The second issue is due to the order in which supported locales are added.

The full changelog since Tor Browser 10.0a6 is:

  • Android
    • Update Fenix to 81.1.2
    • Update Tor to 0.4.4.5
    • Update NoScript to 11.0.46
    • Bug 10394: Let Tor Browser update HTTPS Everywhere
    • Bug 11154: Disable TLS 1.0 (and 1.1) by default
    • Bug 16931: Sanitize the add-on blocklist update URL
    • Bug 17374: Disable 1024-DH Encryption by default
    • Bug 21601: Remove unused media.webaudio.enabled pref
    • Bug 30682: Disable Intermediate CA Preloading
    • Bug 30812: Exempt about: pages from Resist Fingerprinting
    • Bug 32886: Separate treatment of @media interaction features for desktop and android
    • Bug 33534: Review FF release notes from FF69 to latest (FF78)
    • Bug 33594: Disable telemetry collection (Glean)
    • Bug 33851: Patch out Parental Controls detection and logging
    • Bug 33856: Set browser.privatebrowsing.forceMediaMemoryCache to True
    • Bug 33862: Fix usages of createTransport API
    • Bug 33962: Uplift patch for bug 5741 (dns leak protection)
    • Bug 34125: API change in protocolProxyService.registerChannelFilter
    • Bug 34338: Disable the crash reporter
    • Bug 34377: Port padlock states for .onion services
    • Bug 34378: Port external helper app prompting
    • Bug 34401: Re-design Connect screen on Android
    • Bug 34402: Re-design Network Settings Screen on Android
    • Bug 34403: UI changes for "Only Private Browsing Mode" on Android
    • Bug 34405: Re-design about:tor on Android
    • Bug 34406: Re-design onion indicators for Android
    • Bug 34407: Review all Fenix menu items
    • Bug 40001: Start Tor as part of the Fenix initialization
    • Bug 40001: Generate tor-browser-brand.ftl when importing translations
    • Bug 40002: Ensure system download manager is not used
    • Bug 40002: Fix generateNSGetFactory being moved to ComponentUtils
    • Bug 40003: Adapt code for L10nRegistry API changes
    • Bug 40004: Fix noscript message passing for Firefox 79
    • Bug 40005: Modify WebExtensions Menu
    • Bug 40006: "Only Private Browsing Mode" on Android
    • Bug 40006: Add Security Level plumbing
    • Bug 40007: Port external helper app prompting
    • Bug 40007: Move SecurityPrefs initialization to the StartupObserver component
    • Bug 40008: Style fixes for 78
    • Bug 40009: Change the default search engines
    • Bug 40010: Verify Sentry is disabled
    • Bug 40011: Verify Leanplum is disabled
    • Bug 40011: Hide option for disallowing addons in private mode
    • Bug 40012: Verify Adjust is disabled
    • Bug 40013: Timestamp is embedded in extension manifest files
    • Bug 40013: Verify InstallReferrer is disabled
    • Bug 40014: Verify Google Ads ID is disabled
    • Bug 40014: Set correct default Security Level
    • Bug 40015: Modify Fenix Home Menu
    • Bug 40016: Modify Fenix Settings Menu
    • Bug 40016: Update Snowflake to discover NAT type
    • Bug 40017: Audit Firefox 68-78 diff for proxy issues
    • Bug 40018: Disable Push functionality
    • Bug 40019: Ensure missing Adjust token does not throw an exception
    • Bug 40023: Rebase Tor Browser esr78 patches onto 80 beta
    • Bug 40026: Implement Security Level settings
    • Bug 40028: Implement bootstrapping and about:tor
    • Bug 40029: Rebase Fenix patches to 81.1.0b1
    • Bug 40030: Install https-everywhere and noscript addons
    • Bug 40031: Hide Mozilla-specific items on About page
    • Bug 40032: Disallow Cleartext Traffic
    • Bug 40034: Disable PWA
    • Bug 40038: Review RemoteSettings for ESR 78
    • Bug 40035: Maybe hide Quick Start in release
    • Bug 40039: Implement Bridge configuration from Connect screen
    • Bug 40040: Investigate why bootstrapping fails
    • Bug 40041: Implement Network settings
    • Bug 40042: Timestamp is embedded in extension manifest files
    • Bug 40044: Fixup Connect, Onboarding, and Home screens
    • Bug 40048: Disable various ESR78 features via prefs
    • Bug 40054: Search engines on mobile Tor Browser don't match the desktop ones
    • Bug 40058: Hide option for disallowing addon in private mode
    • Bug 40061: Do not show "Send to device" in sharing menu
    • Bug 40063: Do not sort search engines alphabetically
    • Bug 40064: Modify Nighty (and Debug) build variants
    • Bug 40066: Remove default bridge 37.218.240.34
    • Bug 40066: Enable Snowflake on Beta
    • Bug 40066: Update existing prefs for ESR 78
    • Bug 40067: Make date on Fenix about page reproducible
    • Bug 40069: Add helpers for message passing with extensions
    • Bug 40072: Bug 40072: Disable Tracking Protection
    • Bug 40073: Repack omni.ja to include builtin HTTPS Everywhere
    • Bug 40073: Disable remote Public Suffix List fetching
    • Bug 40082: Let JavaScript on safest setting handled by NoScript again
    • Bug 40091: Load HTTPS Everywhere as a builtin addon
    • Bug 40095: Review Mozilla developer notes for 79-81 (including)
    • Bug 40096: Review closed Mozilla bugs between 79-81 (inclusive) for GeckoView
    • Bug 40097: Rebase browser patches to 81.0b1
    • Bug 40098: Initialize torbutton for Geckoview and make sure its features work as expected in Fenix
    • Bug 40112: Check that caching stylesheets per document group adheres to FPI
    • Bug 40119: Update Fenix dependencies for 81.1.2
    • Bug 40125: Geckoview: Expose security level interface
    • Bug 40172: Security UI not updated for non-https .onion pages in Fenix
    • Bug 40173: Initialize security_slider in GeckoView at 4
    • Translations update
  • Build System
    • Android
      • Bump Go to 1.14.7
      • Bug 33556: Add TBB project for android-components
      • Bug 33557: Update Android toolchain for Fenix
      • Bug 33558: Update tor-onion-proxy-library to use toolchain for Fenix
      • Bug 33559: Update tor-android-service to use toolchain for Fenix
      • Bug 33561: Update OpenSSL to use Android NDK 20
      • Bug 33563: Update Tor to use Android NDK 20
      • Bug 33564: Update ZSTD to use Android NDK 20
      • Bug 33626: Add project for GeckoView
      • Bug 33670: Update rbm.conf to match NDK 20
      • Bug 33801: Update Go project to use new Android toolchain
      • Bug 33833: Update Rust project to use Android NDK 20
      • Bug 33927: Add tor-browser-build project for fenix
      • Bug 33935: Fenix's classes5.dex files are not reproducible
      • Bug 33973: Create fat .aar for GeckoView
      • Bug 34011: Bump clang to 9.0.1
      • Bug 34012: Bump cbindgen to 0.14.3
      • Bug 34013: Bump Node to 10.21.0
      • Bug 34014: Enable sqlite3 support in Python
      • Bug 34101: Add tor-browser-build project for application-services
      • Bug 34163: testbuild target is broken for Tor Browser 64 bit
      • Bug 34187: Update zlib to use Android NDK 20
      • Bug 40010: Add nss project for application-services
      • Bug 40011: Add sqlcipher for application-services
      • Bug 40029: Clean-up all projects to remove fennec bits we don't need for fenix
      • Bug 40031: Add licenses for kcp-go and smux.
      • Bug 40039: Remove version_path in nss project
      • Bug 40040: Wire geckoview, application-services, android-components, and fenix together
      • Bug 40054: Adapt build.android script in tor-browser project for fenix
      • Bug 40055: Integrate building Glean in offline mode
      • Bug 40057: Include translations into build process in the fenix world
      • Bug 40058: Build Fenix with tor-android-service and tor-onion-proxy-library
      • Bug 40060: Set Fenix Version Name in build
      • Bug 40061: Remove Android SDK 28
      • Bug 40065: Bump debootstrap-image ubuntu_version to 20.04.1
      • Bug 40068: Bump versions for Fenix 81.1.0b1 dependencies
      • Bug 40072: Tor libraries are missing in final .apk after switch to 81.1.0b1
      • Bug 40076: Use our android-components repo on GitLab
      • Bug 40078: Bump Gradle version for Fenix to 6.5.1
      • Bug 40084: Generation of AndroidManifest.xml is not reproducible
      • Bug 40085+40086: classes.dex files are not reproducible in Fenix
      • Bug 40087: Deterministically add HTTPS Everywhere into omni.ja
      • Bug 40088+40117: Use MOZ_BUILD_DATE for extension manifest timestamps
      • Bug 40093: Ensure application-services libs do not include libc networking symbols
      • Bug 40094: Aarch64 fenix rust cross-compilation fails
      • Bug 40095: The pattern for the apk variable in build.android is matching too much
      • Bug 40101: Pick up Fenix 81.1.1
      • Bug 40105: Enhance Gradle dependency script (sort deterministically and exclude .module files)
      • Bug 40106: Support using geckoview as well
      • Bug 40108: android-components does not bundle tooling-glean-gradle archive, only .pom file
      • Bug 40113: Nightly Android should use Nightly branding
...
@kushal October 6, 2020 - 04:05 • 17 days ago
SecureDrop QA workflow and how to improve it?

Right now, we are in the QA period for the SecureDrop 1.6.0 release. SecureDrop is an open-source whistleblower submission system that media organisations and NGOs can install to securely accept documents from anonymous sources. It was originally created by the late Aaron Swartz and is now managed by Freedom of the Press Foundation.

In this blog post I am going to explain how we do the QA for the release. I hope you can suggest some ways to improve the steps and make it better.

A few properties of SecureDrop to keep in mind during QA

  • It is a complex web application that gets auto-updated via the Debian package on the servers running around the world.
  • Security has the highest priority.
  • We (the developers) do not have any access to those servers.
  • Most of the servers are maintained by the system administrator from the news organization who very little time to manage and many times no Linux skill set.
  • It is actually 2 servers per installation.
  • Officially supported hardware list contains a few different generations of Intel NUCs, and Mac Minis.
  • We also provide our own kernel package for these systems.

Test plan

The test plan for each release is tracked on the wiki and linked from the release ticket. Each time, we have the following categories of test cases:

  • Application Acceptance Testing (related to general application usage)
  • Basic Tails testing (for the tails updated GUI tool)
  • Release specific changes for each release (detailed tests for new/updated features/fixes)
  • Preflight check (for the release process itself)

We also have a private QA matrix, where we track things for each supported hardware (for update and new install) in a spreadsheet so that it becomes easier to understand if any basic test (say if the system is booting) is failing.

Please go through the test plan and the workflow. If you have any suggestions, you toot/tweet or email me. Your input is precious to make SecureDrop a better and safer tool for whistleblowers around the world.

...
@blog October 5, 2020 - 09:17 • 17 days ago
Tor Browser and Onion Services - Challenges and Opportunities
Tor Browser and Onion Services - Challenges and Opportunities gk October 05, 2020
Maintaining a browser like Tor Browser has its challenges but also its rewards. It allows us to reach faster adoption of important technologies like onion services, providing a more secure browsing experience for all Tor users. Improving the treatment of onion services on the browser side, however, comes with its own challenges both for users and service providers and it is important to reflect on those as a requirement for future growth. Thus, we feel it is time to take stock in this blog post and outline the steps we have taken over the years to improve the user experience and adoption of onion services, the challenges we faced and continue to face, and what the future might look like.

What does this mean and how did we get here?

Onions services are self-authenticating and provide integrity and confidentiality by default. That means once you are connected to an onion service you can be sure you are talking to the one you tried to reach and your data is not manipulated or read by Man-In-The-Middle-attackers. HTTPS was introduced over 20 years ago to provide some of those properties for plain web traffic (HTTP) when communicating with a server.
 
Three years ago, Mozilla announced their plan for raising awareness about the insecurity of HTTP by introducing a new visual indicator and a username/password warning message for websites loaded over HTTP (instead of HTTPS). Not knowing anything about onion services, the way this was implemented on Mozilla's side was by looking at the scheme in the URL bar: if it is only "http" then the warning kicks in. As a result, the idea of handling connections with onion services as (inherently) "secure" was proposed because these new browser security indicators directly harmed the usability of onion sites, like those hosted by SecureDrop and Riseup. At that time, extended validation (EV) TLS certificates containing .onion addresses were available for web sites that could afford them, and those web sites were already available over HTTPS, but the certificates were too costly for the general public. Domain validation (regular) TLS certificates weren't allowed to contain .onion addresses, and that idea wasn't being considered.
 
With the immediate usability problem, we found a solution that was acceptable by Mozilla for inclusion in Firefox, as well. The solution elevated connections with .onion addresses to a "potentially trustworthy origin," and this was defined by the Web specification as an origin (web site) that the web browser "can generally trust as delivering data securely".
 
As a result of handling an .onion address as a "potentially trustworthy origin", Tor Browser then modified how it dealt with mixed content over onion service connections and "secure cookies". Over the last two years, based on these previous changes, onion service usability has become a primary feature of Tor Browser, and the security and improved usability of onion services are the reason we can run an onion service adoption campaign like #MoreOnionsPorfavor.

Challenges

The features mentioned in the previous section meant a lot of effort for our small team of engineers and designers. Staying on track and delivering them on time has been challenging sometimes. Additionally, we did not have the resources so far to port all of them to mobile. But we keep iterating so that all Tor users are able to benefit from the enhanced security provided by onion services when browsing the web.
 
All those engineering efforts depend on good communication between stakeholders to be effective and lasting. That does not only mean between the different teams within Tor to get the various improvements implemented but external stakeholders as well.
 
Support by browser vendors is crucial, which is why we spent effort on making our changes specification-compliant and getting them upstreamed into Firefox. Mozilla is now even proactively taking the .onion use case into account which is promising for future changes. And other browser vendors have our onion services enhancements in their pipeline as well.
 
We neglected another stakeholder group, though: companies like Facebook, the New York Times, Guardian, BBC and others which started to run onion services in an enterprise environment. The complexities of those environments and the lack of communication in this area led to potential security issues like the one core contributor Alec Muffett recently reported. As a consequence of that we just started to reach out to enterprises we know are running onion services and provide them with help for running those onion services securely. We have a group, called "onion-advisors," where all of those efforts are coordinated to avoid making this mistake again in the future.

What is the future of Tor Browser and Onion Services?

We are going to continue supporting onion services in Tor Browser, both with and without certificates acquired by the onion service owner, and are continuing the trend of enhancing their usability as well. We hope campaigns like #MoreOnionsPorfavor will help increase awareness of onion services and adoption by small and large web sites. As part of these campaigns we will emphasize the importance of deploying onion services that are secure end-to-end so Tor Browser doesn't make a wrong assumption about which data should be sent over HTTP onion connections. We're also currently improving our documentation for onion service operators and making clear Tor Browser's expectations of web sites.
 
The future of TLS support for onion services is very encouraging. In March of this year, the CA/Browser Forum approved an amendment to the domain validation (DV) TLS certificate baseline requirements which now allows certificate authorities (CAs) to issue certificates containing v3 .onion addresses. This means, in the not-too-distant-future, a CA like Let's Encrypt can issue a certificate for an onion service and Tor Browser will "just work." In addition, for onion services that do not want to rely on certificate authorities, we are exploring alternative designs like Same Origin Onion Certificate for inclusion in Tor Browser.
 
While getting TLS support for onion services is important, making sure onion sites without any TLS certificate continue to get a good user experience will remain one of our priorities in the foreseeable future. After all, onion services by themselves already provide the security benefits (and more) TLS is meant to give to users in most of the cases. Additionally, there remains the idea to explore that onion routing is actually the successor of TLS security-wise. We should not give up on that easily by solely jumping on the TLS + .onion train.
 
There are many different scenarios possible for onion service deployment and the role browsers in general and Tor Browser in particular will play in that. Our experimenting so far seems to indicate that the changes in Tor Browser have been worth it even though deploying onion services securely has not always been easy in this fast-moving area. Where we will end up we don't know. The only thing we can say with certainty is that this part of Tor and Tor Browser is still evolving and we are continuing to push the boundaries of a secure, private, safe, and usable web for everyone. Please watch for future improvements in Tor and Tor Browser, and please deploy secure onion services.
...
@anarcat September 30, 2020 - 17:21 • 22 days ago
Presentation tools

I keep forgetting how to make presentations. I had a list of tools in a wiki from a previous job, but that's now private and I don't see why I shouldn't share this (even if for myself!).

So here it is. What's your favorite presentation tool?

Tips

  • if you have some text to present, outline keywords so that you can present your subject without reading every word
  • ideally, don't read from your slides - they are there to help people follow, not for people to read
  • even better: make your slides pretty with only a few words, or don't make slides at all

Further advice:

I'm currently using Pandoc with PDF input (with a trip through LaTeX) for most slides, because PDFs are more reliable and portable than web pages. I've also used Libreoffice, Pinpoint, and S5 (through RST) in the past. I miss Pinpoint, too bad that it died.

Some of my presentations are available in my GitLab.com account:

See also my list of talks and presentations which I can't seem to keep up to date.

Tools

Beamer (LaTeX)

  • LaTeX class
  • Do not use directly unless you are a LaTeX expert or masochist, see Pandoc below
  • see also powerdot
  • Home page

Darkslide

  • HTML, Javascript
  • presenter notes, table of contents, Markdown, RST, Textile, themes, code samples, auto-reload
  • Home page, demo

Impress.js

Impressive

  • simply displays PDFs or images
  • page transitions, overview screen, highlighting
  • Home page

Libreoffice Impress

  • Powerpoint clone
  • Makes my life miserable
  • PDF export, presenter notes, outline view, etc
  • Home page, screenshots

Magicpoint

  • ancestor of everyone else (1997!)
  • text input format, image support, talk timer, slide guides, HTML/Postscript export, draw on slides, X11 output
  • no release since 2008
  • Home page

mdp and lookatme (commandline)

Pandoc

  • Allows converting from basically whatever into slides, including Beamer, DZSlides, reveal.js, slideous, slidy, Powerpoint
  • PDF, HTML, Powerpoint export, presentation notes, full screen background images
  • nice plain text or markdown input format
  • Home page, documentation

PDF Presenter

  • PDF presentation tool, shows presentation notes
  • basically "Keynote for Linux"
  • Home page, pdf-presenter-console in Debian

Pinpoint

  • Native GNOME app
  • Full screen slides, PDF export, live change, presenter notes, pango markup, video, image backgrounds
  • Home page
  • Abandoned since at least 2019

Reveal.js

  • HTML, Javascript
  • PDF export, Markdown, LaTeX support, syntax-highlighting, nested slides, speaker notes
  • Source code, demo

S5

  • HTML, CSS
  • incremental, bookmarks, keyboard controls
  • can be transformed from ReStructuredText (RST) with rst2s5 with python-docutils
  • Home page, demo

sent

  • X11 only
  • plain text, black on white, image support, and that's it
  • from the suckless.org elitists
  • Home page

Sozi

  • Entire presentation is one poster, zooming and jumping around
  • SVG + Javascript
  • Home page, demo

Other options

Another option I have seriously considered is just generate a series of images with good resolution, hopefully matching the resolution (or at least aspect ratio) of the output device. Then you flip through a series of images one by one. In that case, any of those image viewers (not an exhaustive list) would work:

Update: it turns out I already wrote a somewhat similar thing when I did a recent presentation. If you're into rants, you might enjoy the README file accompanying the Kubecon rant presentation. TL;DR: "makes me want to scream" and "yet another unsolved problem space, sigh" (refering to "display images full-screen" specifically).

...
@blog September 24, 2020 - 21:08 • 28 days ago
New Release: Tor Browser 10.5a1
New Release: Tor Browser 10.5a1 sysrqb September 24, 2020

Tor Browser 10.5a1 is now available from the Tor Browser Alpha 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.

Tor Browser 10.5a1 ships with Firefox 78.3.0esr, updates NoScript to 11.0.44, and Tor to 0.4.4.5.

Note: Tor Browser 10.5 does not support CentOS 6.

Note: Now Javascript on the Safest security level is governed by NoScript again. It was set as false when on Safest in 9.5a9. The javascript.enabled preference was reset to true for everyone using Safest and you must re-set it as false if that is your preference.

Note: After investigating the error seen by Windows users while playing videos on Youtube, a user helped us identify the cause. Until this is fixed in an upcoming release, a workaround is setting media.rdd-opus.enabled as false in about:config.

The full changelog since Tor Browser 10.0a7 is:

  • Windows + OS X + Linux
    • Update Firefox to 78.3.0esr
    • Update Tor to 0.4.4.5
    • Update Tor Launcher to 0.2.25
      • Translations update
    • Update NoScript to 11.0.44
      • Bug 40093: Youtube videos on safer produce an error
    • Translations update
  • Linux
    • Bug 40089: Remove CentOS 6 support for Tor Browser 10.5
  • Build System
    • Linux
      • Bug 26238: Move to Debian Jessie for our Linux builds
      • Bug 40041: Remove CentOS 6 support for 10.5 series
      • Bug 40103: Add i386 pkg-config path for linux-i686
...
@blog September 22, 2020 - 20:40 • 30 days ago
New Release: Tor Browser 10
New Release: Tor Browser 10 sysrqb September 22, 2020

Update 1700 UTC 2020-09-24: After investigating the error seen by Windows users while playing videos on Youtube, a user helped us identify the cause. Until this is fixed in an upcoming release, a workaround is setting media.rdd-opus.enabled as false in about:config.

The new shiny Tor Browser 10 for Desktop is now available from the Tor Browser download page and also from our distribution directory!

Android Tor Browser 10 is under active development and we are supporting the current 9.5 series for Android until the new one is ready. We are informed by Mozilla of any issues they learn about affecting the 9.5 series. We expect to release the new Tor Browser for Android based on Fenix in the following weeks.

Tor Browser 10 ships with Firefox 78.3.0esr, updates NoScript to 11.0.44, and Tor to 0.4.4.5. This release includes important security updates to Firefox.

This new Tor Browser release is focused on stablizing Tor Browser based on a new extended support release of Mozilla Firefox. Tor Browser 10.0 is the first stable release of the 10.0 series based on Firefox 78esr.

Note: Tor Browser 10.0 is the final Tor Browser series supporting CentOS 6. Beginning with the 10.5 series, CentOS 6 is not supported.

Note: In this release JavaScript is controlled by NoScript again. JavaScript was completely disabled on the Safest security level beginning in Tor Browser 9.0.7. The Firefox preference javascript.enabled is reset to true in this release. You must re-set it as false if that is your preference.

Give Feedback

If you find a bug or have a suggestion for how we could improve this release, please let us know. Thanks to all of the teams across Tor, and the many volunteers, who contributed to this release.

Full Changelog

The full changelog since Tor Browser 9.5.4 is:

  • Windows + OS X + Linux
    • Update Firefox to 78.3.0esr
    • Update Tor to 0.4.4.5
    • Update Tor Launcher to 0.2.25
      • Bug 32174: Replace XUL with
      • Bug 33890: Rename XUL files to XHTML
      • Bug 33862: Fix usages of createTransport API
      • Bug 33906: Fix Tor-Launcher issues for Firefox 75
      • Bug 33998: Use CSS grid instead of XUL grid
      • Bug 34164: Tor Launcher deadlocks during startup (Firefox 77)
      • Bug 34206: Tor Launcher button labels are missing (Firefox 76)
      • Bug 40002: After rebasing to 80.0b2 moat is broken
      • Translations update
    • Update NoScript to 11.0.44
      • Bug 40093: Youtube videos on safer produce an error
    • Translations update
    • Bug 10394: Let Tor Browser update HTTPS Everywhere
    • Bug 11154: Disable TLS 1.0 (and 1.1) by default
    • Bug 16931: Sanitize the add-on blocklist update URL
    • Bug 17374: Disable 1024-DH Encryption by default
    • Bug 21601: Remove unused media.webaudio.enabled pref
    • Bug 30682: Disable Intermediate CA Preloading
    • Bug 30812: Exempt about: pages from Resist Fingerprinting
    • Bug 31918+33533+40024+40037: Rebase Tor Browser esr68 patches for ESR 78
    • Bug 32612: Update MAR_CHANNEL_ID for the alpha
    • Bug 32886: Separate treatment of @media interaction features for desktop and android
    • Bug 33534: Review FF release notes from FF69 to latest (FF78)
    • Bug 33697: Use old search config based on list.json
    • Bug 33721: PDF Viewer is not working in the safest security level
    • Bug 33734: Set MOZ_NORMANDY to False
    • Bug 33737: Fix aboutDialog.js error for Firefox nightlies
    • Bug 33848: Disable Enhanced Tracking Protection
    • Bug 33851: Patch out Parental Controls detection and logging
    • Bug 33852: Clean up about:logins to not mention Sync
    • Bug 33856: Set browser.privatebrowsing.forceMediaMemoryCache to True
    • Bug 33862: Fix usages of createTransport API
    • Bug 33867: Disable password manager and password generation
    • Bug 33890: Rename XUL files to XHTML
    • Bug 33892: Add brandProductName to brand.dtd and brand.properties
    • Bug 33962: Uplift patch for bug 5741 (dns leak protection)
    • Bug 34125: API change in protocolProxyService.registerChannelFilter
    • Bug 40001: Generate tor-browser-brand.ftl when importing translations
    • Bug 40002: Remove about:pioneer
    • Bug 40002: Fix generateNSGetFactory being moved to ComponentUtils
    • Bug 40003: Adapt code for L10nRegistry API changes
    • Bug 40005: Initialize the identity UI before setting up the circuit display
    • Bug 40006: Fix new identity for 81
    • Bug 40007: Move SecurityPrefs initialization to the StartupObserver component
    • Bug 40008: Style fixes for 78
    • Bug 40017: Audit Firefox 68-78 diff for proxy issues
    • Bug 40022: Update new icons in Tor Browser branding
    • Bug 40025: Revert add-on permissions due to Mozilla's 1560059
    • Bug 40036: Remove product version/update channel from #13379 patch
    • Bug 40038: Review RemoteSettings for ESR 78
    • Bug 40048: Disable various ESR78 features via prefs
    • Bug 40059: Verify our external helper patch is still working
    • Bug 40066: Update existing prefs for ESR 78
    • Bug 40066: Remove default bridge 37.218.240.34
    • Bug 40073: Disable remote Public Suffix List fetching
    • Bug 40073: Repack omni.ja to include builtin HTTPS Everywhere
    • Bug 40078: Backport patches for bug 1651680 for now
    • Bug 40082: Let JavaScript on safest setting handled by NoScript again
    • Bug 40088: Moat "Submit" button does not work
    • Bug 40090: Disable v3 add-on blocklist for now
    • Bug 40091: Load HTTPS Everywhere as a builtin addon
    • Bug 40102: Fix UI bugs in Tor Browser 10.0 alpha
    • Bug 40106: Cannot install addons in full screen mode
    • Bug 40109: Playing video breaks after reloading pages
    • Bug 40119: Enable v3 extension blocklisting again
  • Windows
    • Bug 33855: Don't use site's icon as window icon in Windows in private mode
    • Bug 40061: Omit the Windows default browser agent from the build
  • OS X
    • Bug 32252: Tor Browser does not display correctly in VMWare Fusion on macOS (mojave)
  • Build System
    • Windows + OS X + Linux
      • Bump Go to 1.14.7
      • Bug 31845: Bump GCC version to 9.3.0
      • Bug 34011: Bump clang to 9.0.1
      • Bug 34014: Enable sqlite3 support in Python
      • Bug 34390: Don't copy DBM libraries anymore
      • Bug 34391: Remove unused --enable-signmar option
      • Bug 40004: Adapt Rust project for Firefox 78 ESR
      • Bug 40005: Adapt Node project for Firefox 78 ESR
      • Bug 40006: Adapt cbindgen for Firefox 78 ESR
      • Bug 40037: Move projects over to clang-source
      • Bug 40026: Fix full .mar creation for esr78
      • Bug 40027: Fix incremental .mar creation for esr78
      • Bug 40028: Do not reference unset env variables
      • Bug 40031: Add licenses for kcp-go and smux.
      • Bug 40045: Fix complete .mar file creation for dmg2mar
      • Bug 40065: Bump debootstrap-image ubuntu_version to 20.04.1
      • Bug 40087: Deterministically add HTTPS Everywhere into omni.ja
    • Windows
      • Bug 34230: Update Windows toolchain for Firefox 78 ESR
      • Bug 40015: Use only 64bit fxc2
      • Bug 40017: Enable stripping again on Windows
      • Bug 40052: Bump NSIS to 3.06.1
      • Bug 40061: Omit the Windows default browser agent from the build
      • Bug 40071: Be explicit about no SEH with mingw-w64 on 32bit systems
      • Bug 40077: Don't pass --no-insert-timestamp when building Firefox
      • Bug 40090: NSIS 3.06.1 based builds are not reproducible anymore
    • OS X
      • Bug 34229: Update macOS toolchain for Firefox 78 ESR
      • Bug 40003: Update cctools version for Firefox 78 ESR
      • Bug 40018: Add libtapi project for cctools
      • Bug 40019: Ship our own runtime library for macOS
    • Linux
      • Bug 34359: Adapt abicheck.cc to deal with newer GCC version
      • Bug 34386: Fix up clang compilation on Linux
      • Bug 40053: Also create the langpacks tarball for non-release builds
...
@blog September 22, 2020 - 10:23 • 1 months ago
New Release: Tails 4.11
New Release: Tails 4.11 Tails September 22, 2020

This release fixes many security vulnerabilities. You should upgrade as soon as possible.

New features

  • We added a new feature of the Persistent Storage to save the settings from the Welcome Screen: language, keyboard, and additional settings.
    To restore your settings when starting Tails, unlock your Persistent Storage in the Welcome Screen.

Changes and updates

  • Update Tor Browser to 10.0.
  • Update Thunderbird to 68.12.
  • Update Linux to 5.7.17. This should improve the support for newer hardware (graphics, Wi-Fi, etc.).
  • Configure KeePassXC to use the new default location Passwords.kdbx. (#17286)
  • Update python3-trezor to 0.11.6 to add compatibility with the new Trezor Model T.

Fixed problems

  • Disable the feature to Turn on Wi-Fi Hotspot in the Wi-Fi settings because it doesn't work in Tails. (#17887)

For more details, read our changelog.

Known issues

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

Get Tails 4.11

To upgrade your Tails USB stick and keep your persistent storage

  • Automatic upgrades are available from Tails 4.2 or later to 4.11.
  • If you cannot do an automatic upgrade or if Tails fails to start after an automatic upgrade, please try to do a manual upgrade.

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.11 directly:

What's coming up?

Tails 4.12 is scheduled for October 20.
Have a look at our roadmap to see where we are heading to.
We need your help and there are many ways to contribute to Tails (donating is only one of them). Come talk to us!

Support and feedback

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

...
@anarcat September 21, 2020 - 18:44 • 1 months ago
PSA: Mailman used to harrass people

It seems that Mailman instances are being abused to harrass people with subscribe spam. If some random people complain to you that they "never wanted to subscribe to your mailing list", you may be a victim to that attack, even if you run the latest Mailman 2.

TL;DR: IKR! HOW DO I FIX THIS!?

Make sure you have SUBSCRIBE_FORM_SECRET set in your mailman configuration:

SECRET=$(tr -dc 'A-Za-z0-9' < /dev/urandom | head -c 30)'
echo "SUBSCRIBE_FORM_SECRET = '$SECRET'" >> /etc/mailman/mm.cfg

This will add a magic token to all forms in the Mailman web forms that will force the attacker to at least get a token before asking for registration. There are, of course, other ways of performing the attack then, but it's more expensive than a single request for the attacker and keeps most of the junk out.

Other solutions

I originally deployed a different fix, using referrer checks and an IP block list:

RewriteMap hosts-deny  txt:/etc/apache2/blocklist.txt
RewriteCond ${hosts-deny:%{REMOTE_ADDR}|NOT-FOUND} !=NOT-FOUND [OR]
RewriteCond ${hosts-deny:%{REMOTE_HOST}|NOT-FOUND} !=NOT-FOUND [OR]
RewriteCond %{HTTP_REFERER} !^https://lists.torproject.org/$ [NC]
RewriteRule ^/cgi-bin/mailman/subscribe/ - [F]
# see also https://www.w3.org/TR/referrer-policy/#referrer-policy-origin
Header always set Referrer-Policy "origin"

I kept those restrictions in place because it keeps the spammers from even hitting the Mailman CGI, which is useful to preserve our server resources. But if "they" escalate with smarter crawlers, the block list will still be useful.

You can use this query to extract the top 10 IP addresses used for subscription attempts:

awk '{ print $NF }' /var/log/mailman/subscribe | sort | uniq -c | sort -n | tail -10  | awk '{ print $2 " " $1 }'

Note that this might include email-based registration, but in our logs those are extremely rare: only two in three weeks, out of over 73,000 requests. I also use this to keep an eye on the logs:

tail -f  /var/log/mailman/subscribe /var/log/apache2/lists.torproject.org-access.log | grep -v 'GET /pipermail/'

The server-side mitigations might also be useful if you happen to run an extremely old version of Mailman, that is pre-2.1.18, but it's now over 6 years old and part of every supported Debian release out there (all the way back to Debian 8 jessie).

Why does that attack work?

Because Mailman 2 doesn't have CSRF tokens in its forms by default, anyone can send a POST request to /mailman/subscribe/LISTNAME to have Mailman send an email to the user. In the old "Internet is for nice people" universe, that wasn't a problem: all it does is ask the victim if they want to subscribe to LISTNAME. Innocuous, right?

But in the brave, new, post-Eternal-September, "Internet is for stupid" universe, some assholes think it's a good idea to make a form that collects hundreds of mailing list URLs and spam them through an iframe. To see what that looks like, you can look at the rendered source code behind samedyfreeday.co.uk (not linking to avoid promoting it). That site does what is basically a distributed cross-site scripting attack against Mailman servers.

Obviously, CSRF protection should be enabled by default in Mailman, but there you go. Hopefully this will help some folks...

(The latest Mailman 3 release doesn't suffer from such idiotic defaults and ships with proper CSRF protection out of the box.)

...
@blog September 18, 2020 - 18:11 • 1 months ago
Censored continent: understanding the use of tools during information controls in Africa: Nigeria, Cameroon, Uganda, and Zimbabwe as case studies.
Censored continent: understanding the use of tools during information controls in Africa: Nigeria, Cameroon, Uganda, and Zimbabwe as case studies. Antonela September 18, 2020

Between 2019 and 2020, The Tor Project has had the opportunity to serve as the host organization of OTF Information Controls Fellow, Babatunde Okunoye. Today, we are sharing here the publication of his research report, titled "Censored continent: understanding the use of tools during Information controls in Africa: Nigeria, Cameroon, Uganda, and Zimbabwe as case studies."

As part of his fellowship, Babatunde examined the use of Internet censorship circumvention tools in Cameroon, Nigeria, Uganda, and Zimbabwe, four countries in Africa with varying degrees of Internet censorship, including Internet bandwidth throttling, social media app restrictions, and website blocks. Interviews were done with 33 people, including students, civil society members, people in business, and teachers, revealing how communities mobilized to defeat censorship.

Important findings include: 

  • Civil society played an important role in mobilizing people to use circumvention tools.
  • Some of the most important VPN adoption reasons were community recommendations, cost of use, and ease of use.
  • Messaging apps like Signal and Telegram, which were unknown to government censors and were not blocked, served as alternative messaging channels when more popular apps like Facebook and WhatsApp were blocked.
  • People used innovative means of sharing VPNs, such as through USBs and Bluetooth, when downloads were no longer possible from official sources such as websites of VPN makers and smartphone App stores.

Full-length report:
https://research.torproject.org/techreports/icfp-censored-continent-202…

Media impact:
https://www.cfr.org/blog/technologies-freedom-enabling-democracy-africa

His research in the field helped us to inform the user research work on improving Tor Browser as an essential circumvention tool.

If you have questions or comments regarding this study, you can reach out to Babatunde directly: to.csgroups[at]gmail.com.

...
@blog September 17, 2020 - 23:04 • 1 months ago
Tor’s Bug Smash Fund, Year 2: $106,709 Raised!
Tor’s Bug Smash Fund, Year 2: $106,709 Raised! Al Smith September 17, 2020

Let’s start this post with a rousing THANK YOU to the Tor community!

This August, we asked you to help us fundraise for our second annual Bug Smash Fund campaign. This fund is designed to grow a healthy reserve earmarked for maintenance work, finding bugs, and smashing them—all tasks necessary to keep Tor Browser, the Tor network, and the many tools that rely on Tor strong, safe, and running smoothly.

In 2019, we raised $86,081, half of which we raised in-person at DEFCON.

In 2020, despite the challenges of COVID-19 and event cancellations, you helped us to raise $106,709!

We could not have predicted how successful this campaign would be. We’re living in a world with new limitations and challenges, and we know many of you are impacted by the financial impact of the pandemic and its ripple effects, as are we. Despite that, contributions came from all over the world, in all different forms: online, through the mail, and in a multitude of different cryptocurrencies, with individual and organizational campaigns supporting the Bug Smash Fund in a variety of efforts. We are humbled by your generosity and continued encouragement around the importance of this fund. Thank you!

Additionally, 60% of all donations came in the form of cryptocurrency. Thank you to everyone from the cryptocurrency community for supporting Tor—you’ve made a huge impact on our ability to find and fix bugs.

What’s next: as we did in 2019, we’ll tag bugs in GitLab with BugSmashFund so you can follow along with how we’re allocating the fund. We’ll also make periodic updates here on the blog and through the newsletter about our progress with these BugSmashFund tickets. 

Thank you to everybody who made a contribution to the Bug Smash Fund. 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.

P.S.: If you made a gift of $74 in order to receive a surprise t-shirt pack during this campaign, your gift is in the mail and on its way to you now.

...
@blog September 16, 2020 - 22:19 • 1 months ago
New Release: Tor Browser 10.0a7
New Release: Tor Browser 10.0a7 sysrqb September 16, 2020

Tor Browser 10.0a7 is now available from the Tor Browser Alpha 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.

We are happy to announce the third alpha for desktop users based on Firefox 78 ESR. The Android version is under active development and will be available in the coming weeks.

Tor Browser 10.0a7 updates NoScript to 11.0.43. The Windows installer now uses NSIS 3.06.1. Please report bugs with steps to reproduce, either here or on Gitlab, or essentially with any other means that would reach us. We are in particular interested in potential proxy bypasses which our proxy audit missed.

Note: We encountered updater issues for all alpha users that have been auto-updating the alpha series for months. We changed the accepted MAR channel ID to torbrowser-torproject-alpha as we are on an alpha channel. The assumption was that enough time passed since we changed it last time to torbrowser-torproject-release,torbrowser-torproject-alpha but it turns out that change did not get applied. Workaround: change the torbrowser-torproject-release in your update-settings.ini (in the Browser's code directory, which depends on you operating system) file to torbrowser-torproject-alpha and the update should get applied successfully. Alternatively, downloading a fresh alpha copy of Tor Browser works as well. Sorry for the inconvenience.

The full changelog since Tor Browser 10.0a6 is:

  • Windows + OS X + Linux
    • Update Tor Launcher to 0.2.24
    • Translations update
    • Update NoScript to 11.0.43
    • Bug 10394: Let Tor Browser update HTTPS Everywhere
    • Bug 32017: Use ExtensionStorageIDB again
    • Bug 40006: Fix new identity for 81
    • Bug 40007: Move SecurityPrefs initialization to the StartupObserver component
    • Bug 40008: Style fixes for 78
    • Bug 40066: Remove default bridge 37.218.240.34
    • Bug 40073: Repack omni.ja to include builtin HTTPS Everywhere
    • Bug 40091: Load HTTPS Everywhere as a builtin addon
    • Bug 40102: Fix UI bugs in Tor Browser 10.0 alpha
    • Bug 40109: Playing video breaks after reloading pages
    • Bug 40119: Enable v3 extension blocklisting again
    • Build System
      • Windows + OS X + Linux
        • Bump Go to 1.14.7
        • Bug 40031: Add licenses for kcp-go and smux.
        • Bug 40045: Fix complete .mar file creation for dmg2mar
        • Bug 40065: Bump debootstrap-image ubuntu_version to 20.04.1
        • Bug 40087: Deterministically add HTTPS Everywhere into omni.ja
      • Windows
        • Bug 40052: Bump NSIS to 3.06.1
        • Bug 40071: Be explicit about no SEH with mingw-w64 on 32bit systems
        • Bug 40077: Don't pass --no-insert-timestamp when building Firefox
        • Bug 40090: NSIS 3.06.1 based builds are not reproducible anymore
...
@blog September 16, 2020 - 13:23 • 1 months ago
Updates on Tor Project’s Board
Updates on Tor Project’s Board isabela September 16, 2020

We would like to share some updates regarding the Tor Project’s Board. Last year Megan Price stepped down as she took a second maternity leave. And in the Spring of this year, Shari Steele asked to step down from the Board for personal reasons. Both Megan and Shari provided great contributions for the Board that Tor will always be thankful for. We are grateful to have them as supporters and friends of Tor.

But to move forward we decided to invite two new members. We are happy to say both have accepted our invitation and joined the Board.

Rabbi Rob, the founder and CEO of Team Cymru and who has been on Tor’s Board before, from 2011 to 2016. Rabbi Rob is part of our core contributors community and is a great supporter of Tor. Rabbi Rob says that, "The Internet remains a top target for tyrants. Tor remains the best solution for those who seek online freedom and an escape from tyranny. It is a great honor to be a part of this important mission."

And Chelsea Komlo, cryptography and privacy researcher and engineer, is also part of our core contributors community and serves as a member of the Tor Research Safety Board. She has experience working on technical teams around the world on both enterprise and open-source projects, a role we are looking forward to having on our Board.

"Tor is in the unique position to provide critical internet privacy infrastructure for millions of people around the world. I am honored to be able to support Tor in this way", Chelsea Komlo.

The other seven members of the Tor Project’s Board are: Bruce Schneier, Cindy Cohn, Gabriella Coleman, Julius Mittenzwei, Matt Blaze, Nighat Dad and Ramy Raoof.

Biographies of Incoming Board Members

Chelsea Komlo is a cryptography and privacy researcher and engineer, and has been a technical contributor to Tor since 2016. She most recently was a collaborator on "Walking Onions," a design that enables the Tor network to meaningfully scale while maintaining low overhead for users. Chelsea also serves as a member of the Tor Research Safety Board.

Chelsea has nearly a decade of engineering experience and is a lead author on several cryptographic designs ranging from multi-party signature schemes to post-quantum primitives with applications to secure messaging. She has experience working on technical teams around the world on both enterprise and open-source projects. She currently is completing her Ph.D at the University of Waterloo in the Cryptography, Security, and Privacy Lab, and is a Principal Technical Advisor and Researcher for the Zcash Foundation.

Rabbi Rob Thomas is the founder and CEO of Team Cymru, and a member of the early generation of network defenders. He has worked at IBM, Sun, and Cisco, among others. During his career, Rabbi Rob has been a Unix kernel developer, ISP backbone engineer, security architect, and an adjunct professor. He was also the first individual member of FIRST (the Forum of Incident Response and Security Teams).

Rabbi Rob took his first C programming class at age 12, and has been addicted to technology ever since. He and Team Cymru are long-time fans and supporters of the Tor Project. They provide infrastructure and services to the project, with a particular interest in enabling dissidents around the world to operate without being tracked or hampered by oppressive regimes. Rabbi Rob and Team Cymru are rabidly devoted to delivering community services that make the Internet and world a safer place. They are proud to support the great work of the Tor Project and the freedoms its technology enables.

...
@blog September 15, 2020 - 13:26 • 1 months ago
New Release: Tor 0.4.4.5
New Release: Tor 0.4.4.5 nickm September 15, 2020

After months of work, we have a new stable release series!
If you build Tor from source, you can download the source
code for 0.4.4.5 on the
download page.
Packages should be available within the next several weeks, with a new Tor Browser by some time next week.

Tor 0.4.4.5 is the first stable release in the 0.4.4.x series. This series improves our guard selection algorithms, adds v3 onion balance support, improves the amount of code that can be disabled when running without relay support, and includes numerous small bugfixes and enhancements. It also lays the ground for some IPv6 features that we'll be developing more in the next (0.4.5) series.

Per our support policy, we support each stable release series for nine months after its first stable release, or three months after the first stable release of the next series: whichever is longer. This means that 0.4.4.x will be supported until around June 2021--or later, if 0.4.5.x is later than anticipated.

Note also that support for 0.4.2.x has just ended; support for 0.4.3 will continue until Feb 15, 2021. We still plan to continue supporting 0.3.5.x, our long-term stable series, until Feb 2022.

Below are the changes since 0.4.3.6-rc. For a complete list of changes since 0.4.4.4-rc, see the ChangeLog file.

Changes in version 0.4.4.5 - 2020-09-15

  • Major features (Proposal 310, performance + security):
    • Implements Proposal 310, "Bandaid on guard selection". Proposal 310 solves load-balancing issues with older versions of the guard selection algorithm, and improves its security. Under this new algorithm, a newly selected guard never becomes Primary unless all previously sampled guards are unreachable. Implements recommendation from 32088. (Proposal 310 is linked to the CLAPS project researching optimal client location-aware path selections. This project is a collaboration between the UCLouvain Crypto Group, the U.S. Naval Research Laboratory, and Princeton University.)
  • Major features (fallback directory list):
    • Replace the 148 fallback directories originally included in Tor 0.4.1.4-rc (of which around 105 are still functional) with a list of 144 fallbacks generated in July 2020. Closes ticket 40061.

 

  • Major features (IPv6, relay):
    • Consider IPv6-only EXTEND2 cells valid on relays. Log a protocol warning if the IPv4 or IPv6 address is an internal address, and internal addresses are not allowed. But continue to use the other address, if it is valid. Closes ticket 33817.
    • If a relay can extend over IPv4 and IPv6, and both addresses are provided, it chooses between them uniformly at random. Closes ticket 33817.
    • Re-use existing IPv6 connections for circuit extends. Closes ticket 33817.
    • Relays may extend circuits over IPv6, if the relay has an IPv6 ORPort, and the client supplies the other relay's IPv6 ORPort in the EXTEND2 cell. IPv6 extends will be used by the relay IPv6 ORPort self-tests in 33222. Closes ticket 33817.
  • Major features (v3 onion services):
    • Allow v3 onion services to act as OnionBalance backend instances, by using the HiddenServiceOnionBalanceInstance torrc option. Closes ticket 32709.
  • Major bugfixes (NSS):
    • When running with NSS enabled, make sure that NSS knows to expect nonblocking sockets. Previously, we set our TCP sockets as nonblocking, but did not tell NSS, which in turn could lead to unexpected blocking behavior. Fixes bug 40035; bugfix on 0.3.5.1-alpha.
  • Major bugfixes (onion services, DoS):
    • Correct handling of parameters for the onion service DoS defense. Previously, the consensus parameters for the onion service DoS defenses were overwriting the parameters set by the service operator using HiddenServiceEnableIntroDoSDefense. Fixes bug 40109; bugfix on 0.4.2.1-alpha.
  • Major bugfixes (stats, onion services):
    • Fix a bug where we were undercounting the Tor network's total onion service traffic, by ignoring any traffic originating from clients. Now we count traffic from both clients and services. Fixes bug 40117; bugfix on 0.2.6.2-alpha.
  • Minor features (security):
    • Channels using obsolete versions of the Tor link protocol are no longer allowed to circumvent address-canonicity checks. (This is only a minor issue, since such channels have no way to set ed25519 keys, and therefore should always be rejected for circuits that specify ed25519 identities.) Closes ticket 40081.
  • Minor features (bootstrap reporting):
    • Report more detailed reasons for bootstrap failure when the failure happens due to a TLS error. Previously we would just call these errors "MISC" when they happened during read, and "DONE" when they happened during any other TLS operation. Closes ticket 32622.
  • Minor features (client-only compilation):
    • Disable more code related to the ext_orport protocol when compiling without support for relay mode. Closes ticket 33368.
    • Disable more of our self-testing code when support for relay mode is disabled. Closes ticket 33370.
    • Most server-side DNS code is now disabled when building without support for relay mode. Closes ticket 33366.
  • Minor features (code safety):
    • Check for failures of tor_inet_ntop() and tor_inet_ntoa() functions in DNS and IP address processing code, and adjust codepaths to make them less likely to crash entire Tor instances. Resolves issue 33788.
  • Minor features (continuous integration):
    • Run unit-test and integration test (Stem, Chutney) jobs with ALL_BUGS_ARE_FATAL macro being enabled on Travis and Appveyor. Resolves ticket 32143.
  • Minor features (control port):
    • If a ClientName was specified in ONION_CLIENT_AUTH_ADD for an onion service, display it when we use ONION_CLIENT_AUTH_VIEW. Closes ticket 40089. Patch by Neel Chauhan.
    • Return a descriptive error message from the 'GETINFO status/fresh- relay-descs' command on the control port. Previously, we returned a generic error of "Error generating descriptor". Closes ticket 32873. Patch by Neel Chauhan.
  • Minor features (defense in depth):
    • Wipe more data from connection address fields before returning them to the memory heap. Closes ticket 6198.
  • Minor features (denial-of-service memory limiter):
    • Allow the user to configure even lower values for the MaxMemInQueues parameter. Relays now enforce a minimum of 64 MB, when previously the minimum was 256 MB. On clients, there is no minimum. Relays and clients will both warn if the value is set so low that Tor is likely to stop working. Closes ticket 24308.
  • Minor features (developer tooling):
    • Add a script to help check the alphabetical ordering of option names in the manual page. Closes ticket 33339.
    • Refrain from listing all .a files that are generated by the Tor build in .gitignore. Add a single wildcard *.a entry that covers all of them for present and future. Closes ticket 33642.
    • Add a script ("git-install-tools.sh") to install git hooks and helper scripts. Closes ticket 33451.
  • Minor features (directory authority):
    • Authorities now recommend the protocol versions that are supported by Tor 0.3.5 and later. (Earlier versions of Tor have been deprecated since January of this year.) This recommendation will cause older clients and relays to give a warning on startup, or when they download a consensus directory. Closes ticket 32696.
  • Minor features (directory authority, shared random):
    • Refactor more authority-only parts of the shared-random scheduling code to reside in the dirauth module, and to be disabled when compiling with --disable-module-dirauth. Closes ticket 33436.
  • Minor features (directory):
    • Remember the number of bytes we have downloaded for each directory purpose while bootstrapping, and while fully bootstrapped. Log this information as part of the heartbeat message. Closes ticket 32720.
  • Minor features (entry guards):
    • Reinstate support for GUARD NEW/UP/DOWN control port events. Closes ticket 40001.
  • Minor features (IPv6 support):
    • Adds IPv6 support to tor_addr_is_valid(). Adds tests for the above changes and tor_addr_is_null(). Closes ticket 33679. Patch by MrSquanchee.
    • Allow clients and relays to send dual-stack and IPv6-only EXTEND2 cells. Parse dual-stack and IPv6-only EXTEND2 cells on relays. Closes ticket 33901.
  • Minor features (linux seccomp2 sandbox, portability):
    • Allow Tor to build on platforms where it doesn't know how to report which syscall caused the linux seccomp2 sandbox to fail. This change should make the sandbox code more portable to less common Linux architectures. Closes ticket 34382.
    • Permit the unlinkat() syscall, which some Libc implementations use to implement unlink(). Closes ticket 33346.
  • Minor features (logging):
    • When trying to find our own address, add debug-level logging to report the sources of candidate addresses. Closes ticket 32888.
  • Minor features (onion service client, SOCKS5):
    • Add 3 new SocksPort ExtendedErrors (F2, F3, F7) that reports back new type of onion service connection failures. The semantics of these error codes are documented in proposal 309. Closes ticket 32542.
  • Minor features (onion service v3):
    • If a service cannot upload its descriptor(s), log why at INFO level. Closes ticket 33400; bugfix on 0.3.2.1-alpha.
  • Minor features (python scripts):
    • Stop assuming that /usr/bin/python exists. Instead of using a hardcoded path in scripts that still use Python 2, use /usr/bin/env, similarly to the scripts that use Python 3. Fixes bug 33192; bugfix on 0.4.2.
  • Minor features (testing, architecture):
    • Our test scripts now double-check that subsystem initialization order is consistent with the inter-module dependencies established by our .may_include files. Implements ticket 31634.
    • Initialize all subsystems at the beginning of our unit test harness, to avoid crashes due to uninitialized subsystems. Follow- up from ticket 33316.
    • Our "make check" target now runs the unit tests in 8 parallel chunks. Doing this speeds up hardened CI builds by more than a factor of two. Closes ticket 40098.
  • Minor features (v3 onion services):
    • Add v3 onion service status to the dumpstats() call which is triggered by a SIGUSR1 signal. Previously, we only did v2 onion services. Closes ticket 24844. Patch by Neel Chauhan.
  • Minor features (windows):
    • Add support for console control signals like Ctrl+C in Windows. Closes ticket 34211. Patch from Damon Harris (TheDcoder).
  • Minor bugfixes (control port, onion service):
    • Consistently use 'address' in "Invalid v3 address" response to ONION_CLIENT_AUTH commands. Previously, we would sometimes say 'addr'. Fixes bug 40005; bugfix on 0.4.3.1-alpha.
  • Minor bugfixes (correctness, buffers):
    • Fix a correctness bug that could cause an assertion failure if we ever tried using the buf_move_all() function with an empty input buffer. As far as we know, no released versions of Tor do this. Fixes bug 40076; bugfix on 0.3.3.1-alpha.
  • Minor bugfixes (directory authorities):
    • Directory authorities now reject votes that arrive too late. In particular, once an authority has started fetching missing votes, it no longer accepts new votes posted by other authorities. This change helps prevent a consensus split, where only some authorities have the late vote. Fixes bug 4631; bugfix on 0.2.0.5-alpha.
  • Minor bugfixes (git scripts):
    • Stop executing the checked-out pre-commit hook from the pre-push hook. Instead, execute the copy in the user's git directory. Fixes bug 33284; bugfix on 0.4.1.1-alpha.
  • Minor bugfixes (initialization):
    • Initialize the subsystems in our code in an order more closely corresponding to their dependencies, so that every system is initialized before the ones that (theoretically) depend on it. Fixes bug 33316; bugfix on 0.4.0.1-alpha.
  • Minor bugfixes (IPv4, relay):
    • Check for invalid zero IPv4 addresses and ports when sending and receiving extend cells. Fixes bug 33900; bugfix on 0.2.4.8-alpha.
  • Minor bugfixes (IPv6, relay):
    • Consider IPv6 addresses when checking if a connection is canonical. In 17604, relays assumed that a remote relay could consider an IPv6 connection canonical, but did not set the canonical flag on their side of the connection. Fixes bug 33899; bugfix on 0.3.1.1-alpha.
    • Log IPv6 addresses on connections where this relay is the responder. Previously, responding relays would replace the remote IPv6 address with the IPv4 address from the consensus. Fixes bug 33899; bugfix on 0.3.1.1-alpha.
  • Minor bugfixes (linux seccomp2 sandbox):
    • Fix a regression on sandboxing rules for the openat() syscall. The fix for bug 25440 fixed the problem on systems with glibc >= 2.27 but broke with versions of glibc. We now choose a rule based on the glibc version. Patch from Daniel Pinto. Fixes bug 27315; bugfix on 0.3.5.11.
    • Makes the seccomp sandbox allow the correct syscall for opendir according to the running glibc version. This fixes crashes when reloading torrc with sandbox enabled when running on glibc 2.15 to 2.21 and 2.26. Patch from Daniel Pinto. Fixes bug 40020; bugfix on 0.3.5.11.
  • Minor bugfixes (logging, testing):
    • Make all of tor's assertion macros support the ALL_BUGS_ARE_FATAL and DISABLE_ASSERTS_IN_UNIT_TESTS debugging modes. (IF_BUG_ONCE() used to log a non-fatal warning, regardless of the debugging mode.) Fixes bug 33917; bugfix on 0.2.9.1-alpha.
    • Remove surprising empty line in the INFO-level log about circuit build timeout. Fixes bug 33531; bugfix on 0.3.3.1-alpha.
  • Minor bugfixes (mainloop):
    • Better guard against growing a buffer past its maximum 2GB in size. Fixes bug 33131; bugfix on 0.3.0.4-rc.
  • Minor bugfixes (onion service v3 client):
    • Remove a BUG() warning that could occur naturally. Fixes bug 34087; bugfix on 0.3.2.1-alpha.
  • Minor bugfixes (onion service, logging):
    • Fix a typo in a log message PublishHidServDescriptors is set to 0. Fixes bug 33779; bugfix on 0.3.2.1-alpha.
  • Minor bugfixes (onion services v3):
    • Avoid a non-fatal assertion failure in certain edge-cases when opening an intro circuit as a client. Fixes bug 34084; bugfix on 0.3.2.1-alpha.
  • Minor bugfixes (protocol versions):
    • Sort tor's supported protocol version lists, as recommended by the tor directory specification. Fixes bug 33285; bugfix on 0.4.0.1-alpha.
  • Minor bugfixes (rate limiting, bridges, pluggable transports):
    • On a bridge, treat all connections from an ExtORPort as remote by default for the purposes of rate-limiting. Previously, bridges would treat the connection as local unless they explicitly received a "USERADDR" command. ExtORPort connections still count as local if there is a USERADDR command with an explicit local address. Fixes bug 33747; bugfix on 0.2.5.1-alpha.
  • Minor bugfixes (refactoring):
    • Lift circuit_build_times_disabled() out of the circuit_expire_building() loop, to save CPU time when there are many circuits open. Fixes bug 33977; bugfix on 0.3.5.9.
  • Minor bugfixes (relay, self-testing):
    • When starting up as a relay, if we haven't been able to verify that we're reachable, only launch reachability tests at most once a minute. Previously, we had been launching tests up to once a second, which was needlessly noisy. Fixes bug 40083; bugfix on 0.2.8.1-alpha.
  • Minor bugfixes (relay, usability):
    • Adjust the rules for when to warn about having too many connections to other relays. Previously we'd tolerate up to 1.5 connections per relay on average. Now we tolerate more connections for directory authorities, and raise the number of total connections we need to see before we warn. Fixes bug 33880; bugfix on 0.3.1.1-alpha.
  • Minor bugfixes (SOCKS, onion service client):
    • Detect v3 onion service addresses of the wrong length when returning the F6 ExtendedErrors code. Fixes bug 33873; bugfix on 0.4.3.1-alpha.
  • Minor bugfixes (tests):
    • Fix the behavior of the rend_cache/clean_v2_descs_as_dir when run on its own. Previously, it would exit with an error. Fixes bug 40099; bugfix on 0.2.8.1-alpha.
  • Minor bugfixes (v3 onion services):
    • Remove a BUG() warning that could trigger in certain unlikely edge-cases. Fixes bug 34086; bugfix on 0.3.2.1-alpha.
    • Remove a BUG() that was causing a stacktrace when a descriptor changed at an unexpected time. Fixes bug 28992; bugfix on 0.3.2.1-alpha.
  • Minor bugfixes (windows):
    • Fix a bug that prevented Tor from starting if its log file grew above 2GB. Fixes bug 31036; bugfix on 0.2.1.8-alpha.
  • Code simplification and refactoring:
    • Define and use a new constant TOR_ADDRPORT_BUF_LEN which is like TOR_ADDR_BUF_LEN but includes enough space for an IP address, brackets, separating colon, and port number. Closes ticket 33956. Patch by Neel Chauhan.
    • Merge the orconn and ocirc events into the "core" subsystem, which manages or connections and origin circuits. Previously they were isolated in subsystems of their own.
    • Move LOG_PROTOCOL_WARN to app/config. Resolves a dependency inversion. Closes ticket 33633.
    • Move the circuit extend code to the relay module. Split the circuit extend function into smaller functions. Closes ticket 33633.
    • Rewrite port_parse_config() to use the default port flags from port_cfg_new(). Closes ticket 32994. Patch by MrSquanchee.
    • Updated comments in 'scheduler.c' to reflect old code changes, and simplified the scheduler channel state change code. Closes ticket 33349.
    • Refactor configuration parsing to use the new config subsystem code. Closes ticket 33014.
    • Move a series of functions related to address resolving into their own files. Closes ticket 33789.
  • Documentation:
    • Replace most http:// URLs in our code and documentation with https:// URLs. (We have left unchanged the code in src/ext/, and the text in LICENSE.) Closes ticket 31812. Patch from Jeremy Rand.
    • Document the limitations of using %include on config files with seccomp sandbox enabled. Fixes documentation bug 34133; bugfix on 0.3.1.1-alpha. Patch by Daniel Pinto.
  • Removed features:
    • Our "check-local" test target no longer tries to use the Coccinelle semantic patching tool parse all the C files. While it is a good idea to try to make sure Coccinelle works on our C before we run a Coccinelle patch, doing so on every test run has proven to be disruptive. You can still run this tool manually with "make check-cocci". Closes ticket 40030.
    • Remove the ClientAutoIPv6ORPort option. This option attempted to randomly choose between IPv4 and IPv6 for client connections, and wasn't a true implementation of Happy Eyeballs. Often, this option failed on IPv4-only or IPv6-only connections. Closes ticket 32905. Patch by Neel Chauhan.
    • Stop shipping contrib/dist/rc.subr file, as it is not being used on FreeBSD anymore. Closes issue 31576.
  • Testing:
    • Add a basic IPv6 test to "make test-network". This test only runs when the local machine has an IPv6 stack. Closes ticket 33300.
    • Add test-network-ipv4 and test-network-ipv6 jobs to the Makefile. These jobs run the IPv4-only and dual-stack chutney flavours from test-network-all. Closes ticket 33280.
    • Remove a redundant distcheck job. Closes ticket 33194.
    • Run the test-network-ipv6 Makefile target in the Travis CI IPv6 chutney job. This job runs on macOS, so it's a bit slow. Closes ticket 33303.
    • Sort the Travis jobs in order of speed. Putting the slowest jobs first takes full advantage of Travis job concurrency. Closes ticket 33194.
    • Stop allowing the Chutney IPv6 Travis job to fail. This job was previously configured to fast_finish (which requires allow_failure), to speed up the build. Closes ticket 33195.
    • Test v3 onion services to tor's mixed IPv4 chutney network. And add a mixed IPv6 chutney network. These networks are used in the test-network-all, test-network-ipv4, and test-network-ipv6 make targets. Closes ticket 33334.
    • Use the "bridges+hs-v23" chutney network flavour in "make test- network". This test requires a recent version of chutney (mid- February 2020). Closes ticket 28208.
    • When a Travis chutney job fails, use chutney's new "diagnostics.sh" tool to produce detailed diagnostic output. Closes ticket 32792.
  • Deprecated features (onion service v2):
    • Add a deprecation warning for version 2 onion services. Closes ticket 40003.
  • Documentation (manual page):
    • Add cross reference links and a table of contents to the HTML tor manual page. Closes ticket 33369. Work by Swati Thacker as part of Google Season of Docs.
    • Alphabetize the Denial of Service Mitigation Options, Directory Authority Server Options, Hidden Service Options, and Testing Network Options sections of the tor(1) manual page. Closes ticket 33275. Work by Swati Thacker as part of Google Season of Docs.
    • Refrain from mentioning nicknames in manpage section for MyFamily torrc option. Resolves issue 33417.
    • Updated the options set by TestingTorNetwork in the manual page. Closes ticket 33778.
...