<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Signatures on rmqa.com</title>
    <link>https://rmqa.com/tags/signatures/</link>
    <description>Recent content in Signatures on rmqa.com</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Wed, 04 Nov 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://rmqa.com/tags/signatures/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>rmqa 0.2 Opens tar.xz and zstd Releases and Verifies Their Signatures</title>
      <link>https://rmqa.com/rmqa-0.2-opens-tar.xz-and-zstd-releases-and-verifies-their-signatures/</link>
      <pubDate>Wed, 04 Nov 2026 00:00:00 +0000</pubDate>
      <guid>https://rmqa.com/rmqa-0.2-opens-tar.xz-and-zstd-releases-and-verifies-their-signatures/</guid>
      <description>&lt;p&gt;rmqa 0.1 couldn&amp;rsquo;t open a large share of the releases people actually publish. cargo-dist, the release tool most Rust projects use, packs every build as &lt;code&gt;.tar.xz&lt;/code&gt;. More C and Rust projects ship &lt;code&gt;.tar.zst&lt;/code&gt; each year. rmqa saw those files, counted their bytes and moved on, so a wrong build inside one went through.&lt;/p&gt;&#xA;&lt;p&gt;0.2 reads both. The xz and zstd readers are rmqa&amp;rsquo;s own, written in Go from the format specifications, so rmqa is still one file with nothing to install beside it. Before trusting them, they were checked against files made by the real tools: xz and zstd at many levels and window sizes, with every kind of built-in check, and damaged copies that must fail. They agreed byte for byte. Each format&amp;rsquo;s own check (CRC32, CRC64 or SHA-256 for xz, the content checksum for zstd) is verified on the way.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
