website

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

20200908-trust-in-distributed-environments.html (4279B)

      1 <!DOCTYPE HTML>
      2 <html lan=en>
      3   <head>
      4     <title>Trust in Distributed Environments | Cem's Website</title>
      5     <meta charset="utf-8">
      6     <meta name="Description" content="Cem Keylan's Website">
      7     <meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no">
      8     <style>
      9       html {font-family:monospace;font-size:16px;color:#282a36;}
     10       body {
     11 	  width: 90%;
     12 	  max-width: 1050px;
     13 	  margin-left: auto;
     14 	  margin-right: auto;
     15 	  margin-top: 20px;
     16 	  overflow: none;
     17           overflow-y: scroll;
     18 	  padding-right: 10px;
     19 	  padding-left: 10px;
     20       }
     21       a{text-decoration:none;font-weight:bold;color:#282a36;}
     22       a:hover{text-decoration:underline;}
     23       @media (prefers-color-scheme: dark) {
     24           html {color: white;background:#282a36;}
     25           a{color:white;}
     26       }
     27     </style>
     28     <link rel="stylesheet" href="/static/syntax.css">
     29     <script src="/static/highlight.pack.js"></script>
     30     <script>hljs.initHighlightingOnLoad();</script>
     31   </head>
     32   <body>
     33     <div class="header">
     34       <nav>
     35         <a href='/'>index</a> |
     36         <a href="/software.html">software</a> |
     37         <a href="/blog.html">blog</a> |
     38         <a href="/contact.html">contact</a> |
     39         <a href="/sysmgr">sysmgr</a> |
     40       </nav>
     41     </div>
     42     <hr>
     43     <p>
     44 <h1>Trust in Distributed Environments</h1>
     45 
     46 <p>A few days ago, in the <code>#kisslinux</code> IRC channel, jedahan mentioned an
     47 implementation for trust in the package manager. While I was intrigued by the
     48 idea initially, I decided not to implement this for the upcoming 4.0.0 release.
     49 That is because the package manager and the distribution itself is already
     50 centered on trust. However, this idea made me think a lot about &ldquo;trust&rdquo; in
     51 distributed environments.</p>
     52 
     53 <p>Who and what would you trust? Would you trust Microsoft? Would you trust a
     54 binary? Would you only trust a so called &ldquo;reproducible&rdquo; build?</p>
     55 
     56 <p>Jedahan mentioned the possibility that a repository maintainer could create a
     57 package that would be normally in the distribution so they could mess your
     58 system up. He suggested a &ldquo;source&rdquo; system where you know where each package
     59 comes from. This way the package manager can warn you when the source of a
     60 package is changed. As I have said this idea intrigued me at the beginning, but
     61 here is why it is complex and unnecessary.</p>
     62 
     63 <p>The package manager would warn you every time you fork a package and apply your
     64 changes. Both with kiss and CPT, you already see git logs when the repositories
     65 are fetched. Those logs address each and every file that has been edited, added,
     66 removed, or renamed. CPT also has support for rsync, which is called verbosely.
     67 While not as descriptive, rsync also shows what&rsquo;s changed/added and what&rsquo;s
     68 deleted.</p>
     69 
     70 <p>Also, back on April, I have added submodule support to my fork of kiss, which
     71 Dylan adapted on May 19. I have added this feature because it solves a similar
     72 issue. I want to have only some packages from a repository and leave the rest
     73 of them. This way I am the one in control of what goes inside my repositories.</p>
     74 
     75 <p>Minor annoyances aside, would this solve the issue of trust? Maybe this evil
     76 repository maintainer decides to botch a package that was already in their
     77 repository not provided by your distribution. Should we then track the source
     78 files, build files as well? But those change all the time.</p>
     79 
     80 <p>I believe that this environment is as trustworthy as it can get, a repository
     81 system with package build instructions that easy to read and understand, easy to
     82 history check, easy to limit, and easy to allow. KISS and Carbs Linux have a
     83 single maintainer. I maintain Carbs and Dylan maintains KISS. You are not
     84 trusting an organization, you are trusting individuals that you can easily
     85 converse on the internet. The same goes for most community repository
     86 maintainers out there. Trying to implement more would be a &ldquo;security theater&rdquo;
     87 that would be a hassle for the maintainers, the users and the package manager
     88 without a noticeable benefit to any.</p>
     89     </p>
     90     <a href="/blog/20200908-trust-in-distributed-environments.txt">This page in plain-text</a>
     91     <hr>
     92     <p class=footer>Copyright &copy; 2019-2021 Cem Keylan</p>
     93   </body>
     94 </html>