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

use SHA256 or GnuPG instead.
This commit is contained in:
Xi Ruoyao 2021-07-22 19:59:42 +08:00
parent f70acb8fbf
commit 633329679c
No known key found for this signature in database
GPG Key ID: D95E4716CCBB34DC

View File

@ -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>