hub icon indicating copy to clipboard operation
hub copied to clipboard

Discussion on the status of Espanso Hub, and next steps

Open federico-terzi opened this issue 6 months ago • 10 comments

Hi all!

I'm writing this issue to align all the team and contributors on the current state of the Espanso Hub. Hopefully, this will give everyone enough context to participate in the discussion.

The core principle that motivates many of the choices detailed below is: Security should be a top priority.

Current state

The Espanso Hub is currently stuck. The last package was merged 9 months ago, and we have >20 packages waiting to be reviewed and merged. This is my fault and I'm sorry about it, I became a bottleneck because I'm (currently) the only one with permission to approve and merge packages, and I've been unable to dedicate time to it in the past few months.

Motivation

The community raised some really valid points in https://github.com/espanso/espanso/issues/1742, which I'll try to address here

Why can't package authors update their packages independently? That would speed up the process

Nothing would stop a package maintainer from publishing a good looking package, and then publishing an update that contains a match like:

  - trigger: "a"
    replace: "{{output}}"
    vars:
      - name: output
        type: shell
        params:
          cmd: "rm -Rf ~"

so that as soon as the user types a, all their files are gone. Script and shell extensions are particularly dangerous.

On one hand, I'm against walled gardens (like Apple's AppStore), but on the other, I'd love to maintain the user expectation that every package they download from the Hub is vetted and safe. There are approaches to mitigate the effort (like improving automatic checks), but removing the review process (even for known package creators) could lead to dangerous packages being released. Keeping in mind that users can still share their packages with others outside the Hub, I still believe that this model is better (although scaling the reviewers team is for sure necessary, because I'm definitely a bottleneck here)

Seems to me you just gave excellent reasons for excluding script and shell extensions from the hub, on principle.

Excluding shell and script extensions is an option, but would limit the usefulness of many packages currently available in the Hub. Examples:

  • https://hub.espanso.org/get-ip
  • https://hub.espanso.org/rand-tools

Proper human reviews are the only solution I can think of to allow those useful packages without posing a security risk for users

Maybe create a CI that validates the packages?

We already do: https://github.com/espanso/hub/tree/main/.github/scripts/validate There's a list of rules currently being checked, and when run, they verify that the package satisfies a set of must-have conditions. Unfortunately, there's a significant problem with the current approach, and again, it's motivated by security.

A bit of context:

Every time a package is merged on the main branch, a Github Action pushes it on the hub-frontend: https://github.com/espanso/hub-frontend so that it can be displayed in the Hub This action is a sensitive operation, because it requires a token that grants write access to the Espanso Hub

If you want to run GitHub actions against PRs opened by external contributors, things get tricky. If permissions are not configured correctly, a malicious user could modify the GitHub actions configuration as part of the PR and extract secrets (for more information, see: https://github.blog/2020-08-03-github-actions-improvements-for-fork-and-pull-request-workflows/#improvements-for-public-repository-forks). At the time, I went with the easiest solution that also guaranteed good security: on each new PR, I would manually review that the PR did not change the GitHub actions configuration, and then approve the workflow manually. Clearly, this does not scale very well.

A solution to allow automated workflows while also guaranteeing good security exists, but it takes time to configure correctly, and unfortunately I didn't have capacity in the past few months. See: https://securitylab.github.com/research/github-actions-preventing-pwn-requests/

Reality check: How does Maven Central do it? Or PyPi? Or Rubygems? Or sdkman? Or GitHub Packages?

That's a good question. Due to the nature of Espanso, most users are fairly technical. That said, downloading a package from PyPi and from Espanso might trigger different expectations: when you download a python package, you are downloading an executable, which is dangerous by nature. For many users, Espanso packages might seem safer (most of them are just string replacements after all), and with the Hub, I wouldn't want to break this expectation. If a package is on the Hub, it should be safe to run (dangerous packages can be hosted in external repositories, if necessary)

Thoughts?

cc @AucaCoyan @smeech

federico-terzi avatar Feb 20 '24 21:02 federico-terzi