Migrate localization to hosted Weblate

[eloquence]

[All copy below by @cfm mostly from March 2024; transferred here from an internal repository.]

Affected components

• SecureDrop
• SecureDrop Client

People

• Infrastructure has been consulted in freedomofpress/infrastructure#4617 (internal repo).

Problem statement

We currently ask the Infrastructure team to do the care and feeding of our own Weblate instance at weblate.securedrop.org. However, most projects Localization Lab works with just use the hosted Weblate service at hosted.weblate.org, just as most (and we!) use either GitHub or GitLab for code. Neither @adaFPF nor I have been able to come up with a convincing security rationale for special-casing our localization platform in this way.

Solution impact

Any change to our localization platform will affect:

• translators;
• reviewers;
• Localization Lab staff; and
• SecureDrop maintainers, who interact with Weblate most while preparing releases.

Requirements and constraints

Any action we take here:

1. MUST achieve security properties equivalent to the status quo;
2. MAY define those security properties and explain why moving to hosted Weblate would in fact not preserve them; and
3. SHOULD ideally lessen or eliminate Infrastructure's burden in maintaining our own self-hosted Weblate instance.

Exploration

See freedomofpress/infrastructure#4617 for background (internal repo).

Initial proposal

Phase 1: Is this even worthwhile?

1. Contact the Weblate team to ask about pricing for our project: >20,000 source strings, 54 languages, but open-source.
2. Infrastructure, probably @soleilera: Decide whether this monetary cost would be a worthwhile tradeoff from the current time/capacity cost.
3. Optional: Sketch a security model for our use of (a) Weblate for translations versus (b) GitHub for source code.
   • hosted.weblate.org links to and summarizes their use and privacy policies from its registration page.

Phase 2: Will this work for us?

4. Set up a trial of the appropriate Weblate plan.
5. Import freedomofpress/securedrop and freedomofpress/securedrop-client directly from Git.
   • Does continuous localization set up correctly? (This may require testing against our sandbox repositories.)
   • Does translation memory and history import correctly?
   • Are translator attributions preserved, both for (a) those translators who are already registered at hosted.weblate.org and (b) those who aren't? (Via Git, no non-public PII is transferred this way.)
6. Compare (feel free to add to this list):
   • Cookies etc. used by hosted.weblate.org versus weblate.securedrop.org
   • What other projects that use hosted Weblate do in their own tools and processes.

Go/no-go decision between SecureDrop and Infrastructure

Phase 3: Migration

TK, but MUST involve:

• Plenty of lead time before the next release from freedomofpress/securedrop and freedomofpress/securedrop-client
• Coordinating with Localization Lab

Suggestions to consider:

• Lint that pull requests coming from Weblate only touch .po/.mo files
• Test Weblate's user-matching/melding behavior from Git history alone, without our user data

The good news is that the actual switchover should be risk-free, since we won't change anything in our repositories or disable anything at weblate.securedrop.org until we're happy with things at hosted.weblate.org.

Selected proposal

Additional notes

The major thing to call out about this proposal (since we first discussed this informally two weeks ago) is that hosted Weblate would very likely cost us some money. Even if we're comfortable with this proposal on the technical merits, I'll have to defer to the Infrastructure team on the tradeoff between capacity and budget.

[adaFPF]

After having done some deep diving into Weblate's guts, one reason to reconsider moving to hosted weblate is that it requires granting repo-level write privs to hosted weblate automation that is used for all hosted weblate translations (not just ours), and that presumably maintainers on Weblate have access to. i.e. widening of attack surface + trust requirements + slightly higher chance of getting caught up in the compromise of a juicier target

Our branch protection rules should prevent most malicious action on SD resources if their automation is compromised, but I can think of one thing we'd still be vulnerable to (not specifying since this is publicly visible). If we did want to make this move still, we could consider returning to the paradigm of "Allow Weblate bot privileged direct push to FPF-managed translation fork" -> "Merge to primary repo via PR."

Not saying "yes" or "no", just adding some context post-transfer of this issue.

[legoktm]

We briefly discussed this today in a call with @eloquence, @adaFPF, @cfm and myself.

There's some additional context that Ada has added to https://github.com/freedomofpress/infrastructure/issues/4617#issuecomment-3165180153 that changes the status of the earlier assertion "Neither @adaFPF nor I have been able to come up with a convincing security rationale for special-casing our localization platform in this way."

So I would propose that from the SecureDrop side of things, we close this with the understanding that:

• in general the SecureDrop team is neutral on where things are hosted, with the caveat that we have relatively strict branch protection rules that we'd like to keep in place (specifically that weblate can only push to a dedicated branch)
  • and to the extent that we would need to help with the migration, we have limited to no resources on it for probably the rest of the quarter or even year.
• we defer more to Infra on whether the burden of supporting self-hosted weblate outweighs the security benefits we get from using it and if they'd like to work on said migration.

tl;dr: SecureDrop isn't motivated to migrate, the ball is in Infra's court if they'd like to.