SQLite

Check-in [e8c87a0ac1]
Login

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

Overview
Comment: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.
Downloads: Tarball | ZIP archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA3-256: e8c87a0ac1bf434c12a8ab602e7913a89a51898e818f30fa541a9b5708864212
User & Date: drh 2019-03-17 23:44:16.475
Context
2019-03-17
23:59
New hyperlink on the README.md file. (check-in: cc5ab96715 user: drh tags: trunk)
23:44
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. (check-in: e8c87a0ac1 user: drh tags: trunk)
2019-03-15
19:08
Back out the change to support Fuchsia, since it turns out fuchsia does not like dot-file locks. (check-in: 1d801a3b2c user: drh tags: trunk)
Changes
Unified Diff Ignore Whitespace Patch
Changes to README.md.
1
2
3
4
5
6
7

8





9




10


11



12
13
14
15
16
17
18
19
20
21
22
23
24
<h1 align="center">SQLite Source Repository</h1>

This repository contains the complete source code for the 
[SQLite database engine](https://sqlite.org/).  Some test scripts 
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

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

  *  Lastest trunk check-in as
     [Tarball](https://www.sqlite.org/src/tarball/sqlite.tar.gz),
     [ZIP-archive](https://www.sqlite.org/src/zip/sqlite.zip), or
     [SQLite-archive](https://www.sqlite.org/src/sqlar/sqlite.sqlar).







>
|
>
>
>
>
>
|
>
>
>
>
|
>
>
|
>
>
>



<
<
<







1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29



30
31
32
33
34
35
36
<h1 align="center">SQLite Source Repository</h1>

This repository contains the complete source code for the 
[SQLite database engine](https://sqlite.org/).  Some test scripts 
are also included.  However, many other test scripts
and most of the documentation are managed separately.

## Version Control

SQLite sources are managed using the
[Fossil](https://www.fossil-scm.org/), a distributed version control system
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:

  *  Lastest trunk check-in as
     [Tarball](https://www.sqlite.org/src/tarball/sqlite.tar.gz),
     [ZIP-archive](https://www.sqlite.org/src/zip/sqlite.zip), or
     [SQLite-archive](https://www.sqlite.org/src/sqlar/sqlite.sqlar).
290
291
292
293
294
295
296



























297
298
299
300
301
302
303

  *  **ext/misc/json1.c** - This file implements the various JSON functions
     that are build into SQLite.

There are many other source files.  Each has a succinct header comment that
describes its purpose and role within the larger system.





























## 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).







>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>







302
303
304
305
306
307
308
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

  *  **ext/misc/json1.c** - This file implements the various JSON functions
     that are build into SQLite.

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

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).