SQLite vydal čtvrtou opravu větve 3.53. Chyb hlášených s pomocí AI podle něj ubývá

SQLite vydal 24. července verzi 3.53.4. Je to čtvrtá opravná verze větve 3.53 za necelé čtyři měsíce a SQLite ji popisuje větou, jakou u opravného vydání jinde nenajdete: opravuje chyby, které většinou objevily AI.

Rozepsanější je novinkový zápis k témuž datu. „Krátce po vydání 3.53.0 (2026-04-09) přišel obrovský nápor hlášení chyb pořízených s pomocí AI, ale v poslední době tempo hlášení znatelně kleslo a chyby, které se hlásí, jsou čím dál bezvýznamnější,“ píše se v něm (přeloženo). Následuje otázka, ne tvrzení: jestli lavina nekončí a jestli AI nenašly skoro všechno, co najít umějí. Zápis dodává, že příští vydání už možná bude 3.54.0 s novými funkcemi.

Co k tomu říká záznam změn

SQLite vyvíjí ve Fossilu a celá časová osa je veřejná, takže se ta věta dá zkusit ověřit. Vzali jsme check-iny větve branch-3.53 od vydání 3.53.0 a rozdělili je do oken mezi jednotlivými opravnými verzemi. Tatáž oprava se do stromu obvykle dostane dvakrát, do hlavní větve i do 3.53, takže se dvojice slučovaly na jednu položku.

• 3.53.1, okno 26 dní: 36 check-inů, z toho 13 s odkazem na hlášení
• 3.53.2, okno 29 dní: 73 check-inů, z toho 35 s odkazem na hlášení
• 3.53.3, okno 23 dní: 78 check-inů, z toho 44 s odkazem na hlášení
• 3.53.4, okno 28 dní: 36 check-inů, z toho 20 s odkazem na hlášení

„Odkazem na hlášení“ myslíme zprávu check-inu, která jmenuje příspěvek na fóru, číslo hlášení nebo toho, kdo problém nahlásil. Přepočteno na den je to 0,5, 1,2, 1,9 a 0,7 takové opravy. Pokles proti červnovému vrcholu je tedy zhruba na dvě pětiny a tvar odpovídá tomu, co SQLite píše. Je to ovšem počet oprav, ne počet hlášení, a datum opravy nemusí být datem, kdy chyba přišla.

Jedna věc se s popisem míjí. Nápor podle novinek přišel „krátce po vydání 3.53.0“, v záznamu je ale první okno nejchudší ze všech a vrchol spadá až na květen a červen. Kdo by chtěl vlnu vidět v dubnu, v časové ose ji nenajde.

Kde se AI v záznamu jmenuje

V celé větvi se AI jmenuje přímo dvakrát. Check-in z 23. června nese zprávu „opravy tří samostatných chyb objevených AI v nedodávaných rozšířeních“ (přeloženo). Jde o zaokrouhlování samých devítek v rozšíření decimal, o odstranění uvozovek v parametrech virtuální tabulky fuzzer a o čtení za koncem vyrovnávací paměti ve funkci next_char() rozšíření spellfix. Žádné z těch tří rozšíření se s knihovnou nedodává, používají se při testování.

Druhá zmínka váží víc. Check-in z 9. července říká, že v programu sqlite3_rsync opravuje „tři vady, které identifikoval Anthropic“ (přeloženo). Tenhle nástroj se dodává a slouží k tomu, aby se kopie databáze na druhém stroji srovnala s originálem, případně přes SSH. Změna sahá na jediný soubor, tool/sqlite3_rsync.c.

U ostatních oprav se ve zprávě check-inu o původci nedočtete. Zpráva odkáže na příspěvek na fóru nebo na časové razítko hlášení a tím to končí, takže poměr „kolik z toho našly AI“ jde z veřejného záznamu odhadnout jen podle toho, co SQLite napsal v novinkách.

Testovacího kódu má SQLite 590krát víc než vlastního

SQLite se dlouhodobě chlubí testováním a čísla k tomu má. Podle vlastní stránky How SQLite Is Tested má projekt 590krát víc testovacího kódu než kódu knihovny, čtyři nezávisle vyvíjené sady testů a stoprocentní větvové pokrytí v takové konfiguraci, v jaké se knihovna dodává. Ty údaje jsou ovšem počítané k verzi 3.42.0 z května 2023, novější stránka neuvádí.

Že to nestačí, ukázala sama větev 3.53. Vznikla jako znovuvydání staženého 3.52.0 a nese opravu chyby, která poškozovala databáze; v seznamu změn vystupuje jako chyba při resetu žurnálu WAL. K verzi 3.52.0, kde se oprava objevila poprvé, SQLite 6. března napsal, že jde o patnáct let starou chybu nalezenou pár dní předtím. Kdo ji objevil, v novinkách nestojí.

U curlu má vlna jiný průběh

U curlu vypadá totéž období opačně. Ten podle vlastního odhadu projektu běží asi ve třiceti miliardách instalací, od telefonů po tiskárny. Jeho zakladatel Daniel Stenberg napsal 26. května příspěvek The pressure, ve kterém popisuje tempo příchozích bezpečnostních hlášení jako čtyř až pětinásobek roku 2024 a dvojnásobek roku 2025, tedy v průměru přes jedno hlášení denně. Nejde podle něj o nesmysly: kvalita hlášení je vyšší než kdy dřív a jsou dlouhá a podrobná. Uvádí i osobní cenu, kterou to má: podle vlastních slov poprvé v životě vyjádřila jeho žena obavy z jeho pracovní doby.

Čísla si lze ověřit v seznamu zranitelností curlu, který projekt vydává i jako strojově čitelný soubor. Za rok 2026 je v něm k 1. srpnu 36 zveřejněných zranitelností proti devíti za celý rok 2025 a jedenácti za rok 2024. Vycházejí v dávkách spolu s vydáním knihovny: šest v lednu, čtyři v březnu, osm v dubnu a osmnáct 24. června. Novější dávka zatím není, protože curl od té doby nevydával, takže o červenci ten seznam neříká nic.

Závažnost je přitom nízká. Ze všech letošních je 22 hodnoceno jako Low a 14 jako Medium, žádná výš. Stenberg to sám zmiňuje: poslední curlí zranitelnost se stupněm High vyšla podle něj v říjnu 2023.

Co ta čísla nedokládají, je příčina. Seznam zranitelností u jednotlivých záznamů neuvádí, jestli za nálezem stál člověk, nástroj, nebo obojí; spojení s AI je Stenbergovo, ne údaj z evidence.

Dvě fáze, ne dva názory

Rozdíl mezi oběma projekty nemusí být rozdíl v postoji. SQLite popisuje vlnu, která u něj začala v dubnu a v červenci opadá; curl popisoval na konci května stav, kdy vlna teprve narůstala, a jeho poslední dávka hlášení je z 24. června. Jestli i curlu tempo klesá, se pozná až s příštím vydáním. Zatím platí jen to, že jeden z nich má vlnu podle vlastních slov za sebou a druhý o jejím konci nic nehlásí.

Zdroje

• SQLite Release 3.53.4 On 2026-07-24, poznámky k vydání
• Recent SQLite News, zápis z 24. července 2026
• SQLite: časová osa větve branch-3.53, repozitář Fossil
• Check-in c980094956, 23. června 2026, a check-in b6ab126399, 9. července 2026
• How SQLite Is Tested, údaje k verzi 3.42.0
• Daniel Stenberg: The pressure, 26. května 2026
• curl: seznam zranitelností, počty a závažnosti dopočítány ze strojově čitelné podoby seznamu