Update the README.md file at the top level to talk about how to deal …

…with

version names and how to verify the code in Git mirrors.

FossilOrigin-Name: e8c87a0ac1bf434c12a8ab602e7913a89a51898e818f30fa541a9b5708864212

README.md

@@ -5,16 +5,28 @@ This repository contains the complete source code for the
 are also included.  However, many other test scripts
 and most of the documentation are managed separately.
 
-SQLite [does not use Git](https://sqlite.org/whynotgit.html).
-If you are reading this on GitHub, then you are looking at an
-unofficial mirror. See <https://sqlite.org/src> for the official
-repository.
-
-## Obtaining The Code
+## Version Control
 
 SQLite sources are managed using the
 [Fossil](https://www.fossil-scm.org/), a distributed version control system
-that was specifically designed to support SQLite development.
+that was specifically designed and written to support SQLite development.
+The Fossil repository contains the urtext.
+
+If you are reading this on GitHub or some other Git repository or service,
+then you are looking at a mirror.  The names of check-ins and
+other artifacts in a Git mirror are different from the official
+names for those objects.  The offical names for check-ins are
+found in a footer on the check-in comment for authorized mirrors.
+The official check-in name can also be seen in the `manifest.uuid` file
+in the root of the tree.  Always use the official name, not  the
+Git-name, when communicating about an SQLite check-in.
+
+If you pulled your SQLite source code from a secondary source and want to
+verify its integrity, there are hints on how to do that in the
+[Verifying Code Authenticity](#vauth) section below.
+
+## Obtaining The Code
+
 If you do not want to use Fossil, you can download tarballs or ZIP
 archives or [SQLite archives](https://sqlite.org/cli.html#sqlar) as follows:
 
@@ -294,6 +306,33 @@ Key files:
 There are many other source files.  Each has a succinct header comment that
 describes its purpose and role within the larger system.
 
+<a name="vauth"></a>
+## Verifying Code Authenticity
+
+If you obtained an SQLite source tree from a secondary source, such as a
+GitHub mirror, and you want to verify that it has not been altered, there
+are a couple of ways to do that.
+
+If you have an official release version of SQLite, and you are using the
+`sqlite3.c` amalgamation, then SHA3-256 hashes for the amalgamation are
+available in the [change log](https://www.sqlite.org/changes.html) on
+the official website.  After building the `sqlite3.c` file, you can check
+that is authentic by comparing the hash.  This does not ensure that the
+test scripts are unaltered, but it does validate the deliverable part of
+the code and only involves computing and comparing a single hash.
+
+For versions other than an official release, or if you are building the
+`sqlite3.c` amalgamation using non-standard build options, the verification
+process is a little more involved.  The `manifest` file at the root directory
+of the source tree ([example](https://sqlite.org/src/artifact/bd49a8271d650fa8))
+contains either a SHA3-256 hash (for newer files) or a SHA1 hash (for 
+older files) for every source file in the repository.  You can write a script
+to extracts hashes from `manifest` and verifies the hashes against the 
+corresponding files in the source tree.  The SHA3-256 hash of the `manifest`
+file itself is the official name of the version of the source tree that you
+have.  The `manifest.uuid` file should contain the SHA3-256 hash of the
+`manifest` file.  If all of the above hash comparisons are correct, then
+you can be confident that your source tree is authentic and unadulterated.
 
 ## Contacts
 

manifest

@@ -1,11 +1,11 @@
-C Back\sout\sthe\schange\sto\ssupport\sFuchsia,\ssince\sit\sturns\sout\sfuchsia\sdoes\snot\nlike\sdot-file\slocks.
-D 2019-03-15T19:08:23.606
+C Update\sthe\sREADME.md\sfile\sat\sthe\stop\slevel\sto\stalk\sabout\show\sto\sdeal\swith\nversion\snames\sand\show\sto\sverify\sthe\scode\sin\sGit\smirrors.
+D 2019-03-17T23:44:16.475
 F .fossil-settings/empty-dirs dbb81e8fc0401ac46a1491ab34a7f2c7c0452f2f06b54ebb845d024ca8283ef1
 F .fossil-settings/ignore-glob 35175cdfcf539b2318cb04a9901442804be81cd677d8b889fcc9149c21f239ea
 F Makefile.in 236d2739dc3e823c3c909bca2d6cef93009bafbefd7018a8f3281074ecb92954
 F Makefile.linux-gcc 7bc79876b875010e8c8f9502eb935ca92aa3c434
 F Makefile.msc 5df60c70edb157feb2148a14c687551969599bd065875a0b959b6b139721ca72
-F README.md 377233394b905d3b2e2b33741289e093bc93f2e7adbe00923b2c5958c9a9edee
+F README.md 1f3d347b2f8716878f00d54baf2e7caf8a7a5e1838e7442f7dcf6ce5ccb9c0ce
 F VERSION 288d756b1b7be03ecdbf1795c23af2c8425f2e46ba6979a14ef53360308f080d
 F aclocal.m4 a5c22d164aff7ed549d53a90fa56d56955281f50
 F art/sqlite370.eps aa97a671332b432a54e1d74ff5e8775be34200c2
@@ -1806,8 +1806,7 @@ F vsixtest/vsixtest.tcl 6a9a6ab600c25a91a7acc6293828957a386a8a93
 F vsixtest/vsixtest.vcxproj.data 2ed517e100c66dc455b492e1a33350c1b20fbcdc
 F vsixtest/vsixtest.vcxproj.filters 37e51ffedcdb064aad6ff33b6148725226cd608e
 F vsixtest/vsixtest_TemporaryKey.pfx e5b1b036facdb453873e7084e1cae9102ccc67a0
-P 73c4abc90264355f3ea6e8c34e5aad6ed665b70fb136c4d416e2a98e46562bbd
-Q -be21a6416d47ff7db995006a0422b745044d9b8bb5bad3c53342aa6e2e524771
-R a213c073daf803755a77adb42425f084
+P 1d801a3b2c48dc8a918d6da047bc877acf033d5f5c4e1d4b412ba7678ed6f8b3
+R d8fc549e8dd256986c9af5a900a70a1f
 U drh
-Z 2fc80787a186258407eabe023238e15d
+Z 007a0bb7f6e7e0fc6bf846f8fa4712b1

manifest.uuid

@@ -1 +1 @@
-1d801a3b2c48dc8a918d6da047bc877acf033d5f5c4e1d4b412ba7678ed6f8b3
+e8c87a0ac1bf434c12a8ab602e7913a89a51898e818f30fa541a9b5708864212