commit cd222ebdc3a7c227ec1a3a8232c650db8a8e38e5
parent 81afa9f0c9de11d0aed516bd6e63d2257917042d
Author: Cem Keylan <cem@ckyln.com>
Date: Tue, 8 Sep 2020 02:08:29 +0300
update
Diffstat:
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 “trust” 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 “reproducible” 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 “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.</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’s changed/added and what’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 “security theater” 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 “trust” 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 “reproducible” 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 “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.</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’s changed/added and what’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 “security theater” 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><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></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><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></description>
+</item>
<item>
<title>wpa_add script</title>
<pubDate>Fri, 28 Aug 2020</pubDate>
