An ALWAYS(X) or NEVER(X) sometimes verifies pre-conditions that are subject to change if other parts of the code are modified in subtle ways. At [https://sqlite.org/src/artifact/18a53540aa3?ln=5512-5516] -we have a case test for two pre-conditions that are true only because +we have a test for two pre-conditions that are true only because of the limited scope of use of the sqlite3BtreeRowCountEst() function. Future enhancements to SQLite might use sqlite3BtreeRowCountEst() in new ways where those preconditions no longer hold, and the NEVER() macros will quickly alert the developers to that fact when the situation arises. But if, for some reason, the pre-conditions are Index: pages/codeofethics.in ================================================================== --- pages/codeofethics.in +++ pages/codeofethics.in @@ -19,11 +19,11 @@
This document is still sometimes used as a "Code of Conduct" on supplier registration forms. But it is not a Code of Conduct in the same sense that many communities mean a Code of Conduct. Rather, -this document describes the ethical principals upon +this document describes the ethical principles upon which SQLite is based. Another way to look at this document is as a succinct description of the SQLite Founder's idea of what it means to be "virtuous".
Index: pages/fullsql.in ================================================================== --- pages/fullsql.in +++ pages/fullsql.in @@ -27,14 +27,16 @@
SQLite is a [self-contained], [high-reliability], -[serverless|embedded], -[full-featured SQL|full-featured], [public-domain], +
SQLite is a C-language library that implements a +[footprint|small], +[faster than the filesystem|fast], +[self-contained], +[high-reliability], +[full-featured SQL|full-featured], SQL database engine. SQLite is the [most used] database engine in the world. -More Info
+It is built into all mobile phones and most computers and +comes bundled inside countless other applications that people +use every day. +More Information... + ++SQLite [https://sqlite.org/src|source code] +is in the [public-domain] and is free to +everyone to use for any purpose. -
Ongoing development and support of SQLite is made possible in part -by SQLite Consortium members, including:
- - - - -^(These functions only work for dates between 0000-01-01 00:00:00 -and 9999-12-31 23:59:59 (julidan day numbers 1721059.5 through 5373484.5).)^ +and 9999-12-31 23:59:59 (julian day numbers 1721059.5 through 5373484.5).)^ For dates outside that range, the results of these functions are undefined.
Non-Vista Windows platforms only support one set of DST rules. Vista only supports two. Therefore, on these platforms, Index: pages/pragma.in ================================================================== --- pages/pragma.in +++ pages/pragma.in @@ -1389,11 +1389,11 @@ Pragma database_list {
^(PRAGMA database_list;
This pragma works like a query to return one row for each database attached to the current database connection.)^ - ^(The second column is the "main" for the main database file, "temp" + ^(The second column is "main" for the main database file, "temp" for the database file used to store TEMP objects, or the name of the ATTACHed database for other database files.)^ ^(The third column is the name of the database file itself, or an empty string if the database is not associated with a file.)^
} Index: pages/security.in ================================================================== --- pages/security.in +++ pages/security.in @@ -1,38 +1,40 @@ -SQLite should never crash, overflow a buffer, leak memory, -or exhibit any other harmful behavior, even with presented with +or exhibit any other harmful behavior, even when presented with maliciously malformed SQL inputs or database files. SQLite should -always detected erroneous inputs and raise an error, not crash or +always detect erroneous inputs and raise an error, not crash or corrupt memory. Any malfunction caused by an SQL input or database file is considered a serious bug and will be promptly addressed when brought to the attention of the SQLite developers. SQLite is -extensively fuzz-tested to help ensure that it is highly resistant +extensively fuzz-tested to help ensure that it is resistant to these kinds of errors.
Nevertheless, bugs happen. If you are writing an application that sends untrusted SQL inputs or database files to SQLite, there are additional steps you can take -to help prevent zero-day exploits caused by undetected bugs: +to help reduce the attack surface and +prevent zero-day exploits caused by undetected bugs.
Applications that accept untrusted SQL inputs should take the following precautions:
Set the [SQLITE_DBCONFIG_DEFENSIVE] flag. -This prevents ordinary SQL statements from corrupted the database +This prevents ordinary SQL statements from corrupting the database file.
Consider using the [sqlite3_set_authorizer()] interface to limit the scope of SQL that will be processed. @@ -43,15 +45,20 @@
Applications that accept untrusted database files should do the following:
Run [PRAGMA integrity_check] or [PRAGMA quick_check] on the database -first, prior to running any other SQLite, and reject the file if any -errors are detected. +as the first SQL statement after opening the database files and +prior to running any other SQL statements. Reject and refuse to +process any database file containing errors.
Enable the [PRAGMA cell_size_check=ON] setting. + +
+Do not enable memory-mapped I/O. +In other words, make sure that [PRAGMA mmap_size=0].