Changes in introduction/important/building-notes.xml [bf5fb94:dddebae7]

File:

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

introduction/important/building-notes.xml

@@ -10 +10 @@
 
   <sect1info>
-    <othername>$LastChangedBy$</othername>
     <date>$Date$</date>
   </sect1info>
@@ -92 +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
@@ -112 +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>
@@ -406 +457 @@
     <title>Stripping One More Time</title>
 
+    <warning>
+      <para>If you did not strip programs and libraries in LFS,
+      the following will probably make your system unusable. To avoid that,
+      run the instructions at <ulink url="&lfs-root;/chapter08/strippingagain.html"/> 
+      instead.  After the critical files are  stripped using those instructions, 
+      the instructions below can be run any time new packages are installed.
+      </para>
+    </warning>
+
     <para>
       In LFS, stripping of debugging symbols was discussed a couple of
@@ -414 +474 @@
     </para>
 
-<screen><userinput>find /{,usr/}{bin,lib,sbin} \
+<screen><userinput>find /usr/{bin,lib,sbin} \
     -type f \( -name \*.so* -a ! -name \*dbg \) \
     -exec strip --strip-unneeded {} \;</userinput></screen>
@@ -615 +675 @@
         </listitem>
         <listitem>
-          <para>debug : '-g'</para>
+          <para>debug : '-g' - this is the default if nothing is specified
+          in either <filename>meson.build</filename> or the command line.
+          However it results large and slow binaries, so we should override
+          it in BLFS.</para>
         </listitem>
         <listitem>
-           <para>debugoptimized : '-O2 -g' - this is the default if nothing is
-           specified, it leaves assertions enabled.</para>
+           <para>debugoptimized : '-O2 -g' : this is the default specified in
+           <filename>meson.build</filename> of some packages.</para>
         </listitem>
         <listitem>
@@ -699 +762 @@
         replace the package's defaults, or even be ignored.  There are details
         on some desktop packages which were mostly current in April 2019 at
-        <ulink url="http://www.linuxfromscratch.org/~ken/tuning/"/> - in
+        <ulink url="https://www.linuxfromscratch.org/~ken/tuning/"/> - in
         particular, README.txt, tuning-1-packages-and-notes.txt, and
         tuning-notes-2B.txt. The particular thing to remember is that if you