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