The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Эксперимент с использованием SQLite в качестве контейнера для архивирования файлов, opennews (??), 25-Мрт-24, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


65. "Эксперимент с использованием SQLite в качестве контейнера дл..."  +/
Сообщение от Аноним (84), 25-Мрт-24, 21:32 
And forgot to add:
* For the purpose of this paragraph let's assumme that SQLite when built with maximum hardening is secure ... Even if you use maximum source-level hardening options of SQLite, it would limit your software to 2 options: statically linking the SQLite lib with thisenoptions, or dynamically linking an additional variant of SQLite lib living in a separate package. Some distro maintainers can forget about this security measure and just link the usual distrowise SQLite lib optimized for performance and special tasks like schema manipulation ... creating this way a vulnerability. So mere using SQLite for the task it is unsuitable for introduces a weak point.
Ответить | Правка | Наверх | Cообщить модератору

80. "Эксперимент с использованием SQLite в качестве контейнера дл..."  +/
Сообщение от O (?), 26-Мрт-24, 00:55 
All are an will be statically linked. They are not considered a shared library to the program, but part of the source.
Ответить | Правка | Наверх | Cообщить модератору

82. "Эксперимент с использованием SQLite в качестве контейнера дл..."  –3 +/
Сообщение от Аноним (84), 26-Мрт-24, 02:21 
Noone sane uses statically-linked libs and sane distros would never accept anything using statically linked libs. It is unmaintainable shit. If a yet another critical RCE vulnr is found in your precious SQLite, then the lib in the distro will be upgraded, but your archiver (needed by nobody sane and kept only to make a check mark that they have it in the repo, if it got enough adoption) with statically linked SQLite will stay vulnerable.

We have enough pain in the ass with Python's pickle, which should be considered a backdoor. If your archiver gets any adoption, there will be a yet another backdoor. Yes, I consider your archive format as a backdoor, and the attempt to forcibly promote it, to the point you are tracking mentions of it on websites in foreign languages, as an attempt to promote a hard-to-remove (if it got adoption and there would be enough archives of your format with valuable unique content in the Internet, so users would have no other option, but to either use SQLite and tolerate the risk, or create an own impl of SQLite specifucally designed to deal with malicious databases securely) backdoor.

Ответить | Правка | Наверх | Cообщить модератору

87. "Эксперимент с использованием SQLite в качестве контейнера дл..."  +/
Сообщение от Аноним (62), 26-Мрт-24, 10:43 
Ты просто не пользовался скулайтом, он примерно всегда бандлится. Или не заметил. Ну и все мейнтейнеры жрут, что им навалят разрабы, странный аргумент. Потому что шляпа вроде ffmpeg или libvpx регулярно ломает совместимость, но узнаешь ты об этом только когда пользователи начнут ныть (подход компилируется значит работает очень популярный у мейнтенеров). Или другой пример именно статически линкуемого компонента неизвестной версии это zlib.
Ответить | Правка | Наверх | Cообщить модератору

89. "Эксперимент с использованием SQLite в качестве контейнера дл..."  +/
Сообщение от Аноним (89), 26-Мрт-24, 13:07 
>Ты просто не пользовался скулайтом, он примерно всегда бандлится

У неадекватов всё подряд бандлится, причём с обоснованием уровня "а вот я тут главный, хочу так, и ниипёт". Некоторые доходят до того, чтш используют Rust или поставляют свои программы в формате Snap или Docker-контейнеров.

zlib и sqlite вообще отличаются довольно стабильным API и очень широко используются, я не помню, чтобы хоть раз какой-либо софт сломался из-за этих либ, прилинкованных динамически.

Вот пример адекватного пакетирования
https://packages.debian.org/sid/python3.12-minimal , https://packages.debian.org/sid/libzip4t64 , https://packages.debian.org/sid/libarchive13t64 , https://packages.debian.org/ru/sid/libxft-dev , https://packages.debian.org/buster/libsvn-dev (остальное найдёшь сам, меня забанили в Гугле. zlib1g AND -inurl:zlib1g AND -inurl:lib32z1 AND -inurl:lib64z1 AND -inurl:search AND -inurl:search_contents AND -inurl:zlib AND site:packages.debian.org) - зависит от https://packages.debian.org/sid/zlib1g
https://packages.debian.org/sid/libpython3.12-stdlib - зависит от https://packages.debian.org/sid/libsqlite3-0

А свои сказки про то, что всегда бандлится ... я уже сказал, бандлится только у неадекватов, которым лень разобраться в работе CMake, поэтому у которых всё на git-подмодулях или вообще просто скопировано в дерево исходников.

Ответить | Правка | Наверх | Cообщить модератору

93. "Эксперимент с использованием SQLite в качестве контейнера дл..."  +/
Сообщение от Аноним (62), 26-Мрт-24, 13:24 
Дело не в этом. Лучше смотри на это с позиции когда мейнтенеры не будут возиться с разбандливанием и разгребанием багов в каждой поделке (а они там будут). Если говорить о скулите, то дистрибутивная версия может быть собрана без secure-delete (потому что это угрожает производительности), а та, что поставляется, например, с браузером, компилируется с этим флагом. Версии, поставляемые с браузером,  во многих случаях будут более новые, либо с применёнными (иными) патчами. В целом, особенно актуальны вопросы совместимости для программ на плюсах, сишные в значительной мере совместимы. Но всё равно нельзя взять и подсунуть произвольную версию и только разрабы знают какая подходит и почему, не мейнтейнеры. Куда чаще проблема не в том, что разрабы не разбираются, а в том, что мейнтейнеры разбираются недостаточно хорошо.
Ответить | Правка | Наверх | Cообщить модератору

96. "Эксперимент с использованием SQLite в качестве контейнера дл..."  +/
Сообщение от Аноним (96), 26-Мрт-24, 14:40 
Да, есть такая проблема. И это проблема в том числе самого SQLite. Слишком многое там конфигурируется во время компиляции флагами компиляции. Потому что нефиг на Си писать. Писать надо было на плюсах и юзать шаблоны, создавая где очень критично к производительности 2 версии кода, и не через макросы, а через ifы/switchи, где в каждом варианте все ветви кроме гдной будут выоптимизированы компилятором. Ещё проблем добавляет модель разработки SQLite - "мы не будем брать ваши патчи, мы возьмём только заказ на работу и гонорар за его исполнение". Костыльный вариант решения я вижу таким — запакетировать несколько бинарных вариантов либы под распространённые use case и линковать приложения к нужному варианту.

>Но всё равно нельзя взять и подсунуть произвольную версию и только разрабы знают какая подходит

Поэтому в программы и либы приходится пихать рантайм-диагностику, анализирующую флаги сборки и фичи, где целесообразно - включающую fallbackи и генерирующую рекомендации о том, какие флаги нужны.

Ответить | Правка | Наверх | Cообщить модератору

90. "Эксперимент с использованием SQLite в качестве контейнера дл..."  +/
Сообщение от O (?), 26-Мрт-24, 13:12 
Hey

I am sorry that you think like that. Not much tracking, rather shared with me on the Lazarus forum (IDE I sued for developing Pack), and I thought clearing some points may help some others.

I can explain more and correct your mistaken statements, but because of your way of talking, I think it won't help.

Ответить | Правка | К родителю #82 | Наверх | Cообщить модератору

94. "Эксперимент с использованием SQLite в качестве контейнера дл..."  +/
Сообщение от Аноним (89), 26-Мрт-24, 13:30 
I can give you a simple advice that will fix all issues in your format: just admit that it was an extremily bad idea to promote it as an archive format and put noticable warnings about that everywhere: on official webpages, in git repo, etc. For the uses that don't promote it as an archive format, but as a key-value store for a local use only in a pretty trusted setup ... there are plenty of solutions, and no hype around them.
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру