website

My personal website
git clone git://git.ckyln.com/website
Log | Files | Refs

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.