If sqlite is compiled without the SQLITE_MAX_VARIABLE_NUMBER compiler flag, as is currently the case in Fedora//RHEL/CentOS, then sqlite uses 999 as the default, which is too low for some use cases, as discussed in the links below. Mac OSX compiles sqlite with SQLITE_MAX_VARIABLE_NUMBER set to 500000. Debian/Ubuntu, ArchLinux, and Homebrew set it to 250000. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717900 https://bugs.archlinux.org/task/52382 https://github.com/Homebrew/legacy-homebrew/pull/49423 Please consider setting this to something similar in Fedora/RHEL/CentOS. Thanks!
This bug appears to have been reported against 'rawhide' during the Fedora 32 development cycle. Changing version to 32.
Some additional information: I requested (https://www.mail-archive.com/sqlite-users@mailinglists.sqlite.org/msg118979.html) in the sqlite-users mailing list for them to raise the default value. One of their responses (https://www.mail-archive.com/sqlite-users@mailinglists.sqlite.org/msg119067.html) was a preference to not do it, because an application developer could then write queries (whether intentionally or via attack) that consume excessive heap memory (72 bytes * the limit, so if the limit is 250K, then that's 18MB) that could be an issue on low memory embedded systems. I don't know if Fedora is used in such systems, but I would think that for most computer systems, if an application is vulnerable to SQL injection, then an attacker forcing an extra 18MB of memory allocation is the least of your problems.
If this enhancement is not supported by upstream and it can also cause some security issues, we are not aiming to fix this. Closing this as WONTFIX. Feel free to discuss, or reopen this bug.