multi-admin behavior: no error at missing v3_onion_services value in an installed system

[kushaldas]

Description

A short summary of the issue.

Steps to Reproduce

• Backup your v2 only site-specific file before upgrade
• Test multi-admin behavior. Conduct this test step after v3 is enabled on the server:
  • Back up site-specific, and copy the version from before the upgrade into place instead. Re-run ./securedrop-admin install, and verify that it fails with a user-friendly message, due to v3_onion_services=False.

Expected Behavior

Seeing an user-friendly error message

Actual Behavior

Can not see any error message.

[zenmonkeykstop]

Error appears for me in the task tor-hidden-services: Confirm service state matches declared config:

The "sdconfig" setings did not specify v3 Onion services, but..."

[rmol]

I'm seeing the same error. I think this is working as expected.

[rmol]

What should an admin do if they actually intend to stop offering v3 services, though? Do we really want to disallow that, or at least to require manual (error-prone) intervention? If not, we shouldn't break securedrop-admin install after a legitimate sdconfig change. 🤔

[zenmonkeykstop]

That's worth breaking out into an issue IMO.

[zenmonkeykstop]

But also IMO since v3 services will be required eventually, and there's a migration path that allows for both v2 and v3 for a smooth transition, my hope would be that admins would follow that one rather than switching from v2 to v3 and then back again if they hit problems
.

[conorsch]

Agreed with @zenmonkeykstop: v2 onions won't be around forever. If an Admin really wants to downgrade from v3 -> v2, that's entirely possible with some small tweaks manually to the torrc file. Supporting that regressive change as a first-class feature of the sdconfig workflow seems like more work than it's worth.

[eloquence]

We agreed during standup today that the configuration behavior will need to be clarified as a note to admins the docs (making it clear that enabling v3 is not trivially reversible), with no change to the logic. This can be done as a commit in #4763, which once merged, can resolve this issue.

[eloquence]

As discussed, this was clarified in the docs:

In a future release of SecureDrop, v3 onion services will be required rather than optional, and there is no automatic downgrade path from v3 to v2 using the securedrop-admin tool.

Closing this issue as a result.