Documentation Source Text

     it recovers more content from corrupt database files.
<li> Enhance the [RBU] extension to support [indexes on expressions].
<li> Change the schema parser so that it will error out if any of
     the type, name, and tbl_name columns of the [sqlite_master table]
     have been corrupted and the database connection is not in
     [writable_schema] mode.
<li> Add the [SQLITE_DBCONFIG_ENABLE_VIEW] option for [sqlite3_db_config()].



<li> The legacy [SQLITE_ENABLE_STAT3] compile-time option is now a no-op.
}

chng {2019-07-10 (3.29.0)} {
<li> Added the [SQLITE_DBCONFIG_DQS_DML] and [SQLITE_DBCONFIG_DQS_DDL]
     actions to [sqlite3_db_config()] for activating and deactivating
     the [double-quoted string literal] misfeature.  Both default to "on"

     it recovers more content from corrupt database files.
<li> Enhance the [RBU] extension to support [indexes on expressions].
<li> Change the schema parser so that it will error out if any of
     the type, name, and tbl_name columns of the [sqlite_master table]
     have been corrupted and the database connection is not in
     [writable_schema] mode.
<li> Add the [SQLITE_DBCONFIG_ENABLE_VIEW] option for [sqlite3_db_config()].
<li> Added the [SQLITE_DIRECTONLY] flag for
     [application-defined SQL functions] to prevent those functions from
     being used inside triggers and views.
<li> The legacy [SQLITE_ENABLE_STAT3] compile-time option is now a no-op.
}

chng {2019-07-10 (3.29.0)} {
<li> Added the [SQLITE_DBCONFIG_DQS_DML] and [SQLITE_DBCONFIG_DQS_DDL]
     actions to [sqlite3_db_config()] for activating and deactivating
     the [double-quoted string literal] misfeature.  Both default to "on"

    <ol>
    <li>^(The rank of the column within the index.  (0 means left-most.))^
    <li>^The rank of the column within the table being indexed.
    <li>^The name of the column being indexed.
    </ol>

    <p>If there is no index named <i>index-name</i> but there is a
    [WITHOUT ROWID] table name <i>index_name</i>, then (as of
    SQLite [version 3.30.0] on [dateof:3.30.0]) this pragma returns the
    PRIMARY KEY columns of the WITHOUT ROWID table as they are used
    in the records of the underlying b-tree, which is to say with
    duplicate columns removed.
}

Pragma index_xinfo {
................................................................................
    <li>^The name for the [collating sequence]
         used to compare values in the index-column.
    <li>^1 if the index-column is a key column and 0 if the index-column
         is an auxiliary column.
    </ol>

    <p>If there is no index named <i>index-name</i> but there is a
    [WITHOUT ROWID] table name <i>index_name</i>, then (as of
    SQLite [version 3.30.0] on [dateof:3.30.0]) this pragma returns the
    columns of the WITHOUT ROWID table as they are used
    in the records of the underlying b-tree, which is to say with
    de-duplicated PRIMARY KEY columns first followed by data columns.
}

Pragma index_list {

    <ol>
    <li>^(The rank of the column within the index.  (0 means left-most.))^
    <li>^The rank of the column within the table being indexed.
    <li>^The name of the column being indexed.
    </ol>

    <p>If there is no index named <i>index-name</i> but there is a
    [WITHOUT ROWID] table with that name, then (as of
    SQLite [version 3.30.0] on [dateof:3.30.0]) this pragma returns the
    PRIMARY KEY columns of the WITHOUT ROWID table as they are used
    in the records of the underlying b-tree, which is to say with
    duplicate columns removed.
}

Pragma index_xinfo {
................................................................................
    <li>^The name for the [collating sequence]
         used to compare values in the index-column.
    <li>^1 if the index-column is a key column and 0 if the index-column
         is an auxiliary column.
    </ol>

    <p>If there is no index named <i>index-name</i> but there is a
    [WITHOUT ROWID] table with that name, then (as of
    SQLite [version 3.30.0] on [dateof:3.30.0]) this pragma returns the
    columns of the WITHOUT ROWID table as they are used
    in the records of the underlying b-tree, which is to say with
    de-duplicated PRIMARY KEY columns first followed by data columns.
}

Pragma index_list {

If the application does use triggers or views, then use queries to
scan the [sqlite_master] table to verify that the triggers and views
found there are expected, that there are no surplus triggers or views,
existing triggers and views have not been tampered with,
and that no existing ordinary tables have been replaced by
malicious views.
</p>












</ol>
</ol>


<p>Even if the application does not deliberately accept database files
from untrusted sources, beware of attacks in which a local database file
is surreptitiously altered to contain harmful content.

<h1>Summary</h1>

<p>
The precautions above are not required in order to use SQLite safely
with potentially hostile inputs.
However, they do provide an extra layer of defense against zero-day
exploits and are encouraged for applications that pass data from
untrusted sources into SQLite.

If the application does use triggers or views, then use queries to
scan the [sqlite_master] table to verify that the triggers and views
found there are expected, that there are no surplus triggers or views,
existing triggers and views have not been tampered with,
and that no existing ordinary tables have been replaced by
malicious views.
</p>
<li><p>
If the application uses [application-defined SQL functions] that have
side effects, then it is recommended to set the [SQLITE_DIRECTONLY] flag
on those SQL functions to prevent them from being used inside triggers
and views.  To illustrate the importants of this flag, consider an
application that implements an SQL function "send_money(...)".  Without
the SQLITE_DIRECTONLY flag, an attacker might be able to add a trigger
or view that uses that custom function, then trick a
high-privilege application to run an otherwise harmless query that invokes
that malicious trigger or view.  The SQLITE_DIRECTONLY flag prevents the
attack by requiring the "send_money()" function to be invoked directly
by the application, rather than indirectly through a trigger or view.
</ol>
</ol>


<p>Even if the application does not deliberately accept database files
from untrusted sources, beware of attacks in which a local database file
is surreptitiously altered to contain harmful content.

<h1>Summary</h1>

<p>
The precautions above are not required in order to use SQLite safely
with potentially hostile inputs.
However, they do provide an extra layer of defense against zero-day
exploits and are encouraged for applications that pass data from
untrusted sources into SQLite.