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

[security] switch away from self-hosted packages #370

Open
cyphar opened this issue Apr 12, 2019 · 7 comments

Comments

Projects
None yet
4 participants
@cyphar
Copy link

commented Apr 12, 2019

Currently, in order for a user to run their own homeserver they are told to use the package repos hosted by matrix.org. This is not a great idea, for a few reasons (which were highlighted by this attack):

  1. Single point of failure. During the attack and rebuild, the package repos were down -- so users wouldn't be able to install new packages. An example of this is that I have a Matrix homeserver set up, but since riot.im was down I wanted to install riot-web in order to have my own riot-web client. Unfortunately the packages are hosted on riot.im, so I'm SoL until the infrastructure is back.

  2. There is no separation (from a security perspective) between the package hosting and homeserver hosting. Yes, you might have firewalled things -- but since the same people are in charge of the infrastructure of both then an attack on the Matrix homeserver can cause issues with the packages used by self-hosters and vice-versa.

Ideally, I would suggest that packages should be entirely maintained in distributions. But at the very least they should not be hosted on the matrix.org infrastructure. I'm a bit biased, but I would suggest hosting on the Open Build Service which supports hosting for a vast array of distributions and is entirely maintained by SUSE/openSUSE. And GPG key leaks like this wouldn't happen (users don't have access to the keys). Yes, you'd have more credentials to deal with but the building of packages is entirely transparent on OBS (rather than being a random blob we download from matrix.org).

@ptman

This comment has been minimized.

Copy link
Contributor

commented Apr 12, 2019

At least debian https://packages.debian.org/sid/matrix-synapse and ubuntu https://packages.ubuntu.com/disco/matrix-synapse have synapse packages. They aren't the latest, but at least debian has a security team that looks after stuff.

@cyphar

This comment has been minimized.

Copy link
Author

commented Apr 12, 2019

As does openSUSE. I think distributions packaging it themselves is the most ideal solution for users (since it gives extra chances for review), but users should either be told to use the official packages from distros or the packages should be hosted outside of the infrastructure that hosts matrix.org.

@gloomy-ghost

This comment has been minimized.

Copy link

commented Apr 13, 2019

separation (from a security perspective)

as long as the signing key is air-gapped it doesn't really matter where the package is hosted. the problem is - do you trust matrix.org folks are following this practice.

@cyphar

This comment has been minimized.

Copy link
Author

commented Apr 13, 2019

as long as the signing key is air-gapped it doesn't really matter where the package is hosted.

Sure, though as I mentioned above you still a single point-of-failure on the Matrix.org infrastructure (so maybe you won't get a malicious package, you'll just get a 404). There's also the point that maintaining the package in a distribution gives you extra review steps (rather than being something that's automatically pushed from CI).

the problem is - do you trust matrix.org folks are following this practice.

Well, we now know they weren't. To be fair, I'm sure the vast majority of third-party repositories have undesirable setups for their package signing -- though it doesn't make the situation any less awful.

@Mikaela

This comment has been minimized.

Copy link

commented Apr 13, 2019

How about priorising Flatpak and Snap? Flatpak is only for GUI apps so it would only help Riot, but Snap also works for daemons/headless systems and I think IPFS is also distributed through it.

@ptman

This comment has been minimized.

Copy link
Contributor

commented Apr 13, 2019

Docker already serves that purpose for synapse IMO.

@gloomy-ghost

This comment has been minimized.

Copy link

commented Apr 13, 2019

snap doesn't even let you disable auto-update... suppose an update deadline can force people to audit the package before installing it?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.