/ 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 Unified Diffs Ignore Whitespace Patch

Changes to README.md.

37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
...
309
310
311
312
313
314
315
316
317
318
319
320
321

322
323
324
325
326
327
328
329
330
331
332
333
334
335
336




337
338
339
340
341
342

  *  Latest release as
     [Tarball](https://www.sqlite.org/src/tarball/sqlite.tar.gz?r=release),
     [ZIP-archive](https://www.sqlite.org/src/zip/sqlite.zip?r=release), or
     [SQLite-archive](https://www.sqlite.org/src/sqlar/sqlite.sqlar?r=release).

  *  For other check-ins, substitute an appropriate branch name or
     tag or hash prefix for "release" in the URLs of the previous
     bullet.  Or browse the [timeline](https://www.sqlite.org/src/timeline)
     to locate the check-in desired, click on its information page link,
     then click on the "Tarball" or "ZIP Archive" links on the information
     page.

If you do want to use Fossil to check out the source tree, 
first install Fossil version 2.0 or later.
................................................................................
<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

The main SQLite webpage is [http://www.sqlite.org/](http://www.sqlite.org/)
with geographically distributed backups at
[http://www2.sqlite.org/](http://www2.sqlite.org) and
[http://www3.sqlite.org/](http://www3.sqlite.org).







|







 







|



|

>
|




|









>
>
>
>


|



37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
...
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347

  *  Latest release as
     [Tarball](https://www.sqlite.org/src/tarball/sqlite.tar.gz?r=release),
     [ZIP-archive](https://www.sqlite.org/src/zip/sqlite.zip?r=release), or
     [SQLite-archive](https://www.sqlite.org/src/sqlar/sqlite.sqlar?r=release).

  *  For other check-ins, substitute an appropriate branch name or
     tag or hash prefix in place of "release" in the URLs of the previous
     bullet.  Or browse the [timeline](https://www.sqlite.org/src/timeline)
     to locate the check-in desired, click on its information page link,
     then click on the "Tarball" or "ZIP Archive" links on the information
     page.

If you do want to use Fossil to check out the source tree, 
first install Fossil version 2.0 or later.
................................................................................
<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 a 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 it 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 the verification process 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
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.

The format of the `manifest` file should be mostly self-explanatory, but
if you want details, they are available
[here](https://fossil-scm.org/fossil/doc/trunk/www/fileformat.wiki#manifest).

## Contacts

The main SQLite website is [http://www.sqlite.org/](http://www.sqlite.org/)
with geographically distributed backups at
[http://www2.sqlite.org/](http://www2.sqlite.org) and
[http://www3.sqlite.org/](http://www3.sqlite.org).