Documentation Source Text

<li> <a href="c3ref/funclist.html">List of C-language APIs</a>
</ul>
</li>
<li> <a href="tclsqlite.html">The TCL Interface Spec</a>
<li> <a href="quirks.html">Quirks and Gotchas</a> </li>
<li> <a href="faq.html">Frequently Asked Questions</a> </li>
<li> <a href="http://www.sqlite.org/src/timeline?n=100&y=ci">Commit History</a> </li>
<li> <a href="http://www.sqlite.org/src/wiki?name=Bug+Reports">Bugs</a> </li>
<li> <a href="news.html">News</a> </li>
</ul>
}
}

  incr nChng
}

chng {2020-08-22 (3.33.0)} {
<li> <i>No changes yet...</i>
}

chng {2020-06-04 (3.32.2)} {
<li> Fix a long-standing bug in the byte-code engine that can cause a
     [COMMIT] command report as success when in fact it failed
     to commit.  Ticket
     [https://www.sqlite.org/src/info/810dc8038872e212|810dc8038872e212]
<p><b>Hashes:</b>
<li>SQLITE_SOURCE_ID: 2020-06-04 12:58:43 ec02243ea6ce33b090870ae55ab8aa2534b54d216d45c4aa2fdbb00e86861e8c
<li>SHA3-256 for sqlite3.c: f17a2a57f7eebc72d405f3b640b4a49bcd02364a9c36e04feeb145eccafa3f8d
} {patchagainst 3.32.0 patchagainst 3.32.1}

chng {2020-05-25 (3.32.1)} {
<li> Fix two long-standing bugs that allow malicious SQL statements
     to crash the process that is running SQLite.  These bugs were announced
     by a third-party approximately 24 hours after the 3.32.0 release but are
     not specific to the 3.32.0 release.
<li> Other minor compiler-warning fixes and whatnot.
<p><b>Hashes:</b>

     <li> Add the .oom command in debugging builds
     <li> Add the --bom option to the [.excel], [.output], and [.once]
          commands.
     <li> Enhance the .filectrl command to support the --schema option.
     <li> The [UINT collating sequence] extension is automatically loaded
     </ol>
<li> The [ESCAPE] clause of a [LIKE] operator now overrides wildcard
     characters, so that the behavior matches what PostgreSQL does.
<li>SQLITE_SOURCE_ID: 2020-05-22 17:46:16 5998789c9c744bce92e4cff7636bba800a75574243d6977e1fc8281e360f8d5a
<li>SHA3-256 for sqlite3.c: 33ed868b21b62ce1d0352ed88bdbd9880a42f29046497a222df6459fc32a356f
}

chng {2020-01-27 (3.31.1)} {
<li> Revert the data layout for an internal-use-only SQLite data structure.
     Applications that use SQLite should never reference internal SQLite

#
# A small amount of manual editing and de-duplication followed.
#
# Manually edit the list for each subsequent release.
#      
foreach line [split {
xxxxxxxxxx|pending|Version 3.33.0
ec02243ea6|2020-06-04|Version 3.32.2
0c1fcf4711|2020-05-25|Version 3.32.1
5998789c9c|2020-05-22|Version 3.32.0
3bfa9cc97d|2020-01-27|Version 3.31.1
f6affdd416|2020-01-22|Version 3.31.0
18db032d05|2019-10-10|Version 3.30.1
c20a353364|2019-10-04|Version 3.30.0
fc82b73eaa|2019-07-10|Version 3.29.0

<title>Vulnerabilities</title>
<tcl>hd_keywords vulnerabilities {reported vulnerabilities} \
  {CVEs}</tcl>

<table_of_contents>

<h1>Executive Summary</h1>

<ul>
<li><p>
CVEs about SQLite probably do not apply to your use of SQLite.

<li><p>
All historical vulnerabilities reported against SQLite require at least
one of these preconditions:
<ol type="1">
<li><p>
The attacker can submit and run arbitrary SQL statements.
<li><p>
The attacker can submit a maliciously crafted database file to the
application that the application will then open and query.
</ol>

<li><p>
Few real-world applications meet either of these preconditions, and hence
few real-world applications are vulnerable, even if they use older
and unpatched versions of SQLite.

<li><p>
The SQLite development team fixes bugs promptly,
usually within hours of discovery.  New releases of SQLite
are issued if the bug seems likely to impact real-world

</ol>

<li><p>
The SQLite developers do not write CVEs.  Any CVEs you find on
SQLite are generated by third-parties, often without any input from the
core developers.  A common scenario is that someone will report a bug in
SQLite, which will promptly be fixed, then weeks later a CVE for that bug will
appear, unbeknownst to the developers.

<li><p>
You should not assume that a CVE about
SQLite contains authoritative information.
CVEs often contain inaccuracies.
The SQLite developers have attempted to add clarifications and
corrections to CVEs about SQLite, but without success.




</ul>

<h1>About CVEs</h1>

<p>CVEs ("Common Vulnerabilities and Exposures") are reports of software
bugs that might allow a system to be hacked.  The idea
behind CVEs is sound.  They provide a common naming scheme whereby 
software bugs that might compromise information security can be easily
tracked.

<p>While the original idea being CVEs is sound, the current processes for
creating and managing CVEs are inadequate.  There are countless grey-hat
hackers running fuzzers against a wide-variety of open-source software
products (SQLite as well as many others) and writing up CVEs against
any problems they find.  The grey-hats are rewarded, sometimes with
prestige and sometimes financially, by the number and severity of
the CVEs they write.  This incentive results in a proliferation
of CVEs which are often not well-vetted and which can have exaggerated

      {<a href="releaselog/\2_\3_\4.html">\0</a>} title
  }
  hd_puts "<h3>$date - $title</h3>"
  regsub -all "\n( *\n)+" $text "</p>\n\n<p>" txt
  hd_resolve "<blockquote>$txt</blockquote>"
  hd_puts "<hr width=\"50%\">"
}

newsitem {2020-06-04} {Release 3.32.2} {
The 3.32.2 release is a one-line change relative to 3.32.1
that fixes a long-standing bug in the COMMIT command.  Since
[version 3.17.0], if you were to retry a COMMIT command over
and over after it returns [SQLITE_BUSY], it might eventually
report success, even though it was still blocked.  This patch
fixes the problem.
}

newsitem {2020-05-25} {Release 3.32.1} {
[https://en.wikipedia.org/wiki/Grey_hat|Grey-hats] published
information about two SQLite bugs approximately 24 hours after
the release of version 3.32.0.  These bugs enable maliciously
crafted SQL to crash the process that is running SQLite.  Both
bugs are long-standing problems that affect releases prior to

</ol>

<p>
For reading database files that are unusually high-risk, such as database
files that are received from remote machines, and possibly from anonymous
contributors, the following extra precautions
might be justified.  These added defenses come with performance costs,
however, and so may not be appropriate in every situation:

<ol>
<li value="10"><p>
Run [PRAGMA integrity_check] or [PRAGMA quick_check] on the database
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.