quote https://forums.whonix.org/t/whonix-16-has-been-released-debian-11-bullseye-based-for-virtualbox-major-release/12297

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.