commit bd23fe2d53c026c87b293d3dba789229088a54f3
parent cd222ebdc3a7c227ec1a3a8232c650db8a8e38e5
Author: Cem Keylan <cem@ckyln.com>
Date: Tue, 8 Sep 2020 02:16:40 +0300
update
Diffstat:
8 files changed, 72 insertions(+), 24 deletions(-)
diff --git a/docs/blog/20200908-trust-in-distributed-environments.html b/docs/blog/20200908-trust-in-distributed-environments.html
@@ -76,9 +76,15 @@ 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>I believe that this environment is as trustworthy as it can get, a repository
+system with package build instructions that easy to read and understand, easy to
+history check, easy to limit, and easy to allow. KISS and Carbs Linux have a
+single maintainer. I maintain Carbs and Dylan maintains KISS. You are not
+trusting an organization, you are trusting individuals that you can easily
+converse on the internet. The same goes for most community repository
+maintainers out there. Trying to implement 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>
diff --git a/docs/blog/20200908-trust-in-distributed-environments.txt b/docs/blog/20200908-trust-in-distributed-environments.txt
@@ -35,6 +35,12 @@ 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.
+I believe that this environment is as trustworthy as it can get, a repository
+system with package build instructions that easy to read and understand, easy to
+history check, easy to limit, and easy to allow. KISS and Carbs Linux have a
+single maintainer. I maintain Carbs and Dylan maintains KISS. You are not
+trusting an organization, you are trusting individuals that you can easily
+converse on the internet. The same goes for most community repository
+maintainers out there. Trying to implement 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
@@ -97,9 +97,15 @@ 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>I believe that this environment is as trustworthy as it can get, a repository
+system with package build instructions that easy to read and understand, easy to
+history check, easy to limit, and easy to allow. KISS and Carbs Linux have a
+single maintainer. I maintain Carbs and Dylan maintains KISS. You are not
+trusting an organization, you are trusting individuals that you can easily
+converse on the internet. The same goes for most community repository
+maintainers out there. Trying to implement 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 />
diff --git a/docs/index.txt b/docs/index.txt
@@ -56,9 +56,15 @@ 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.
+I believe that this environment is as trustworthy as it can get, a repository
+system with package build instructions that easy to read and understand, easy to
+history check, easy to limit, and easy to allow. KISS and Carbs Linux have a
+single maintainer. I maintain Carbs and Dylan maintains KISS. You are not
+trusting an organization, you are trusting individuals that you can easily
+converse on the internet. The same goes for most community repository
+maintainers out there. Trying to implement 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/rss.xml b/docs/rss.xml
@@ -51,9 +51,15 @@ 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>
+<p>I believe that this environment is as trustworthy as it can get, a repository
+system with package build instructions that easy to read and understand, easy to
+history check, easy to limit, and easy to allow. KISS and Carbs Linux have a
+single maintainer. I maintain Carbs and Dylan maintains KISS. You are not
+trusting an organization, you are trusting individuals that you can easily
+converse on the internet. The same goes for most community repository
+maintainers out there. Trying to implement 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>
diff --git a/src/blog/20200908-trust-in-distributed-environments.md b/src/blog/20200908-trust-in-distributed-environments.md
@@ -35,6 +35,12 @@ 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.
+I believe that this environment is as trustworthy as it can get, a repository
+system with package build instructions that easy to read and understand, easy to
+history check, easy to limit, and easy to allow. KISS and Carbs Linux have a
+single maintainer. I maintain Carbs and Dylan maintains KISS. You are not
+trusting an organization, you are trusting individuals that you can easily
+converse on the internet. The same goes for most community repository
+maintainers out there. Trying to implement 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
@@ -56,9 +56,15 @@ 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.
+I believe that this environment is as trustworthy as it can get, a repository
+system with package build instructions that easy to read and understand, easy to
+history check, easy to limit, and easy to allow. KISS and Carbs Linux have a
+single maintainer. I maintain Carbs and Dylan maintains KISS. You are not
+trusting an organization, you are trusting individuals that you can easily
+converse on the internet. The same goes for most community repository
+maintainers out there. Trying to implement 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/rss.xml b/src/rss.xml
@@ -51,9 +51,15 @@ 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>
+<p>I believe that this environment is as trustworthy as it can get, a repository
+system with package build instructions that easy to read and understand, easy to
+history check, easy to limit, and easy to allow. KISS and Carbs Linux have a
+single maintainer. I maintain Carbs and Dylan maintains KISS. You are not
+trusting an organization, you are trusting individuals that you can easily
+converse on the internet. The same goes for most community repository
+maintainers out there. Trying to implement 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>
