[go: up one dir, main page]

Page MenuHomePhabricator

Security Readiness Review For Suggestor
Closed, DeclinedPublic

Description

Project Information

Description of the tool/project: Suggestor is intended to allow Tor users (but open to anyone really) to suggest edits that other, logged-in users can then approve and take responsibility for under their own account (via OAuth). In this way Tor users can maintain their privacy, have their contribution be added to wikis, not violate the spirit of the Tor blocking, as other users are making the edit on their behalf.

Description of how the tool will be used at WMF:

  • A JavaScript module will be added to Extension:TorBlock offering Tor users the opportunity to send their edit through Suggestor (happens client-side)
  • Suggestor performs some basic sanity/anti-abuse measures (e.g. SpamBlacklist, ORES) checks on the proposed edits
  • Wiki users logged in via OAuth can review and approve/reject edits from the queue. Each edit is made under the reviewers account, as they are taking responsibility for the edit.

Dependencies

List dependencies, or upstream projects that this project relies on.

Suggestor is being rewritten in Rust. Dependencies will be in Cargo.{toml,lock}, I can list them here if you'd like.

Has this project been reviewed before?

Please link to tasks or wiki pages of previous reviews.

No.

Working test environment

Please link or describe setup process for setting up a test environment.

TBD.

Post-deployment

Name of team responsible for tool/project after deployment and primary contact.

Same team

Comments
While most of the code being written is primarily for Toolforge, which is out of scope of the security team's reviews, some will be integrated into TorBlock, which is in scope. I'd also especially like to make sure we're not undermining TorBlock's technical measures.

Related Objects

StatusSubtypeAssignedTask
OpenNone
DeclinedNone

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript
sbassett changed the task status from Open to Stalled.Jul 20 2020, 4:57 PM
sbassett triaged this task as Low priority.
sbassett moved this task from Incoming to Back Orders on the secscrum board.
sbassett subscribed.

I'm going to stall this as low until we have a more concrete deployment date and an agreed-upon commit sha at which to freeze the new Rust code base for the review. Also - just to set expectations - we don't have an enormous amount of experience auditing Rust apps, so this will likely be more of a due-diligence review.

DannyS712 added a subscriber: Bodhi_Tri.
DannyS712 removed a subscriber: Bodhi_Tri.
sbassett lowered the priority of this task from Low to Lowest.Sep 2 2020, 4:20 PM
Jcross subscribed.

Untagging as there has been no activity. Please feel free to re-tag if this moves forward and we will be happy to triage.

This task is a Security Readiness Review request, so this task should be tagged with Application Security Reviews which allows to find all and any security readiness review requests by looking at tasks tagged with Application Security Reviews.
If this task is not an actionable review request, then please set its task status to "stalled". Once this task becomes actionable, please change back the task status to "open".
Thanks.

That Herald rule makes no sense.

JBennett subscribed.

The Security team is updating their readiness review SOP to reflect a new change that any request that has aged 90 days without being in a reviewable state will be declined. We do this to help keep our work area current, accurate and reflective of actual work. If the status of your project changes please re-tag us and we will get this work scheduled.

@Jcross: Please do not remove correct metadata as it makes it harder to find tasks. This is and was a security readiness review request (which has been declined). Thanks.