20200908-trust-in-distributed-environments.txt (2747B)
1 Trust in Distributed Environments 2 ================================================================================ 3 4 A few days ago, in the `#kisslinux` IRC channel, jedahan mentioned an 5 implementation for trust in the package manager. While I was intrigued by the 6 idea initially, I decided not to implement this for the upcoming 4.0.0 release. 7 That is because the package manager and the distribution itself is already 8 centered on trust. However, this idea made me think a lot about "trust" in 9 distributed environments. 10 11 Who and what would you trust? Would you trust Microsoft? Would you trust a 12 binary? Would you only trust a so called "reproducible" build? 13 14 Jedahan mentioned the possibility that a repository maintainer could create a 15 package that would be normally in the distribution so they could mess your 16 system up. He suggested a "source" system where you know where each package 17 comes from. This way the package manager can warn you when the source of a 18 package is changed. As I have said this idea intrigued me at the beginning, but 19 here is why it is complex and unnecessary. 20 21 The package manager would warn you every time you fork a package and apply your 22 changes. Both with kiss and CPT, you already see git logs when the repositories 23 are fetched. Those logs address each and every file that has been edited, added, 24 removed, or renamed. CPT also has support for rsync, which is called verbosely. 25 While not as descriptive, rsync also shows what's changed/added and what's 26 deleted. 27 28 Also, back on April, I have added submodule support to my fork of kiss, which 29 Dylan adapted on May 19. I have added this feature because it solves a similar 30 issue. I want to have only some packages from a repository and leave the rest 31 of them. This way I am the one in control of what goes inside my repositories. 32 33 Minor annoyances aside, would this solve the issue of trust? Maybe this evil 34 repository maintainer decides to botch a package that was already in their 35 repository not provided by your distribution. Should we then track the source 36 files, build files as well? But those change all the time. 37 38 I believe that this environment is as trustworthy as it can get, a repository 39 system with package build instructions that easy to read and understand, easy to 40 history check, easy to limit, and easy to allow. KISS and Carbs Linux have a 41 single maintainer. I maintain Carbs and Dylan maintains KISS. You are not 42 trusting an organization, you are trusting individuals that you can easily 43 converse on the internet. The same goes for most community repository 44 maintainers out there. Trying to implement more would be a "security theater" 45 that would be a hassle for the maintainers, the users and the package manager 46 without a noticeable benefit to any.