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

use SHA256 or GnuPG instead.

introduction/important/building-notes.xml

@@ -90,9 +90,9 @@ bunzip2 -v patchname.bz2</userinput></screen>
   </sect2>
 
   <sect2>
-    <title>Verifying File Integrity Using 'md5sum'</title>
+    <title>Verifying File Integrity</title>
 
-    <para>Generally, to verify that the downloaded file is genuine and complete,
+    <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
     corresponding md5sum file to the same directory (preferably from different
@@ -111,6 +111,58 @@ bunzip2 -v patchname.bz2</userinput></screen>
 
 <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>
 
   <sect2>