A few days ago, in the #kisslinux IRC channel, jedahan mentioned an
implementation for trust in the package manager. While I was intrigued by the
idea initially, I decided not to implement this for the upcoming 4.0.0 release.
That is because the package manager and the distribution itself is already
centered on trust. However, this idea made me think a lot about “trust” in
distributed environments.
Who and what would you trust? Would you trust Microsoft? Would you trust a binary? Would you only trust a so called “reproducible” build?
Jedahan mentioned the possibility that a repository maintainer could create a package that would be normally in the distribution so they could mess your system up. He suggested a “source” system where you know where each package comes from. This way the package manager can warn you when the source of a package is changed. As I have said this idea intrigued me at the beginning, but here is why it is complex and unnecessary.
The package manager would warn you every time you fork a package and apply your changes. Both with kiss and CPT, you already see git logs when the repositories are fetched. Those logs address each and every file that has been edited, added, removed, or renamed. CPT also has support for rsync, which is called verbosely. While not as descriptive, rsync also shows what’s changed/added and what’s deleted.
Also, back on April, I have added submodule support to my fork of kiss, which Dylan adapted on May 19. I have added this feature because it solves a similar issue. I want to have only some packages from a repository and leave the rest of them. This way I am the one in control of what goes inside my repositories.
Minor annoyances aside, would this solve the issue of trust? Maybe this evil repository maintainer decides to botch a package that was already in their repository not provided by your distribution. Should we then track the source files, build files as well? But those change all the time.
I believe that this environment is as trustworthy as it can get, a repository system with package build instructions that easy to read and understand, easy to history check, easy to limit, and easy to allow. KISS and Carbs Linux have a single maintainer. I maintain Carbs and Dylan maintains KISS. You are not trusting an organization, you are trusting individuals that you can easily converse on the internet. The same goes for most community repository maintainers out there. Trying to implement more would be a “security theater” that would be a hassle for the maintainers, the users and the package manager without a noticeable benefit to any.
This page in plain-text