Automated build

public/blog/what-should-we-learn-from-the-xz-situation-as-package-maintainers/index.html

@@ -208,7 +208,7 @@
 
     ,
         "url" : "https:\/\/antiz.fr\/blog\/what-should-we-learn-from-the-xz-situation-as-package-maintainers\/",
-        "wordCount" : "1302",
+        "wordCount" : "1277",
         "genre" : [ ],
         "keywords" : [ ]
     }
@@ -428,7 +428,7 @@ <h1>What Should We Learn From the XZ Situation as Package Maintainers?</h1>
           </li>
           <li class="post__meta-item">
             <em class="fas fa-stopwatch post__meta-icon"></em>
-            <span class="post__meta-text">7-minute read</span>
+            <span class="post__meta-text">6-minute read</span>
           </li>
         </ul>
       <h2 id="context">Context</h2>
@@ -449,7 +449,7 @@ <h2 id="what-about-the-gpg-signature-though">What about the GPG signature, thoug
 <h2 id="so-what-action-will-i-take-on-my-side">So, what action will I take on my side?</h2>
 <p>I already started the effort of switching the source of the packages I maintain on Arch Linux side that are currently based on such custom made tarballs to either the auto-generated tarball made by the git platform the code is hosted on, or to the git sources themselves directly (hopefully not at the expense of a GPG signature but I will <em>probably</em> do it if there&rsquo;s no other choice).</p>
 <p>With the recent xz situation, I think that basing our packages on a more transparent source, at the potential cost of <a href="https://gitlab.archlinux.org/archlinux/packaging/packages/mupdf/-/commit/9e7f9c55b141833762d7951b81c0a574aa9353d9">more complex</a> packages to maintain (as the eventual pre-required steps needed for the source to be usable in the first place would now be on our side) is worth the price.</p>
-<p>Additionally, together with David Runge (Arch Linux Developer), we decided to jointly write an RFC (namely about “how to deal with sources in our packages?”) as a trial / suggestion to establish general guidelines on those matters on Arch Linux side <em>(I’ll update this part of the article with the links to those RFCs once they have been written and published)</em>.</p>
+<p>Additionally, together with David Runge (an Arch Linux Developer), we decided to jointly write <a href="https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/46">an RFC</a> which aims to establish some standards regarding the way we deal with our package sources and digital signatures for them.</p>
 <h2 id="this-is-not-only-a-downstream--packaging-matter-but-also-an-upstream-one">This is not only a downstream / packaging matter but also an upstream one</h2>
 <p>While package maintainers can make changes on their sides to bring more transparency into their packages and <em>mitigate</em> eventual issues, it’s in my opinion very important that all of this turns into a common effort in which upstream developers adapt their development and release workflow to provide transparent sources / artifacts without skimping on the “trust path” they provide with it.</p>
 <p>Ideally, such questions as “should I prefer a signed source or a transparent one?” shouldn’t be a thing anymore. Realistically, only signed VCS objects (e.g. commits or tags) or signed auto-generated source tarballs accompanied by a trust path are viable.</p>