website

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

commit cd222ebdc3a7c227ec1a3a8232c650db8a8e38e5
parent 81afa9f0c9de11d0aed516bd6e63d2257917042d
Author: Cem Keylan <cem@ckyln.com>
Date:   Tue,  8 Sep 2020 02:08:29 +0300

update

Diffstat:
Mdocs/blog.html | 1+
Mdocs/blog.txt | 1+
Adocs/blog/20200908-trust-in-distributed-environments.html | 87+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adocs/blog/20200908-trust-in-distributed-environments.txt | 40++++++++++++++++++++++++++++++++++++++++
Mdocs/index.html | 46++++++++++++++++++++++++++++++++++++++++++++++
Mdocs/index.txt | 47+++++++++++++++++++++++++++++++++++++++++++++++
Mdocs/rss.xml | 47++++++++++++++++++++++++++++++++++++++++++++++-
Msrc/blog.md | 1+
Asrc/blog/20200908-trust-in-distributed-environments.md | 40++++++++++++++++++++++++++++++++++++++++
Msrc/index.md | 47+++++++++++++++++++++++++++++++++++++++++++++++
Msrc/rss.xml | 47++++++++++++++++++++++++++++++++++++++++++++++-
11 files changed, 402 insertions(+), 2 deletions(-)

diff --git a/docs/blog.html b/docs/blog.html @@ -43,6 +43,7 @@ <h2>Blog Index</h2> <ul> +<li>Sep 08 2020 - <a href="/blog/20200908-trust-in-distributed-environments.html">Trust in Distributed Environments</a></li> <li>Aug 28 2020 - <a href="/blog/20200828-wpa-add-script.html">wpa_add script</a></li> <li>Aug 28 2020 - <a href="/blog/20200828-static-linking.html">Static linking</a></li> <li>Aug 12 2020 - <a href="/blog/20200812-starting-x-without-xinit.html">Starting X without Xinit</a></li> diff --git a/docs/blog.txt b/docs/blog.txt @@ -1,6 +1,7 @@ Blog Index -------------------------------------------------------------------------------- +* Sep 08 2020 - [Trust in Distributed Environments](/blog/20200908-trust-in-distributed-environments.html) * Aug 28 2020 - [wpa_add script](/blog/20200828-wpa-add-script.html) * Aug 28 2020 - [Static linking](/blog/20200828-static-linking.html) * Aug 12 2020 - [Starting X without Xinit](/blog/20200812-starting-x-without-xinit.html) diff --git a/docs/blog/20200908-trust-in-distributed-environments.html b/docs/blog/20200908-trust-in-distributed-environments.html @@ -0,0 +1,87 @@ +<!DOCTYPE HTML> +<html lan=en> + <head> + <title>Trust in Distributed Environments | Cem's Website</title> + <meta charset="utf-8"> + <meta name="Description" content="Cem Keylan's Website"> + <meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no"> + <style> + html {font-family:monospace;font-size:16px;color:#282a36;} + body { + width: 90%; + max-width: 1050px; + margin-left: auto; + margin-right: auto; + margin-top: 20px; + overflow: none; + overflow-y: scroll; + padding-right: 10px; + padding-left: 10px; + } + a{text-decoration:none;font-weight:bold;color:#282a36;} + a:hover{text-decoration:underline;} + @media (prefers-color-scheme: dark) { + html {color: white;background:#282a36;} + a{color:white;} + } + </style> + <link rel="stylesheet" href="/static/syntax.css"> + <script src="/static/highlight.pack.js"></script> + <script>hljs.initHighlightingOnLoad();</script> + </head> + <body> + <div class="header"> + <nav> + <a href='/'>index</a> | + <a href="/software.html">software</a> | + <a href="/blog.html">blog</a> | + <a href="/contact.html">contact</a> | + </nav> + </div> + <hr> + <p> +<h1>Trust in Distributed Environments</h1> + +<p>A few days ago, in the <code>#kisslinux</code> 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 &ldquo;trust&rdquo; in +distributed environments.</p> + +<p>Who and what would you trust? Would you trust Microsoft? Would you trust a +binary? Would you only trust a so called &ldquo;reproducible&rdquo; build?</p> + +<p>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 &ldquo;source&rdquo; 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.</p> + +<p>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&rsquo;s changed/added and what&rsquo;s +deleted.</p> + +<p>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.</p> + +<p>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.</p> + +<p>I believe that this environment is as trustworthy as it can get, more would +be a &ldquo;security theater&rdquo; that would be a hassle for the maintainers, the users +and the package manager without a noticeable benefit to any.</p> + </p> + <a href="/blog/20200908-trust-in-distributed-environments.txt">This page in plain-text</a> + <hr> + <p class=footer>Copyright © 2019-2020 Cem Keylan</p> + </body> +</html> diff --git a/docs/blog/20200908-trust-in-distributed-environments.txt b/docs/blog/20200908-trust-in-distributed-environments.txt @@ -0,0 +1,40 @@ +Trust in Distributed Environments +================================================================================ + +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, 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. diff --git a/docs/index.html b/docs/index.html @@ -57,6 +57,52 @@ able to view this site in your favourite pager! In your terminal simply type:</p <hr /> +<h1>Trust in Distributed Environments</h1> + +<p><a href="/blog/20200908-trust-in-distributed-environments.html">Permalink</a></p> + +<p>Date: Sep 08 2020</p> + +<p>A few days ago, in the <code>#kisslinux</code> 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 &ldquo;trust&rdquo; in +distributed environments.</p> + +<p>Who and what would you trust? Would you trust Microsoft? Would you trust a +binary? Would you only trust a so called &ldquo;reproducible&rdquo; build?</p> + +<p>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 &ldquo;source&rdquo; 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.</p> + +<p>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&rsquo;s changed/added and what&rsquo;s +deleted.</p> + +<p>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.</p> + +<p>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.</p> + +<p>I believe that this environment is as trustworthy as it can get, more would +be a &ldquo;security theater&rdquo; that would be a hassle for the maintainers, the users +and the package manager without a noticeable benefit to any.</p> + +<hr /> + <h1>wpa_add script</h1> <p><a href="/blog/20200828-wpa-add-script.html">Permalink</a></p> diff --git a/docs/index.txt b/docs/index.txt @@ -15,6 +15,53 @@ able to view this site in your favourite pager! In your terminal simply type: ******************************************************************************** +Trust in Distributed Environments +================================================================================ +[Permalink](/blog/20200908-trust-in-distributed-environments.html) + +Date: Sep 08 2020 + + +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, 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. + +******************************************************************************** + wpa_add script ================================================================================ [Permalink](/blog/20200828-wpa-add-script.html) diff --git a/docs/rss.xml b/docs/rss.xml @@ -9,7 +9,52 @@ <description>Personal blog/website on Linux/tech/nerdy stuff</description> <link>https://cemkeylan.com</link> <atom:link href="https://cemkeylan.com/rss.xml" rel="self" type="application/rss+xml" /> - <lastBuildDate>Fri Aug 28 2020 22:00</lastBuildDate> + <lastBuildDate>Mon Sep 07 2020 23:00</lastBuildDate> +<item> +<title>Trust in Distributed Environments</title> +<pubDate>Tue, 08 Sep 2020</pubDate> +<dc:creator>Cem Keylan</dc:creator> +<link>https://cemkeylan.com/blog/20200908-trust-in-distributed-environments.html</link> +<description>&lt;h1&gt;Trust in Distributed Environments&lt;/h1&gt; + +&lt;p&gt;A few days ago, in the &lt;code&gt;#kisslinux&lt;/code&gt; 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 &amp;ldquo;trust&amp;rdquo; in +distributed environments.&lt;/p&gt; + +&lt;p&gt;Who and what would you trust? Would you trust Microsoft? Would you trust a +binary? Would you only trust a so called &amp;ldquo;reproducible&amp;rdquo; build?&lt;/p&gt; + +&lt;p&gt;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 &amp;ldquo;source&amp;rdquo; 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.&lt;/p&gt; + +&lt;p&gt;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&amp;rsquo;s changed/added and what&amp;rsquo;s +deleted.&lt;/p&gt; + +&lt;p&gt;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.&lt;/p&gt; + +&lt;p&gt;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.&lt;/p&gt; + +&lt;p&gt;I believe that this environment is as trustworthy as it can get, more would +be a &amp;ldquo;security theater&amp;rdquo; that would be a hassle for the maintainers, the users +and the package manager without a noticeable benefit to any.&lt;/p&gt;</description> +</item> <item> <title>wpa_add script</title> <pubDate>Fri, 28 Aug 2020</pubDate> diff --git a/src/blog.md b/src/blog.md @@ -1,6 +1,7 @@ Blog Index -------------------------------------------------------------------------------- +* Sep 08 2020 - [Trust in Distributed Environments](/blog/20200908-trust-in-distributed-environments.html) * Aug 28 2020 - [wpa_add script](/blog/20200828-wpa-add-script.html) * Aug 28 2020 - [Static linking](/blog/20200828-static-linking.html) * Aug 12 2020 - [Starting X without Xinit](/blog/20200812-starting-x-without-xinit.html) diff --git a/src/blog/20200908-trust-in-distributed-environments.md b/src/blog/20200908-trust-in-distributed-environments.md @@ -0,0 +1,40 @@ +Trust in Distributed Environments +================================================================================ + +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, 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. diff --git a/src/index.md b/src/index.md @@ -15,6 +15,53 @@ able to view this site in your favourite pager! In your terminal simply type: ******************************************************************************** +Trust in Distributed Environments +================================================================================ +[Permalink](/blog/20200908-trust-in-distributed-environments.html) + +Date: Sep 08 2020 + + +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, 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. + +******************************************************************************** + wpa_add script ================================================================================ [Permalink](/blog/20200828-wpa-add-script.html) diff --git a/src/rss.xml b/src/rss.xml @@ -9,7 +9,52 @@ <description>Personal blog/website on Linux/tech/nerdy stuff</description> <link>https://cemkeylan.com</link> <atom:link href="https://cemkeylan.com/rss.xml" rel="self" type="application/rss+xml" /> - <lastBuildDate>Fri Aug 28 2020 22:00</lastBuildDate> + <lastBuildDate>Mon Sep 07 2020 23:00</lastBuildDate> +<item> +<title>Trust in Distributed Environments</title> +<pubDate>Tue, 08 Sep 2020</pubDate> +<dc:creator>Cem Keylan</dc:creator> +<link>https://cemkeylan.com/blog/20200908-trust-in-distributed-environments.html</link> +<description>&lt;h1&gt;Trust in Distributed Environments&lt;/h1&gt; + +&lt;p&gt;A few days ago, in the &lt;code&gt;#kisslinux&lt;/code&gt; 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 &amp;ldquo;trust&amp;rdquo; in +distributed environments.&lt;/p&gt; + +&lt;p&gt;Who and what would you trust? Would you trust Microsoft? Would you trust a +binary? Would you only trust a so called &amp;ldquo;reproducible&amp;rdquo; build?&lt;/p&gt; + +&lt;p&gt;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 &amp;ldquo;source&amp;rdquo; 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.&lt;/p&gt; + +&lt;p&gt;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&amp;rsquo;s changed/added and what&amp;rsquo;s +deleted.&lt;/p&gt; + +&lt;p&gt;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.&lt;/p&gt; + +&lt;p&gt;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.&lt;/p&gt; + +&lt;p&gt;I believe that this environment is as trustworthy as it can get, more would +be a &amp;ldquo;security theater&amp;rdquo; that would be a hassle for the maintainers, the users +and the package manager without a noticeable benefit to any.&lt;/p&gt;</description> +</item> <item> <title>wpa_add script</title> <pubDate>Fri, 28 Aug 2020</pubDate>