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.

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

Journalist UI could not be reached via v3 URL 1.0.0~rc1 #4738

Closed
kushaldas opened this issue Sep 4, 2019 · 8 comments · Fixed by #4744
Closed

Journalist UI could not be reached via v3 URL 1.0.0~rc1 #4738

kushaldas opened this issue Sep 4, 2019 · 8 comments · Fixed by #4744

Comments

@kushaldas
Copy link
Contributor

Description

I could not reach the journalist UI via v3 onion address.

Steps to Reproduce

  • Updated from only v2 onion based 1.0.0~rc1 to both v2 and v3 enabled system.
  • Ran ./securedrop-admin tailsconfig on the admin workstation
  • Tried to open the journalist UI by double clicking on the desktop icon.

Note: The source v3 onion address is working fine, and if I type in the old v2 onion address manually, it is currently working.

Expected Behavior

The journalist UI should come up.

Actual Behavior

The Tor Browser can not find the onion address.

@redshiftzero redshiftzero added this to the 1.0.0 milestone Sep 4, 2019
@eloquence eloquence added this to SecureDrop 1.0.0 Release - 9/4-/9/18 in SecureDrop Team Board Sep 4, 2019
@rmol
Copy link
Contributor

rmol commented Sep 4, 2019

Confirmed.

@rmol
Copy link
Contributor

rmol commented Sep 4, 2019

The problem seems to be that the securedrop_init.py hook isn't getting run during tailsconfig, so /var/lib/tor/onion_auth isn't getting populated. I bounced the network manually to get it run, that directory was populated, and I can now reach the journalist interface.

I think the cause is that the copy task in configure_network_hook.yml (Copy NetworkManager hook for managing SecureDrop interfaces.) doesn't have force: yes, so if the file doesn't need to be copied, the notify doesn't fire and the handler doesn't run securedrop_init.py.

@rmol
Copy link
Contributor

rmol commented Sep 4, 2019

Nope, copy with force: yes still only copies the file if the source content differs from the destination.

It looks like we might want to either populate /var/lib/onion/auth outside of the hook, or move the hook to a task instead of a handler?

@zenmonkeykstop
Copy link
Contributor

This is an existing bug iirc - securedrop_init.py also updates the torrc with the v2 HidServAuth changes, so v2 services would have been subject to the same issue.

FWIW I couldn't reproduce on a fresh VM install, but that's probably because the network hook did run when tailsconfig ran.

@zenmonkeykstop
Copy link
Contributor

Moving the hook to a task makes most sense to me.

@conorsch
Copy link
Contributor

conorsch commented Sep 4, 2019

Moving the hook to a task makes most sense to me.

Makes sense to me. That's a simple approach, and the only downside is that the hook will run (and bounce tor) every time tailsconfig is run—hardly a major disadvantage.

populate /var/lib/onion/auth outside of the hook

That'd indeed be slightly cleaner, requiring the network hook to bounce only if changes were detected, but it doesn't seem worth the effort in order to provide a stable experience to Admins.

@rmol
Copy link
Contributor

rmol commented Sep 4, 2019

OK. On it. Thanks!

@zenmonkeykstop
Copy link
Contributor

There's an extra directive to be added to torrc to point to the onion_auth directory anyway, so it would still need to be bounced by the hook even if the files were added elsewhere.

SecureDrop Team Board automation moved this from SD 1.0.0 Release Sprint - 9/4-/9/18 to Done Sep 4, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
No open projects
Development

Successfully merging a pull request may close this issue.

5 participants