On 14.07.2015 14:36, László Böszörményi (GCS) wrote:
On Tue, Jul 14, 2015 at 11:41 AM, Yuriy M. Kaminskiy <[email protected]> wrote:Package: libsqlite3-dev Version: 3.8.7.1-1+deb8u1 Followup-For: Bug #736463(was sent to unrelated bug, resenting, sorry) 1) I was able to reproduce this bug in jessie's 3.8.7.1 (gdb and valgrind report attached); 2) I was *NOT* able to reproduce it in (self-backported) sid's 3.8.10.2-1 (and running under valgrind does not show any problem). [fwiw, test.db created by sid {totally expectdly} kills jessie's sqlite3 on attempt to open it]. However, I have not found respective entry in changelogs (or upstream commit), so this could be false positive.I can only repeat that the quick solution to remove UNIQUE, the PRIMARY KEY itself guarantee that the specified column will be unique.
:shrug:There should be no problem with attempt to open a database file obtained from untrusted source, right? It's just data, no executable code[*], etc, right?
Then try to open attached database with jessie's sqlite3. Or feed it to mozilla (IIRC, there are javascript binding?) That is, this is a security problem.(The fact that UNIQUE constraint is redundant with PRIMARY KEY is completely irrelevant here; e.g. it can be autogenerated code, database should handle that gracefully anyway).
[*] well, almost; there are triggers, but their side effects are limited to altering the database.
test.db
Description: Binary data
