Changeset 6333296

Timestamp:

07/22/2021 11:59:42 AM (23 months ago)

Author:

Xi Ruoyao <xry111@…>

Branches:

11.0, 11.1, 11.2, 11.3, ken/inkscape-core-mods, lazarus, plabs/python-mods, qt5new, trunk, upgradedb, xry111/intltool, xry111/soup3, xry111/test-20220226

Children:

74d0fc8f

Parents:

f70acb8

Message:

building notes: stop to use MD5 for genuity verification, ...

use SHA256 or GnuPG instead.

File:

• introduction/important/building-notes.xml (modified) (2 diffs)

introduction/important/building-notes.xml

@@ -91 +91 @@
 
   <sect2>
-    <title>Verifying File Integrity Using 'md5sum'</title>
-
-    <para>Generally, to verify that the downloaded file is genuine and complete,
+    <title>Verifying File Integrity</title>
+
+    <para>Generally, to verify that the downloaded file is complete,
     many package maintainers also distribute md5sums of the files. To verify the
     md5sum of the downloaded files, download both the file and the
@@ -111 +111 @@
 
 <screen><userinput>md5sum <replaceable>&lt;name_of_downloaded_file&gt;</replaceable></userinput></screen>
+
+    <para>MD5 is not cryptographically secure, so the md5sums are only
+    provided for detecting random errors or truncations introduced during
+    network transfer.  There is no <quote>100%</quote> secure way to make
+    sure the genuity of the source files.  Assuming the upstream is managing
+    their website correctly (the private key is not leaked and the domain is
+    not hijacked), and the trust anchors have been set up correctly using
+    <xref linkend="make-ca"/> on the BLFS system, we can reasonably trust
+    download URLs to the upstream official website
+    <emphasis role="bold">with https protocol</emphasis>.  Note that
+    BLFS book itself is published on a website with https, so you should
+    already have some confidence in https protocol or you wouldn't trust the
+    book content.</para>
+
+    <para>If the package is downloaded from an unofficial location (for
+    example a local mirror), checksums generated by cryptographically secure
+    digest algorithms (for example SHA256) can be used to verify the
+    genuity of the package.  Download the checksum file from the upstream
+    <emphasis role="bold">official</emphasis> website (or somewhere
+    <emphasis role="bold">you can trust</emphasis>) and compare the
+    checksum of the package from unoffical location with it.  For example,
+    SHA256 checksum can be checked with the command:</para>
+
+    <note>
+      <para>If the checksum and the package are downloaded from the same
+      untrusted location, you won't gain security enhancement by verifying
+      the package with the checksum. The attacker can fake the checksum as
+      well as compromising the package itself.</para>
+    </note>
+
+<screen><userinput>sha256sum -c <replaceable>file</replaceable>.sha256sum</userinput></screen>
+
+    <para>If <xref linkend="gnupg2"/> is installed, you can also verify the
+    genuity of the package with a GPG signature.  Import the upstream GPG
+    public key with:</para>
+
+<screen><userinput>gpg --recv-key <replaceable>keyID</replaceable></userinput></screen>
+
+    <para><replaceable>keyID</replaceable> should be replaced with the key ID
+    from somewhere <emphasis role="bold">you can trust</emphasis> (for
+    example, copy it from the upstream official website using https).  Now
+    you can verify the signature with:</para>
+
+<screen><userinput>gpg --recv-key <replaceable>file</replaceable>.sig <replaceable>file</replaceable></userinput></screen>
+
+    <para>The advantage of <application>GnuPG</application> signature is,
+    once you imported a public key which can be trusted, you can download
+    both the package and its signature from the same unofficial location and
+    verify them with the public key.  So you won't need to connect to the
+    official upstream website to retrieve a checksum for each new release.
+    You only need to update the public key if it's expired or revoked.
+    </para>
 
   </sect2>