diff --git a/public/blog/index.html b/public/blog/index.html index 38170ae..a0551c9 100644 --- a/public/blog/index.html +++ b/public/blog/index.html @@ -319,11 +319,11 @@
-

What should we learn from the XZ situation as Packagers?

 +

What should we learn from the XZ situation as Package Maintainers?
03 April 2024

Context As you probably already know by now, a backdoor/security vulnerability has been recently discovered in xz. In this article, I won’t cover the technical aspect or the potential consequences of it (it has already been done by people way more knowledgeable than am I on that matter) but I will expose what I think we should learn from it from a packaging point of view.

[...]

- Read More + Read More
diff --git a/public/blog/index.xml b/public/blog/index.xml index da05260..3759dc2 100644 --- a/public/blog/index.xml +++ b/public/blog/index.xml @@ -8,11 +8,11 @@ en-us Wed, 03 Apr 2024 14:56:04 +0200 - What should we learn from the XZ situation as Packagers? - https://antiz.fr/blog/what-should-we-learn-from-the-xz-situation-as-packagers/ + What should we learn from the XZ situation as Package Maintainers? + https://antiz.fr/blog/what-should-we-learn-from-the-xz-situation-as-package-maintainers/ Wed, 03 Apr 2024 14:56:04 +0200 - https://antiz.fr/blog/what-should-we-learn-from-the-xz-situation-as-packagers/ + https://antiz.fr/blog/what-should-we-learn-from-the-xz-situation-as-package-maintainers/ Context As you probably already know by now, a backdoor/security vulnerability has been recently discovered in xz. In this article, I won’t cover the technical aspect or the potential consequences of it (it has already been done by people way more knowledgeable than am I on that matter) but I will expose what I think we should learn from it from a packaging point of view. diff --git a/public/blog/what-should-we-learn-from-the-xz-situation-as-packagers/index.html b/public/blog/what-should-we-learn-from-the-xz-situation-as-package-maintainers/index.html similarity index 85% rename from public/blog/what-should-we-learn-from-the-xz-situation-as-packagers/index.html rename to public/blog/what-should-we-learn-from-the-xz-situation-as-package-maintainers/index.html index 1e091e2..f86c2bb 100644 --- a/public/blog/what-should-we-learn-from-the-xz-situation-as-packagers/index.html +++ b/public/blog/what-should-we-learn-from-the-xz-situation-as-package-maintainers/index.html @@ -10,7 +10,7 @@ Robin Candau | - What should we learn from the XZ situation as Packagers? + What should we learn from the XZ situation as Package Maintainers? @@ -94,7 +94,7 @@ <link rel="icon" type="image/png" sizes="32x32" href="/favicon-32x32.png" /> <link rel="icon" type="image/png" sizes="16x16" href="/favicon-16x16.png" /> - <link rel="canonical" href="https://antiz.fr/blog/what-should-we-learn-from-the-xz-situation-as-packagers/" /> + <link rel="canonical" href="https://antiz.fr/blog/what-should-we-learn-from-the-xz-situation-as-package-maintainers/" /> @@ -122,16 +122,16 @@ - <meta name="twitter:card" content="summary"/><meta name="twitter:title" content="What should we learn from the XZ situation as Packagers?"/> + <meta name="twitter:card" content="summary"/><meta name="twitter:title" content="What should we learn from the XZ situation as Package Maintainers?"/> <meta name="twitter:description" content="Context As you probably already know by now, a backdoor/security vulnerability has been recently discovered in xz. In this article, I won’t cover the technical aspect or the potential consequences of it (it has already been done by people way more knowledgeable than am I on that matter) but I will expose what I think we should learn from it from a packaging point of view."/> - <meta property="og:title" content="What should we learn from the XZ situation as Packagers?" /> + <meta property="og:title" content="What should we learn from the XZ situation as Package Maintainers?" /> <meta property="og:description" content="Context As you probably already know by now, a backdoor/security vulnerability has been recently discovered in xz. In this article, I won’t cover the technical aspect or the potential consequences of it (it has already been done by people way more knowledgeable than am I on that matter) but I will expose what I think we should learn from it from a packaging point of view." /> <meta property="og:type" content="article" /> -<meta property="og:url" content="https://antiz.fr/blog/what-should-we-learn-from-the-xz-situation-as-packagers/" /><meta property="article:section" content="blog" /> +<meta property="og:url" content="https://antiz.fr/blog/what-should-we-learn-from-the-xz-situation-as-package-maintainers/" /><meta property="article:section" content="blog" /> <meta property="article:published_time" content="2024-04-03T14:56:04+02:00" /> <meta property="article:modified_time" content="2024-04-03T14:56:04+02:00" /><meta property="og:site_name" content="Robin Candau" /> @@ -146,8 +146,8 @@ "@context": "http://schema.org", "@type": "BlogPosting", "articleSection": "blog", - "name": "What should we learn from the XZ situation as Packagers?", - "headline": "What should we learn from the XZ situation as Packagers?", + "name": "What should we learn from the XZ situation as Package Maintainers?", + "headline": "What should we learn from the XZ situation as Package Maintainers?", "alternativeHeadline": "", "description": " @@ -162,7 +162,7 @@ "isFamilyFriendly": "true", "mainEntityOfPage": { "@type": "WebPage", - "@id": "https:\/\/antiz.fr\/blog\/what-should-we-learn-from-the-xz-situation-as-packagers\/" + "@id": "https:\/\/antiz.fr\/blog\/what-should-we-learn-from-the-xz-situation-as-package-maintainers\/" }, "author" : { "@type": "Person", @@ -200,8 +200,8 @@ ] , - "url" : "https:\/\/antiz.fr\/blog\/what-should-we-learn-from-the-xz-situation-as-packagers\/", - "wordCount" : "1222", + "url" : "https:\/\/antiz.fr\/blog\/what-should-we-learn-from-the-xz-situation-as-package-maintainers\/", + "wordCount" : "1231", "genre" : [ ], "keywords" : [ ] } @@ -384,7 +384,7 @@ > <div class="post__content"> - <h1>What Should We Learn From the XZ Situation as Packagers?</h1> + <h1>What Should We Learn From the XZ Situation as Package Maintainers?</h1> <ul class="post__meta"> <li class="post__meta-item"> @@ -405,24 +405,24 @@ <h1>What Should We Learn From the XZ Situation as Packagers?</h1> </ul> <h2 id="context">Context</h2> <p>As you probably already know by now, a backdoor/security vulnerability has been <a href="https://www.openwall.com/lists/oss-security/2024/03/29/4">recently discovered in xz</a>. In this article, I won’t cover the technical aspect or the potential consequences of it (it has already been done by people way more knowledgeable than am I on that matter) but I will expose what I think we should learn from it from a packaging point of view.</p> -<p>To sum up the situation briefly (as a context for the rest of this article), the xz (co-)maintainer himself introduced a <a href="https://en.wikipedia.org/wiki/Backdoor_(computing)">backdoor</a> in the code, obfuscated by the fact that the malicious code (or at least parts of it) was only present in the <em>custom</em> made tarball (basically an archive) of the sources (but not present in the git repo itself). The said tarball/archive was signed with his GPG key and manually uploaded as an asset/artifact of the releases, which packagers used a source for their package.</p> +<p>To sum up the situation briefly (as a context for the rest of this article), the xz (co-)maintainer himself introduced a <a href="https://en.wikipedia.org/wiki/Backdoor_(computing)">backdoor</a> in the code, obfuscated by the fact that the malicious code (or at least parts of it) was only present in the <em>custom</em> made tarball (basically an archive) of the sources (but not present in the git repo itself). The said tarball/archive was signed with his GPG key and manually uploaded as an asset/artifact of the releases, which package maintainers used a source for their package.</p> <h2 id="why-relying-on-a-custom-made-tarball-of-the-sources-over-the-sources-themselves-in-the-first-place">Why relying on a custom made tarball of the sources over the sources themselves in the first place?</h2> -<p>Firstly, depending on how a software is developed and what it relies/depends on, the <em>raw</em> sources might not be usable <em>as is</em> (sometimes at all). It happens that some software’s sources require additional steps/pre-configuration in order to be properly compiled and packaged (for instance projects that relies on <a href="https://en.wikipedia.org/wiki/GNU_Autotools">autotools</a> or <a href="https://git-scm.com/book/en/v2/Git-Tools-Submodules">git submodules</a> to configure sources or pull required third party dependencies). As a matter of convenience, it is quite common that upstream developers provide custom made tarballs of the sources of their software with those pre-required additional steps already done, allowing packagers to get sources usable as is.</p> -<p>The other reason why packagers often rely on such custom made tarballs over “raw” sources is because it’s quite common for upstream developers to not <del>bother integrating</del> integrate <a href="https://www.gnupg.org/gph/en/manual/x135.html">GPG signing</a> in their development and release workflows (basically sign their commits and tags) but only sign these custom made tarballs instead (probably as a way to “promote” it over raw sources regarding the previous point about convenience). A GPG signed source tarball represents an additional level of trust for packagers as it constitutes a reliable way to proves the identity of the person that generated/made the said tarball, but also that it hasn’t been modified in any way after being signed.</p> -<h2 id="as-packagers-should-we-prefer-a-more-transparent-source-over-a-convenient-one">As packagers, should we prefer a more transparent source over a convenient one?</h2> -<p>While these custom made tarballs are often more convenient for us packagers (as explained above), they are also less transparent by nature. Indeed, it’s way more involved and difficult to have a tarball being reliably reviewed and audited compared to a publicly and easily accessible git repo hosted online. And identifying differences in the content of the tarball compared to the content of the “raw” sources on its own is not enough as this is often actually expected (since these custom made tarballs are expected to include the prerequisites needed to properly compile/package the software compared to the “raw” sources).</p> +<p>Firstly, depending on how a software is developed and what it relies/depends on, the <em>raw</em> sources might not be usable <em>as is</em> (sometimes at all). It happens that some software’s sources require additional steps/pre-configuration in order to be properly compiled and packaged (for instance projects that relies on <a href="https://en.wikipedia.org/wiki/GNU_Autotools">autotools</a> or <a href="https://git-scm.com/book/en/v2/Git-Tools-Submodules">git submodules</a> to configure sources or pull required third party dependencies). As a matter of convenience, it is quite common that upstream developers provide custom made tarballs of the sources of their software with those pre-required additional steps already done, allowing package maintainers to get sources usable as is.</p> +<p>The other reason why package maintainers often rely on such custom made tarballs over “raw” sources is because it’s quite common for upstream developers to not <del>bother integrating</del> integrate <a href="https://www.gnupg.org/gph/en/manual/x135.html">GPG signing</a> in their development and release workflows (basically sign their commits and tags) but only sign these custom made tarballs instead (probably as a way to “promote” it over raw sources regarding the previous point about convenience). A GPG signed source tarball represents an additional level of trust for package maintainers as it constitutes a reliable way to proves the identity of the person that generated/made the said tarball, but also that it hasn’t been modified in any way after being signed.</p> +<h2 id="as-package-maintainers-should-we-prefer-a-more-transparent-source-over-a-convenient-one">As package maintainers, should we prefer a more transparent source over a convenient one?</h2> +<p>While these custom made tarballs are often more convenient for us package maintainers (as explained above), they are also less transparent by nature. Indeed, it’s way more involved and difficult to have a tarball being reliably reviewed and audited compared to a publicly and easily accessible git repo hosted online. And identifying differences in the content of the tarball compared to the content of the “raw” sources on its own is not enough as this is often actually expected (since these custom made tarballs are expected to include the prerequisites needed to properly compile/package the software compared to the “raw” sources).</p> <p>It’s undeniable that if the xz malicious code was present in the “raw” sources themselves, it would have been detected way faster and more easily (which is why it was only injected in the custom made tarball as the way to obfuscate it). My personal take on that is, <em>when possible,</em> we should prefer using a more transparent source (over a more convenient one) that is, by cascade, more audited and thus eventually more trustworthy.</p> <h2 id="what-about-the-gpg-signature-though">What about the GPG signature, though?</h2> -<p>As said previously in this article, it’s <em>unfortunately</em> quite common that upstream developers only sign such custom made tarballs and not commits/tags on the git sources themselves (which is one of the reason packagers choose to base their packages on them).</p> +<p>As said previously in this article, it’s <em>unfortunately</em> quite common that upstream developers only sign such custom made tarballs and not commits/tags on the git sources themselves (which is one of the reason package maintainers choose to base their packages on them).</p> <p>However, as said in the <a href="#context">first chapter</a> of this article, it’s important to remind that the <em>infected</em> xz tarball <strong>was signed</strong> with the GPG of the (co-)maintainer of the project himself (who also introduced the backdoor). That raise an important question: To which degree we want to trust a GPG signature over anything else (in this particular case, over a more transparent source)?</p> <p>While the signature on its own indeed proved the identity of the person that created the tarball (and that it has not been altered since it got signed), it does not guarantee <strong>anything</strong> about the content of the archive in the first place (so not that nothing malicious or not trustworthy has been injected in it when created, as the xz situation demonstrated)! When the people themselves are compromised, the signatures worth nothing.</p> -<p>My personal opinion is that, while a GPG signature is an important and valuable addition to the “<a href="https://en.wikipedia.org/wiki/Trusted_path">trust path</a>” upstream developers are building towards users/packagers, a transparent source (that do not require any additional effort to be proven reliable/trustworthy when compared to “raw” sources) outweighs it.</p> +<p>My personal opinion is that, while a GPG signature is an important and valuable addition to the “<a href="https://en.wikipedia.org/wiki/Trusted_path">trust path</a>” upstream developers are building towards users/package maintainers, a transparent source (that do not require any additional effort to be proven reliable/trustworthy when compared to “raw” sources) outweighs it.</p> <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 itself the code is hosted on (which is a snapshot of the exact state of the repo itself at the precise moment the tag was created) or to the git sources themselves directly (by cloning the repo against the specific tag I want to package).</p> <p>With the recent xz situation, I do 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>Together with David Runge (an Arch Linux Developer), we also decided to jointly write two RFCs (namely about “how to deal with sources in our packages?” and “how to deal with signed sources and trust path?”) to try to establish general guidelines on those matters on Arch Linux side <em>(I’ll update this part with the links to those RFCs once they have been written and published)</em>.</p> <h2 id="this-is-not-only-a-downstreampackaging-matter-but-also-an-upstream-one">This is not only a downstream/packaging matter but also an upstream one</h2> -<p>While packagers can make changes on their sides to bring more transparency into the 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>While package maintainers can make changes on their sides to bring more transparency into the 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 auto-generated source tarballs + GPG signatures or signed tags (+ eventual addition trust path) are viable.</p> <p>So, for eventual upstream developers passing by, if you don’t already, please (🥺) consider starting to sign your tags/auto-generated source tarballs and provide information about additional steps that may be required to make your sources usable (if needed and if possible, obviously).<br> <em>(I’ll start doing it myself for the few projects I’m developing).</em> 😀</p> diff --git a/public/index.xml b/public/index.xml index 493340d..c2e1476 100644 --- a/public/index.xml +++ b/public/index.xml @@ -8,11 +8,11 @@ <language>en-us</language> <lastBuildDate>Thu, 16 Feb 2023 13:11:49 +0100</lastBuildDate><atom:link href="https://antiz.fr/index.xml" rel="self" type="application/rss+xml" /> <item> - <title>What should we learn from the XZ situation as Packagers? - https://antiz.fr/blog/what-should-we-learn-from-the-xz-situation-as-packagers/ + What should we learn from the XZ situation as Package Maintainers? + https://antiz.fr/blog/what-should-we-learn-from-the-xz-situation-as-package-maintainers/ Wed, 03 Apr 2024 14:56:04 +0200 - https://antiz.fr/blog/what-should-we-learn-from-the-xz-situation-as-packagers/ + https://antiz.fr/blog/what-should-we-learn-from-the-xz-situation-as-package-maintainers/ Context As you probably already know by now, a backdoor/security vulnerability has been recently discovered in xz. In this article, I won’t cover the technical aspect or the potential consequences of it (it has already been done by people way more knowledgeable than am I on that matter) but I will expose what I think we should learn from it from a packaging point of view. diff --git a/public/sitemap.xml b/public/sitemap.xml index be2205d..9ea3763 100644 --- a/public/sitemap.xml +++ b/public/sitemap.xml @@ -5,7 +5,7 @@ https://antiz.fr/blog/ 2024-04-03T14:56:04+02:00 - https://antiz.fr/blog/what-should-we-learn-from-the-xz-situation-as-packagers/ + https://antiz.fr/blog/what-should-we-learn-from-the-xz-situation-as-package-maintainers/ 2024-04-03T14:56:04+02:00 https://antiz.fr/blog/raspberry-pi-wake-on-lan-server/