Community Bonding - Progress Report

GSoC Projects Plugin Ecosystem Security
1

PROGRESS :

This week, I worked closely with my mentor on refining the project proposal for the secure plugin ecosystem. We had productive discussions regarding the architecture, and following his review, I made several key changes to the project scope, threat model, and tooling. To validate the new architecture, I also successfully built and tested a working Proof of Concept (PoC) for the new GitHub-based submission workflow. Also ran many tests for finalizing the tooling to use for code scan!
Here's a small demonstration :

Next Week Scope

  • Finalize the Proposal: Update the proposal through feedbacks and lock in the final architectural specifications.

  • Build the Publish Flow: Begin integrating the PoC logic directly into the generator-joplin package to officially start building the new publish flow.

Problem Faced

One of the primary challenges encountered during the early architectural phase was that I was doing a lot of over-engineering and over-complicating many workflows. In an effort to build a perfectly , "bulletproof" security boundary, the initial designs became overly heavy and relied on too many new, tools.
Choosing one tool for the scanning of code was also a very big challenge due to several trade-offs!

2

looks like a noble idea, did you consider the risk that bots will push slop into the repository? Can we mitigate it protecting from this kind of DoS attack? Like a timeout or max number of submissions in a week?

3

Thanks for suggestion!
Current architecture has few rate limiting layers like :

  • Every submission requires a real GitHub OAuth session for PAT so each issue is tied to a verified GitHub account.
  • Mass issue spam would trigger GitHub's own abuse prevention.
  • The CI auto-closes any submission for an already-registered plugin ID. So even if someone spams updates for a plugin they don't own, it gets rejected immediately.
  • And also even if a bot floods submissions, nothing gets merged without a maintainer applying status: approved. The worst case is noise in the issue queue, not actual registry pollution.

While currently our focus is on stabilizing the core architecture, adding a per-account submission cooldown would be an excellent feature to explore as a stretch goal once the primary architecture is ready!