/ Check-in [bbdbaf84]
Login

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:Improvements to the README.md file. No code changes.
Downloads: Tarball | ZIP archive | SQL archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA3-256: bbdbaf84a52937ccf877072a8b01b07f7b9c037c59ba54df72ca888d5404cbad
User & Date: drh 2019-03-28 01:00:37
Context
2019-03-28
04:03
If the string formatter in sqlite3NestedParse() fails due to an over-length string, make sure this error is recorded by the parser so that it knows to fail. check-in: 85e53ff1 user: drh tags: trunk
01:00
Improvements to the README.md file. No code changes. check-in: bbdbaf84 user: drh tags: trunk
2019-03-27
14:59
Support building the Tcl bindings DLL using MSVC. check-in: b2011c13 user: mistachkin tags: trunk
Changes
Hide Diffs Side-by-Side Diffs Ignore Whitespace Patch

Changes to README.md.

    37     37   
    38     38     *  Latest release as
    39     39        [Tarball](https://www.sqlite.org/src/tarball/sqlite.tar.gz?r=release),
    40     40        [ZIP-archive](https://www.sqlite.org/src/zip/sqlite.zip?r=release), or
    41     41        [SQLite-archive](https://www.sqlite.org/src/sqlar/sqlite.sqlar?r=release).
    42     42   
    43     43     *  For other check-ins, substitute an appropriate branch name or
    44         -     tag or hash prefix for "release" in the URLs of the previous
           44  +     tag or hash prefix in place of "release" in the URLs of the previous
    45     45        bullet.  Or browse the [timeline](https://www.sqlite.org/src/timeline)
    46     46        to locate the check-in desired, click on its information page link,
    47     47        then click on the "Tarball" or "ZIP Archive" links on the information
    48     48        page.
    49     49   
    50     50   If you do want to use Fossil to check out the source tree, 
    51     51   first install Fossil version 2.0 or later.
................................................................................
   309    309   <a name="vauth"></a>
   310    310   ## Verifying Code Authenticity
   311    311   
   312    312   If you obtained an SQLite source tree from a secondary source, such as a
   313    313   GitHub mirror, and you want to verify that it has not been altered, there
   314    314   are a couple of ways to do that.
   315    315   
   316         -If you have an official release version of SQLite, and you are using the
          316  +If you have a release version of SQLite, and you are using the
   317    317   `sqlite3.c` amalgamation, then SHA3-256 hashes for the amalgamation are
   318    318   available in the [change log](https://www.sqlite.org/changes.html) on
   319    319   the official website.  After building the `sqlite3.c` file, you can check
   320         -that is authentic by comparing the hash.  This does not ensure that the
          320  +that it is authentic by comparing the hash.  This does not ensure that the
   321    321   test scripts are unaltered, but it does validate the deliverable part of
   322         -the code and only involves computing and comparing a single hash.
          322  +the code and the verification process only involves computing and
          323  +comparing a single hash.
   323    324   
   324    325   For versions other than an official release, or if you are building the
   325    326   `sqlite3.c` amalgamation using non-standard build options, the verification
   326    327   process is a little more involved.  The `manifest` file at the root directory
   327         -of the source tree ([example](https://sqlite.org/src/artifact/bd49a8271d650fa8))
          328  +of the source tree
   328    329   contains either a SHA3-256 hash (for newer files) or a SHA1 hash (for 
   329    330   older files) for every source file in the repository.  You can write a script
   330    331   to extracts hashes from `manifest` and verifies the hashes against the 
   331    332   corresponding files in the source tree.  The SHA3-256 hash of the `manifest`
   332    333   file itself is the official name of the version of the source tree that you
   333    334   have.  The `manifest.uuid` file should contain the SHA3-256 hash of the
   334    335   `manifest` file.  If all of the above hash comparisons are correct, then
   335    336   you can be confident that your source tree is authentic and unadulterated.
   336    337   
          338  +The format of the `manifest` file should be mostly self-explanatory, but
          339  +if you want details, they are available
          340  +[here](https://fossil-scm.org/fossil/doc/trunk/www/fileformat.wiki#manifest).
          341  +
   337    342   ## Contacts
   338    343   
   339         -The main SQLite webpage is [http://www.sqlite.org/](http://www.sqlite.org/)
          344  +The main SQLite website is [http://www.sqlite.org/](http://www.sqlite.org/)
   340    345   with geographically distributed backups at
   341    346   [http://www2.sqlite.org/](http://www2.sqlite.org) and
   342    347   [http://www3.sqlite.org/](http://www3.sqlite.org).