meek might be dead by then:
https://forums.whonix.org/t/replacing-meek-snowflake

Ah I see.

JasonJAyalaP (Jason J. Ayala P.):

JasonJAyalaP added a comment.

I changed it to
NoNewPrivileges=No
That's the only thing I can imagine that would be causing that parsing error. Testing now

> torproject's stretch repository [1] does not contain tor_0.3.1.5 yet.

Once TPOs stretch repo contains the latest, this workaround will no longer be needed, correct?

In T676#14449, @JasonJAyalaP wrote:

with =no, I'm no longer getting the parsing error

sudo journalctl | grep workaround

but /lib/systemd/system/tor@default.service is unaffected

# Hardening
AppArmorProfile=system_tor
NoNewPrivileges=yes
PrivateTmp=yes
PrivateDevices=yes
ProtectHome=yes
...

with =no, I'm no longer getting the parsing error

I changed it to
NoNewPrivileges=No
That's the only thing I can imagine that would be causing that parsing error. Testing now

In T676#14015, @JasonJAyalaP wrote:

Ok I created the workaround as you described:
https://github.com/Whonix/anon-gw-anonymizer-config/blob/master/lib/systemd/system/tor@default.service.d/40_obfs4proxy-workaround.conf

Please keep the Whonix 14 tag. I guess this can be closed, resolved?

JasonJAyalaP (Jason J. Ayala P.):

JasonJAyalaP added a comment.

Ok I created the workaround as you described:

https://github.com/Whonix/anon-gw-anonymizer-config/commit/bfe28e340d03cc4d77e4f49e24bcc0a9da42da06

Debian bug report:

Ok I created the workaround as you described:
https://github.com/Whonix/anon-gw-anonymizer-config/blob/master/lib/systemd/system/tor@default.service.d/40_obfs4proxy-workaround.conf

JasonJAyalaP (Jason J. Ayala P.):

JasonJAyalaP added a comment.

Two things work:

1. Changing obfs4 execution permission in system_tor apparmor profile

(abstractions/tor) from PUx to ix.

2. Keeping PUx but removing "NoNewPrivileges" from tor@default

systemd service (/lib/systemd/system)

Two things work:

Pux (already Tor's default) is alright.

I commented out the lines in local/system_tor about obfsproxy. This caused obfsproxy to fail. Changing obfsproxy to rix didn't work. But I'm confused at what I'm seeing, and so I'm still looking at it.

Comment that and obfs4proxy can run as PUx (instead of needing ix)

To save you from somehow learning about systemd overrides the hard way...

In this case, a /local file can probably not do the trick.

In T676#13872, @JasonJAyalaP wrote:

Ah. I didn't see the include. Makes sense.

Ah. I didn't see the include. Makes sense.

/etc/apparmor.d/system_tor after #include <abstractions/tor> and #include <local/system_tor> will be interpreted like the following, I think:

But what I really don't know is how system_tor interacts with abstractions/

AA doesn't report a denied message when tor tries to launch obfs4. However:

Yes. Because the other solution "not use AppArmor for Tor" is not a great one. It worked in Whonix 13, just needs to be fixed for Whonix 14.

To be clear:
Tor ships a broken apparmor profile (for the last 5 years? Suggested nuke of the profile 3 years ago), and we're trying to unbreak obfs4, correct?

/etc/apparmor.d/system_tor is unmodified, owned by Debian tor packabe. /etc/apparmor.d/system_tor Will #include <local/system_tor>.

In T676#13825, @JasonJAyalaP wrote:

Which app armor profile is blocking obfs4?

Which app armor profile is blocking obfs4? Something from us or an apparmor profile that comes from tpo?

That's why we need to sort it out in https://github.com/Whonix/apparmor-profile-anondist/blob/master/etc/apparmor.d/abstractions/base.anondist somehow.

Tor's own app armor profile breaks needed features (obs4). The ticket is 4 years old with no progress. Even they complained about needed to resolve or remove it (years ago).

You're right. /var/run/tor/log reports
"Could not launch managed proxy executable /usr/bin/obfs4proxy Operation not permitted"

Is the obfs4proxy package installed? Probably yes.

I was trying obfs4proxy in whonix-gateway. I editted the torrc to UseBridges 1 and added the Client Transport line (note, torrc.examples says to add "managed" at the end; https://github.com/Yawning/obfs4 does not). I then added bridges from tpo (bridge obfs4 ip ... ).
Whonixcheck reports WARNING can't connect to bridge REASON=PT_MISSING
PT_Missing is an error from stem: "no pluggable transport was available"

Not easy. Need to wait for reply from TPO.

Didn't make it into Debian version 9 codename Stretch. Rechecking in Debian version 10 codename Buster.

Calling this a duplicate of T118.

Will be checking on this ticket during porting to Debian version 9 codename Stretch (or +1 more depending on when meek lands in Debian).

In T386#6199, @HulaHoop wrote:

Closing this ticket.

Its part of a bigger project of how we want to add pluggable transport support for Whonix, discussed in https://phabricator.whonix.org/T118

Then we exactly point that out.

HulaHoop (HulaHoop):

I've thought about it and I don't think we should advise putting
censorship circumvention tools between a user and entry guard (except
bridges and pluggable transports of course). All other tools besides
pluggable transports are ill equipped to resist protocol
fingerprinting and can have security problems. Using them to mask Tor
traffic would be a red flag that narrows the user base to people who
have seen this page which goes against advGoalTracking.

I've thought about it and I don't think we should advise putting censorship circumvention tools between a user and entry guard (except bridges and pluggable transports of course). All other tools besides pluggable transports are ill equipped to resist protocol fingerprinting and can have security problems. Using them to mask Tor traffic would be a red flag that narrows the user base to people who have seen this page which goes against advGoalTracking.

I don't think it's important for the implementation of this ticket. However, this is as I guess things internally work...

In T90#6837, @troubadour wrote:

A note about T118. Been on and off on that one. It looks like tor-launcher is merely settings variables, and that the actual work (like editing torrc or starting meek-client) is done downstream, in firefox or wherever. So I'm not sure it's even possible achieve the bridges settings that way, without starting Tor browser.

• Couldn't talk to the ones working on tor-launcher at Tor summer dev meeting 2015. mp / geko not working on this. Therefore still no feedback on how a patch could be designed.
• Roger said,
  • it's not worth it going through lengths to make TBB/tor-launcher work as system Tor.
  • Pluggable transports will not be changing that fast for now. Duplicating an alternative to tor-launcher and proper packaging for meek would be the way forward.
• Fragile / crazy idea.

Did some analysis, had the tor-browser_en-US folder managed by git before/during/post update.

I see. Sounds interesting. It's still unclear if checkrestart is capable of monitoring arbitrary processes that are not managed by dpkg/apt-get. And if it would be easier to replicate this lsof based check rather than bending checkrestart to do that. (Also undesirable to have both checkrestart and needrestart installed at the same time, see T324.)

Checkrestart is a Python application wrapping lsof (“list open files”). It tries to identify files used by processes that are not in the file system anymore. How so?

Note that during an update a certain binary file becomes replaced: the new version is first downloaded to disk and then rename()ed in order to overwrite the original. During POSIX rename() the old file becomes deleted. But the old file is still in use! The standard says that if any process still has a file open during its deletion, that file will remain “in existence” until the last file descriptor referring to it is closed. While these files that are still held “in existence” for running processes by the operating system, they are not listed in the file system anymore. They can however easily be identified via the lsof tool. And this is exactly what checkrestart does.

Hence, checkrestart “compares” the open files used by running processes to the corresponding files in the file system. If the file system contains other (e.g. newer) data than the process is currently using, then checkrestart proposes to restart that process. In a tidy server environment, this usually is the case only for updated shared library files.

fixed obfsproxy AppArmor issue "OSError: [Errno 13] Permission denied: '/rw/usrlocal/lib/python2.7/dist-packages'" using superior /etc/apparmor.d/tunables/home.d/qubes-whonix-anondist solution - https://phabricator.whonix.org/T396:
https://github.com/Whonix/apparmor-profile-anondist/commit/8785d3124c75dc39c6da2f1753e19b02d625a987

In T118#6510, @HulaHoop wrote:

One problem I can see is the need to restart TBB for updates to take effect. Without a GUI it's not possible for a user to know this information directly but needrestart can detect updated daemons by open file descriptors and restart them.

One problem I can see is the need to restart TBB for updates to take effect. Without a GUI it's not possible for a user to know this information directly but needrestart can detect updated daemons by open file descriptors and restart them.

Actually, that's a much better solution.

In T118#6361, @HulaHoop wrote:

TBB 5+ enables automatic updates by default. No custom modifications needed.

Starting with this release, Tor Browser will now also download and apply upgrades in the background, to ensure that users upgrade quicker and with less interaction. This behavior is governed by the about:config pref app.update.auto, but we do not recommend disabling it unless you really know what you're doing.

https://blog.torproject.org/blog/tor-browser-50-released

Got another answer.

In T396#6413, @Patrick wrote:

AppArmor upstream feature request - symlink support:
https://bugs.launchpad.net/apparmor/+bug/1485055

AppArmor upstream feature request - symlink support:
https://bugs.launchpad.net/apparmor/+bug/1485055

A real fix would require having an AppArmor option to follow symlinks.

TBB 5+ enables automatic updates by default. No custom modifications needed.

Nice progress!

Significant progress has been made:
Using Tor / Pluggable Transports from the Tor Browser Bundle

I succeeded starting TBB as user debian-tor.

Another blocker problem: TBB will refuse to run as root. Not going to be possible to run it as system Tor. Cannot use debian-tor group.

But then we'll don't get a pluggable transports gui (tor-launcher) within the next how many years. And no access to recent (working!) pluggable transports.

I think this whole thing is a hack. Should therefore just be optional. It's also more likely to break. Too experimental to make it the default for everyone. And cumbersome.

I'm assuming we are completely replacing Debian repo's system Tor with TBB Tor.

I'm assuming we are completely replacing Debian repo's system Tor with TBB Tor.

HulaHoop (HulaHoop):

Launching Tor and TBB from command line:

Launching Tor and TBB from command line:
https://askubuntu.com/questions/320545/how-to-launch-tor

Good ideas! I would call this development / TODO research tasks, though.

Closing this ticket.

At the moment we have three choices:

In T386#6195, @HulaHoop wrote:

Running Whonix Gateway behind another Whonix Gateway doesn't work for some reason. Any suggestions? I can't run this in the clear when I've already talked about it because it can be linked to me.

In T386#6194, @HulaHoop wrote:

• The problems discussed in https://trac.torproject.org/projects/tor/ticket/14121 can be solved even if the features requested are never developed. Running TBB Tor headlessly is possible thru using xvfb (pkg that tricks a gui application into thinking its connected to a X-server) and something like selenium.

https://github.com/webfp/tor-browser-crawler
https://github.com/isislovecruft/tor-browser-selenium

Even when we can run TBB headlessly and still take advanatge of torlauncher-gui I forsee problems that will make the entire idea a non-starter. We cannot redistribute TBB binaries. They must be downloaded. Imagine users in censored areas where they can't connect with Tor how will they be able to fetch TBB when connections to TPO are censored? Downloading from alternative distribution channels using GetTor will leave all kinds of network fingerprints.

The only sane solution is for TPO to spin off torlauncher-gui into its own independent package along with all pluggable transports, all in their repo so we can redistribute them freely and generate builds that include them without problems.

Running Whonix Gateway behind another Whonix Gateway doesn't work for some reason. Any suggestions? I can't run this in the clear when I've already talked about it because it can be linked to me.

Did you succeed in setting this up you? Can you share instructions in meanwhile please?