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

sdk: Configure custom proxy VM via QubesDB/env; update docs #2236

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

legoktm
Copy link
Member

@legoktm legoktm commented Sep 20, 2024

Status

Ready for review

Description

Instead of using a custom /etc/sd-sdk.conf for setting a custom proxy VM, use our now established pattern of using QubesDB or the environment.

I am somewhat dubious of the use case of using a different proxy VM, but I can see how it could be useful for some debugging operations.

Update and remove a lot of documentation around updating VCR cassettes that was outdated but referenced this configuration mechanism.

Fixes #2040.

Test Plan

  • visual review (I think that is sufficient, I don't think it merits actually testing by cloning the proxy VM, setting the QubesDB flag, etc.)
  • CI passes

Checklist

  • These changes should not need testing in Qubes
  • No update to the AppArmor profile is required for these changes (maybe it should've been??)
  • No database schema changes are needed

@legoktm legoktm requested a review from a team as a code owner September 20, 2024 19:12
Instead of using a custom `/etc/sd-sdk.conf` for setting a custom proxy
VM, use our now established pattern of using QubesDB or the environment.

I am somewhat dubious of the use case of using a different proxy VM, but
I can see how it could be useful for some debugging operations.

Update and remove a lot of documentation around updating VCR cassettes
that was outdated but referenced this configuration mechanism.

Fixes #2040.
Copy link
Member

@cfm cfm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, thank you for doing this, @legoktm. One nit inline if you feel like it; otherwise feel free to merge.

@@ -39,11 +39,13 @@ class Config:
"gpg_domain": "QUBES_GPG_DOMAIN",
"journalist_key_fingerprint": "SD_SUBMISSION_KEY_FPR",
"download_retry_limit": "SD_DOWNLOAD_RETRY_LIMIT",
"proxy_vm_name": "SD_PROXY_VM_NAME",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very nit: Now that we have two keys that refer to other VMs, do we want to standardize their naming? QUBES_GPG_DOMAIN isn't up to us. Is SD_*_VM_NAME the convention we want to use for the ones that are? I would probably accept the asymmetry (as we do for SD_SUBMISSION_KEY_FPR) of:

Suggested change
"proxy_vm_name": "SD_PROXY_VM_NAME",
"proxy_vm_name": "SD_PROXY_VM", # or "SD_PROXY_DOMAIN"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Under Review
Development

Successfully merging this pull request may close these issues.

securedrop_client.sdk should also be configured via QubesDB
2 participants