PortsMaster / PortMaster-New

New PortMaster repo
https://www.portmaster.games
MIT License
68 stars 70 forks source link

Port build reproducibility and security #699

Open Lgt2x opened 9 hours ago

Lgt2x commented 9 hours ago

Hi there! First of all, I hope this is the right place to discuss this. I've recently been looking into Linux handheld gaming software, and PortMaster seems to be a project on the rise when it comes to running desktop games.

Running PortMaster for the first time was a pretty smooth experience, but looking into it more left me with a few questions that are not addressed in the FAQ. Adding a new port looks very straightforward: a README, a few xml/json metadata files, and a bash script doing whatever it needs to get the game to run.

What was more surprising to me was seing raw binary executable embedded in the repository (making it really large and cumbersome to clone without LFS :/ ), especially for games derived from open source engines. I don't feel confident running binaries added by the community through Pull Requests that anyone can open, for 2 main reasons, the first one being security. Does PortMaster provide any sand-boxing or analysis for games? If it does not, some bad actor could push compromised binaries without anyone knowing; a compromised device could leak sensitive data (SSH keys, WiFi Access Point passwords...). Even then, handhelds usually have internet access, giving potential attackers full access to LAN, which is something you usually want to avoid.

Additionally, as the number of ports is increasing steadily, this also raises the question of maintainability and reproducible builds. Let's say I want to update the engine for a recently added port, or troubleshoot a game not booting on a given device (by the way, how do we know which games can run or have been tested on a given device?). Looking at a random port https://github.com/PortsMaster/PortMaster-New/blob/main/ports/descent/README.md , I could not find any instruction to build the game or even source location, which basically means that the effort made to get the game to compile has been lost.

Is there anything in place or planned to mitigate these issues? Even requiring a BUILD.md, Dockerfile and hash for binaries could help a lot to get more accessible and reproducible builds.

Thanks anyway for running this project improving the Linux handheld experience!

JeodC commented 8 hours ago

@Cebion and @kloptops can get into more detail, but I can raise a few points to help out.

Port Security

Ports are tested in our Discord server before we merge them. If a pull request doesn't have an accompanied Testing Thread with passing marks, it sits in limbo or gets denied. The same goes for port updates, excluding minor updates like metadata changes. As we're a relatively niche community, we rely on users to report oddities. We have yet to have a security breach, fortunately.

Maintainability & Reproducability

PortMaster is only a few years old, and our standardizations are still changing. There are a lot of old ports that don't measure up to current times, including logging and as you pointed out, build steps. In my case, I try to keep my own ports maintained separately before I submit pull requests to this repository.

Ship of Harkinian is one of the more recent ports that is consistently updated and maintained, since it's one of the most popular.

Dockerfile and hash

We do this stuff as a hobby, so if we lack experience for something that should probably be done to make things easier, it generally doesn't get done.

I hope you're enjoying your handheld! Don't be shy in the Discord. :) Plenty of friendly folks.

Lgt2x commented 6 hours ago

Ports are tested in our Discord server before we merge them. If a pull request doesn't have an accompanied Testing Thread with passing marks, it sits in limbo or gets denied. The same goes for port updates, excluding minor updates like metadata changes. As we're a relatively niche community, we rely on users to report oddities. We have yet to have a security breach, fortunately.

Manual testing cannot ensure that the game has not been tampered with or the lack of a backdoor. Truly open sourcing ports and documenting the build process is the only way to get trust-worthy binaries shipped. The real problem here is that handheld users may download executables that PortMaster maintainers do not have the source for, and did not build themselves.

We do this stuff as a hobby, so if we lack experience for something that should probably be done to make things easier, it generally doesn't get done.

This is also why I'm opening this issue! This problem seems very critical to me for the project in the long run. Raw binaries in a git repository is not manageable at scale, and I'm all in to help improve standards for the ports hosted here.

I hope you're enjoying your handheld! Don't be shy in the Discord. :) Plenty of friendly folks.

As much as I like Discord for certain things, messages tend to get easily lost and buried quickly, so I turned in here to try and get more public attention

JeodC commented 5 hours ago

I mean, it is true that we currently have no methods for verifying, say, libraries bundled with a port. A backdoor would be relatively easy to implement. Again, fortunately, it hasn't been a problem thus far, and, as the community grows, more will take notice and the probability of it increases, especially with recent developments like Valve and Arch Linux.

Regarding open source ports, I'm sure you've seen that not every port we have is OSS. Many, like Descent 3, are just compatibility layers without the game assets.

In terms of solution, we have no solution (yet). It hasn't been a high priority for us. It appears you're working to understand the entire structure of the project in hopes of proposing one or more solutions though, which we do appreciate.