Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Automatically handle Whonix's "Anon Connection Wizard" #1096

Open
1 task done
legoktm opened this issue Jun 24, 2024 · 3 comments · May be fixed by freedomofpress/securedrop-client#2099
Open
1 task done

Automatically handle Whonix's "Anon Connection Wizard" #1096

legoktm opened this issue Jun 24, 2024 · 3 comments · May be fixed by freedomofpress/securedrop-client#2099

Comments

@legoktm
Copy link
Member

legoktm commented Jun 24, 2024

  • I have searched for duplicates or related issues

Description

When you provision SDW or start it for the first time, you need to manually step through Whonix's Anon Connection Wizard, it would be nice if we could do that automatically for users, with some override for users who need to use a bridge.

How will this impact SecureDrop/SecureDrop Workstation users?

Users no longer need to manually walk through the Whonix connection interface, which reduces the chances of user confusion or even mistakes.

How would this affect the SecureDrop Workstation threat model?

As long as we allow people a way to set bridges, etc., I don't think it should.

User Stories

  • As a user, I don't want to manually step through a dialog that I don't need to.
  • As a developer I don't want to repeatedly manually step through the same dialog over and over when I reinstall SDW.

Notes
deeplow added a commit that referenced this issue Jun 24, 2024
@deeplow
Fix issue blocking sd-viewer & sd-app to be marked internal
92daddc 
The issue was due to a double yaml intruction, which when rendered
and interpreted lead to the first `set` to be ignored.

Fixes: #1096
legoktm pushed a commit that referenced this issue Jun 25, 2024
@deeplow @legoktm
Fix issue blocking sd-viewer & sd-app to be marked internal
25cf9fb 
The issue was due to a double yaml intruction, which when rendered
and interpreted lead to the first `set` to be ignored.

Fixes: #1096
legoktm pushed a commit that referenced this issue Jun 26, 2024
@deeplow @legoktm
Fix issue blocking sd-viewer & sd-app to be marked internal
b7d540f 
The issue was due to a double yaml intruction, which when rendered
and interpreted lead to the first `set` to be ignored.

Fixes: #1096
@rocodes
Copy link
Contributor

rocodes commented Jul 9, 2024

I looked into this. The correct thing to do is adjust the (empty, whonix-provided) file /usr/local/etc/torrc.d/50_user.conf so that it contains the line DisableNetwork 0. That bypasses the anon connection wizard and configures a regular Tor connection as if the user had selected the "Connect" button in the wizard.

A few notes:

  • If any SDW users are using Tor bridges, this won't work for them and they will need to remove this line. (When they reboot, the anon-connection-wizard will be retriggered, or they can run it manually).
    • If we're confident that most/all of our SDW users are not using Tor bridges to connect, this seems like a reasonable UX improvement + we can document what users who want to use Tor bridges would need to do. We may need more info on this.
  • There's (currently) no harm in entirely replacing the file /usr/local/etc/torrc.d/50_user.conf, since whonix leaves the file alone if it's already present rather than clobbering it on upgrade. The same is not guaranteed to be true about 40_tor_panel_control.conf.
    • But it seems like the proper debian way to do this might be to dpkg-divert that file and symlink to our own file rather than just overwriting it (and I think you can't just overwrite one file in /usr/local anyway or debhelper complains - ask me how I know ;) )
    • Or edit/append to the file in Salt or in the securedrop-whonix-config postinst, but I really like that we are getting away from editing files in place.

@legoktm
Copy link
Member Author

legoktm commented Jul 9, 2024

Ooh!

If we're confident that most/all of our SDW users are not using Tor bridges to connect, this seems like a reasonable UX improvement + we can document what users who want to use Tor bridges would need to do. We may need more info on this.

Agreed on getting more info from users first, assuming it matches our intuition I think we could default to no bridges, with some way to flag (maybe "bridges": true in config.json) that manual configuration is desired.

But it seems like the proper debian way to do this might be to dpkg-divert that file and symlink to our own file rather than just overwriting it (and I think you can't just overwrite one file in /usr/local anyway or debhelper complains - ask me how I know ;) )

Heh :) Or maybe a systemd unit to create the file, to make it easy to connect w/ qubesdb/qubes services.

@rocodes
Copy link
Contributor

rocodes commented Jul 9, 2024 •
edited
Loading

Or maybe a systemd unit to create the file, to make it easy to connect w/ qubesdb/qubes services.

So the file is already created by whonix, which is why I was looking at dpkg-divert since we'd be replacing a file that we didn't put in place. But I actually think (even though it's what I didn't want to do before) the simplest thing may be to append to the file, maybe in sd whonix config postinst. And I like your idea about making it configurable.

@rocodes rocodes linked a pull request Jul 9, 2024 that will close this issue
Draft
13 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
2 participants
@legoktm @rocodes