Проект Pack предпринял попытку создания формата для архивирования файлов, построенного на базе библиотеки SQLite и алгоритма сжатия ZSTD (Zstandard). Подготовленный прототип, написанный на языке Pascal и распространяемый под лицензией Apache 2.0, обогнал по скорости создания архивов наиболее распространённые архиваторы, при том, что его работа сводилась к чтению данных, сжатию библиотекой libzstd и выполнению SQL-операций по добавлению сжатых данных в файл с БД SQLite...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=60842
А почему бы не исолпльзовать tar с zstd? Ну и для 7z где-то были эксперименты с zstd.
Степени сжатия 7z можно достичь, используя xz, который по-умолчанию обычно уже есть в системе и tar умеет создавать tar.xz, а 7z потребует отдельной установки. xz и 7z оба используют алгоритм LZMA2 по умолчанию. Но если сравнивать что круче в одних и тех же условиях, zstd или LZMA2, то всегда зависит от самих файлов.
tar умеет создавать всё и всегда: tar -c .... | xz > file.txz
;-)
тем временем:
-J, --xz
(c mode only) Compress the resulting archive with xz(1). In
extract or list modes, this option is ignored. Note that this
tar implementation recognizes XZ compression automatically when
reading archives.
tar(1)
P.S. ;-)
> тем временем:
> -J, --xzЧто ты этим хотел сказать?
>> тем временем:
>> -J, --xz
> Что ты этим хотел сказать?а ты догадайся.
подсказка: tar(1) означает что скопировано из General Commands Manual утилиты tar
>>> тем временем:
>>> -J, --xz
>> Что ты этим хотел сказать?
> а ты догадайся.
> подсказка: tar(1) означает что скопировано из General Commands Manual утилиты tar:FACEPALM: Возьми с полки пирожок. Дальше-то что? Раскрой свою мысль. Или тебя похвалить, что ты способен скопировать часть текста из man-страницы?
Похвали, конечно. Трудно что ли?
> Похвали, конечно. Трудно что ли?Да что это я, действительно.
Молодец!
>>>> тем временем:
>>>> -J, --xz
>>> Что ты этим хотел сказать?
>> а ты догадайся.
>> подсказка: tar(1) означает что скопировано из General Commands Manual утилиты tar
> :FACEPALM: Возьми с полки пирожок. Дальше-то что? Раскрой свою мысль. Или тебя
> похвалить, что ты способен скопировать часть текста из man-страницы?мысль проста: вые?ся нужно уметь. ты - не умеешь. хотя, если ты из банды cat somefile | grep something то, кажется, я зря теряю время
p.s ;-)
> мысль проста: вые?ся нужно уметь. ты - не умеешь. хотя, если ты
> из банды cat somefile | grep something то, кажется, я зря
> теряю время
> p.s ;-)Аха :-). Мда. Скопировал кусок man'а, выдал какую-то невероятную мысль. Что хотел, зачем писал - не понятно.
Это тоже самое.
Победил 7z. Пофиг, что затратил 54.2 с, зато сильнее всех пожмакал.
В современных реалиях быстрее будет чуть больше скачать, но быстрее распаковать
Да не факт! Вы что, из америки где "везде есть интернет, электричество и паркинг"?? Люди могут и на 8Мбит сидеть - им не нужны ГИГАБАЙТЫ инфы, которую кто-то никак не может сжать.
Мы из России. Тут интернет плохой в небольших удаленных поселках. Но 1МБ/с -- это вообще вполне сносно и не напряжно в рамках дачного поселка в 30км от города.
Сомнительное соотношение скорости сжатия к размеру файла и скорости скачивания. У меня 100 мегабит етхернета быстрее работает чем большинство флешек лет 10 назад.
Тогда уж xz. Только там еще дольше)
Там тот же lzma только в формате потока, поточные компрессоры всегда будут давать результат хуже архиватора и иметь меньшую гибкость, но например они позволяют сжать тарбол со всеми атрибутами в него сохранёнными. Конечно, 7z/rar тоже позволяют запаковать тарбол, но они являются архиваторами со своей по-файловой логикой и тут стоит проверить здоровье.
7z не дедуплицирует данные, поэтому годится только для маленьких и скучных наборов (без расширенных атрибутов, тегов, времени изменения/доступа и прочего подобного). А результат на пару килобайт лучше достигается совершенно дефективным форматом файла.
Ему это не надо, он это умеет на уровне алгоритма словаря с параметром qs. Если словарь достаточного размера. Умеет атрибуты NTFS потоки. С атрибутами файла есть недостатки, потому что 7z не совсем из мира unix way.
Если словарь достаточного размера. Типичный архив в него не влезает, кроме того, ресурсов намного больше необходимо (и для упаковки и для распаковки) и в многопотоке прогрессия там не очень приятная.
Джипеги же жали, да?))
rar одного размера с zip?
Подозрительно. rar обычно лучше сжимает.
Разный же! 253 и 235 Мб
В отрыве от возможностей в мейнстриме это всё весело, но довольно бессмысленно.
Отдельно интересно посмотреть бенчмарк всех этих весёлых алгоритмов на разных типах данных и на разных выборках (например, что если нужно извлечь только один файл из сета, либо обновить один файл)
С одной стороны соглашусь, с другой нет. SQLite поставляется во всех массовых дистрибутивах систем и языков программирования, и сделать возможность создания такого арзива достаточно легко и не требует наличия специфических зависимостей, так что жизнь у проекто точно возможна, но как мы знаем, это далеко даже не 25%.Сколько проектов всяких интересных по сжатию умирало из-за отсутствия поддержки в меинстриме
Скулайт он как питон, второй лучший вариант в любой сфере. Только тут задачи применимые к базе данных. Но всегда есть первый вариант.
>pickle поставляется во всех массовых дистрибутивах Python, и сделать возможность создания такого файла с сериализацией достаточно легко и не требует наличия специфических зависимостейОтлично, давайте использовать везде pickle, зачем нам какие-то JSON, CBOR, npy, safetensors, ведь это надо код писать, а тут всё в стандартной библиотеке! Давайте выпилим из либ код ненужных сериализаций и десериализаций, и будем просто использовать pickle!
Тут нечего смотреть! Бенчи Сыкулита будут ±1% от того архиватора, который под капотом (на ЕДИНИЧНЫХ файлах). Главное - такой формат позволяет БЫСТРЫЙ доступ к любому файлу, что может быть полезно для каких-нть утилит синхронизации или просто "обновление бэкапа".
Вообще они немножко опоздали, таких штук было уже навалом
https://github.com/phiresky/sqlite-zstd
Душнила. Весь кайф поломал :D
В новости речь про воссоздание архиватора на базе SQLite, а sqlite-zstd - дополнение для прозрачного сжатия записей в SQLite.
Ну раз пошла такая пьянка ... https://codeberg.org/KOLANICH-libs/Cache.py
жду реализации для http-статики =) в духе времени будет
Для веб-архивирования. Как раз есть аддон SingleFile, который выгружает все ресурсы страницы (стили/графику), и инлайнит её в html, кодируя в base64. И есть на его базе отдельный SingleFileZ, который формирует zip-архив, и аналогичным образом вкладывает в html-страницу вместе со скриптом на js для распаковки и рендера.
Тут можно сделать что-то подобное, но вложив в html-страницу БД SQLite, и скрипт для доступа к ней. С поддержкой сжатия БД.
Хотя бы в рамках эксперимента и веществ.
https://wiki.openzim.org/wiki/ZIM_file_format со сжатием, есть просмотрщики. При этом всё умно по категориям ресурсов распихивает, а не тупо в Base64 кодирует.
Только нет вменяемых средств создания.
> При сжатии каталога с 81 тысячей файлов, общим размером 1.25 ГБ, pack оказался быстрее утилиты ZIP в 112 раз, выполнив операцию за 1.3 секунды против 146 секунд у ZIPПодозреваю, первым замерили скорость zip, и файлы он читал с диска, а после него запустили pack и файлы он брал из кэша. Ничем другим такую разницу объяснить невозможно.
То, что Pack оказался настолько быстрее Zip-а, конечно, подозрительно, но пусть (разные алгоритмы сжатия с многопоточность ю в Zstd и т.п.). Но то, что tar.gz с Deflate оказался в несколько раз быстрее, чем Zip с таким же Deflate (размер тарболла оказался даже несколько меньше, т.е. дело явно не в разных степенях сжатия), лично для меня является более серьёзным аргументом в пользу неправильно проведённого теста.
"тест с zip был запущен при холодном кэше, а остальные тесты при прогретом"
Серьёзно? Это ведь эпичнейшая фейспальма!
Чтобы дропнуть кэши надо записать 1 байт в специальный файл, очень сложно. Да и в чёрной-чёрной консоли, очень страшно! У нас тут дружелюбный паскаль. Но вообще, без указания версий и параметров это ни о чём. Поразительно низкое качество подачи материала, тот случай, когда со дна постучали.
Это очень важный пункт эксперимента.
Он наглядно демонстрирует, насколько стоит доверять всем остальным намерянным циферкам.
Не на то смотришь. Если в намеренных данных не указаны ни доверительные интервалы, ни дисперсия, то не данные и были, кто-то просто нарисовал цифры от балды. Если есть, то следующий этап -- это исходные данные, на которых считались статистики или скрипт, который эти данные получает. Либо это есть, и вот тогда можно подумать над результатами статистики и как-то интерпретировать их, либо этого нет, тогда думать не о чем.
Хорошо хоть что сами дали себе явную оценку в тестах. Хотя по результата и так ясно что авторы в полном неадеквате
Безумству храбрых поём мы песню.
Разве это не просто альтернативная реализация идеи https://www.sqlite.org/sqlar/doc/trunk/README.md ?
> This repository contains sources for the "SQLite Archiver" program. This program (named "sqlar") operates much like "zip", except that the compressed archive it builds is stored in an SQLite database instead of a ZIP archive.Причём sqlar аж 2014 года.
Скулайт итак мало для чего пригоден, так он теперь ещё и плохой архиватор.
в докер надо засунуть, тогда будет норм
libsql
systemd-sqlited
>предпринял попытку создания формата для архивирования файлов, построенного на базе библиотеки SQLiteSQLite by design умеет исполнять произвольный код, поэтому даже просто открывать недоверенные SQLite-базы небезопасно.
Извините, но что это за uдuотская фича - исполнять код?? Это в смысле "брешь" в обработке файлов или это прямо специально реализованная фича?
Споткнулся и выполнил
Штатная фича - https://www.sqlite.org/lang_createview.html . VIEW - эта такая типа таблица, но когда из неё SELECT делаешь, то выполняется код, который при создании VIEW указали. Что-то вроде хранимой процедуры. Через них некоторый софт, который использует базы, можно эксплуатировать.Ещё в SQLite можно умышленно подредактировать контролируемым образом базу через редактирование служебных таблиц https://www.sqlite.org/schematab.html . Это можно прикрыть на уровне либы путём флагов ... но ведь скачанный с инета файл может быть сделан не твоей обмазанной флагами либой, а вообще форком.
В общем ещё свежа память о том, как веб-страничкой с SQL-кодом, заточенным под эксплуатацию SQLite, Хром ломали (у него был API WebSQL на основе движка SQLite с навесными защитами).
Вы меня пугаете. Программные хуки в SQLite выполняются софтом.
Хромому они не помогли.
>сжатию библиотекой libzstdНапоминаю - zip -это контейнер, и туда могут быть добавлены произвольные компрессоры. Просто большинство реализаций не смогут распаковать архивы с компрессией, отличными от zlib, lzma и lzma2.
даже PPMD очень не везде поддерживается. В качестве реализации рекомендую https://github.com/mcmilk/7-Zip-zstd
ppmd уже давно поддерживается в 7z. Или ты смешивает ppmd и zstd.
в 7z - да, а вот во многих других реализациях помимо store и zlib в лучшем случае lzma2 поддерживается, а не полный комплект компрессоров. В питонью реализацию с помощью monkey-patchingа можно любой компрессор впрячь, и пакеты есть, но это всё же не приложение для конечного пользователя.
По скорее бы завезли zstd в info-zip, уже много лет как zip поддерживает zstd в стандарте. И zstd определённо предпочтительнее lzma по всем параметрам (а по многим и предпочтительнее deflate). А вот 7z что-то сдулся, теперь везде RAR и он не такой томозной и дефективный (даже больше линуксовых данных о файле поддерживает).
Мне плевать на "тормозной" до тех пор, пока замедление адекватно сжатию. У lzma2 оно адекватно, самое лучшее сжатие, что получал (на нужном наборе данных) - у brotli, просто бротли надо с песней компилировать и устанавливать на некоторых системах, а lzma из коробки идёт. zstd - это просто модно, юзаю его исключительно из-за наличия API для кастомного словаря в питоновском пакете (у lzma нет в пакете этого API). Но, как я уже сказал, хотя у brotli убрали вообще возможность юзать кастомный словарь в питоновском пакете, он жмёт лучше, чем zstd с шарингом словаря между записями. Поэтому, если есть возможность юзать бротли - то юзайте его.
Чего не хватает в 7z так это больше фильтров для разных типов файла как в winrar. Сейчас он имеет фильтры только для исполняемых файлов и wav.
Ещё фичей являются произвольные настраиваемые sfx модули. Куда можно встроить полноценный гуи или консольный установщик.
Так у 7z тот же brunsli для картинок есть уже много лет. Как по мне, главная фича рар это коды коррекции, ну и стратегии кодирования выбирает более адекватно.
Я хочу это чтобы было в стандартной поставке. Стратегии это по сути и есть препрецессор фильтры 7z для типа файла.
А где сравнение с утилитой zstd?
Есть такой проект, Pigz называется, тотже gzip, но распаралленый. Быстро работает.
Плохо, что всё время забываешь -I pigz к tar подкидывать. Его уже надо бы по-умолчанию подхватывать, если установлен.
Сделай его системным.
pbzip2 тоже, но чуть лучше жмёт и при распаковке контрольную сумму проверяет.
mksqushfs тоже неплох с дефолтным lz4 сжатием.
> При сжатии каталога с 81 тысячей файлов, общим размером 1.25 ГБЛучше пользоваться https://github.com/mhx/dwarfs. И сжимает мощно, и вместо распаковки можно просто смонтировать.
Можно и lrzip или lrzip-next.Если бы в Pack был бы precomp или аналоги -- это уже было бы круто, и позволило бы сжать джипеги процентов на 20. Очень не хватает подобной штуки в потребительских архиваторах.
А так вообще непонятно, чем именно оно лучше tar+zstd.
>read-only
> А так вообще непонятно, чем именно оно лучше tar+zstd.Прежде всего тем, что может вытащить ЛЮБОЙ файл за минимальное время.
Не, нужно так писать> Прежде всего тем, что МОЖЕТ вытащить ЛЮБОЙ файл за МИНИМАЛЬНОЕ время.
А этот dwarfs в качестве хранилки библиотеки сойдет?
> А этот dwarfs в качестве хранилки библиотеки сойдет?В целом да. Но если данные сами по себе плохо сжимаются, то проще как есть в папках хранить. Всё-таки это read-only fs, докидывать новые файлики будет трудно
Давно ищу архиватор/способ чтоб в архиве сохранялась дата создания(через stat это Birth) и изменения файлов(через stat это Modify), дописывать в имена файлов не вариант. В "окошках" все популярные форматы это умеют, а в более продвинутой ОС это не работает. Да ну не может быть подумал я .. какая же это была ошибка, ну вот нет такого.Долгие поиски и.. последняя надежда на 7z после выкатывания исходников для сборки от автора, но он продолжил стандартную "подлянку" с "Change" вместо "Birth", автору писал "не баг, а фича". Я пытался разобраться в исходниках и сделать нормальное поведение, как заявлено в документации, нуу и не смог.. Если кто-то знает где это правится, поделитесь пожалуйста, можно патчем. Или может другой способ какой рабочий.
Если сам формат файла хранит только ОДНУ дату, вряд ли ты сможешь туда засунуть вторую! (это так, мысли вслух) Спроси автора, может он идею какую подкинет (писать дату в комменты или что-то подобное).
> а в более продвинутой ОС это не работает. Да ну не может быть подумал
> я .. какая же это была ошибка, ну вот нет такого.Это в какой именно "более продвинутой"?
А то у лапчатых например Birth был долго "нинужна!" (ext2/3/4) - оттуда и отсутствие у многих утилит вменяемой поддержки.
>> а в более продвинутой ОС это не работает. Да ну не может быть подумал
>> я .. какая же это была ошибка, ну вот нет такого.
> (ext2/3/4)Тьфу, 4 там лишняя. Но пингвинячий stat() таки традиционно не поддерживает b_time.
Не так и давно, поддержку birth иноды (не столь и полезная для архивации информация на самом деле) в ядро добавили только несколько лет назад и только около года назад её добавили в glibc и следом в dolphin (с тех пор я её использую постоянно). Я использую расширенные аттрибуты для сохранения даты создания файла (и хеша, удобно после распаковки архива знать что это был за архив и когда модифицирован в оригинале, файлы не меняются, поэтому это и есть время создания плюс время записи), чтобы получить что-то вроде того, что есть на macos. Но я вижу, что многое надо доработать в файловом менеджере, например, чтобы он не удалял расширенные аттрибуты при копировании/перемещении файла.>7z
Oн вообще не сохраняет никакие линуксовые параметры файла, возлагать какие-либо надежды на грязную вендузятскую поделку не стоит. Лучше стоит обратить внимание на tar, и в частности индексированный tar позволяет получить быстрый произвольный доступ к сжатым данным, чего не может тот же 7z.
А по степени сжатия lrzip-zpaq натравленный на тарбол, в большинстве случаев значительно обходит 7z, и, кроме того, в режиме lrzip-lzma или даже lrzip-gzip он его обходит, поскольку полноценно дедуплицирует данные. Правда, его вряд ли получится индексировать, но тут уж стоит выбирать в зависимости от характера данных.
>>7z
>Oн вообще не сохраняет никакие линуксовые параметры файла, возлагать какие-либо надеждыНеужели вы до сих пор путаете архиватор с компрессором?
Использую для архивации *.tar.7z - что я делаю не так?
>> и в частности индексированный tar позволяет получить быстрый произвольный доступ к сжатым данным,
> Использую для архивации *.tar.7z - что я делаю не так?Обрати внимание на "быстрый произвольный доступ к сжатым данным".
Я тут уже лет 10 пишу, что с появлением твердотельников будущее за файловыми системами на основе хешей и БД.
> чтению данных, сжатию библиотекой libzstd и выполнению SQL-операций по добавлению сжатых данных в файл с БД SQLiteЭто имеет смысл только на конкретных юзкейсах "имеем один большой архив и периодически обновляем там некоторые файлы".
Для простых бэкапов (где критична степень сжатия) нужен сжимальщик, который учитывает ВЕСЬ контент - типа 7z (solid архивы).
Оверинженеринг
Прелестный эксперимент. Чтоб подумать над результатом. :)
Здравствуйте,I am the author of Pack, and I am happy to see you all interested in Pack. I am sorry for writing in English; my understanding of Russian is limited to that Здравствуйте.
I try to answer most of the comments here, but if you have any further questions or comments, let me know or email me (you can find it in the linked post).Warm or Cold:
On the linked post (https://pack.ac/note/pack), there is a line noting the test condition: "All corresponding official programs were used in an out-of-the-box configuration at the time of writing in a warm state."
Please note that for ZIP, the official tool is WinZip and I tried the test many times to find the best warm time and remove any file system and disk interference.
As noted in the post, you should test it for yourself. The numbers were not as "Look, others are bad". They are great; my point was, "Look what we can do if we update our design and code"Random access (extracting one):
You can do that with Pack:
`pack -i ./test.pack --include=/a/file.txt`or a couple files and folders at once:
`pack -i ./test.pack --include=/a/file.txt --include=/a/folder/`Use `--list` to get a list of all files:
`pack -i ./test.pack --list`Such random access using `--include` is very fast. As an example, if I want to extract just a .c file from the whole codebase of Linux, it can be done (on my machine) in 30 ms, compared to near 500 ms for WinRAR or 2500 ms for tar.gz. And it will just worsen when you count encryption. For now, Pack encryption is not public, but when it is, you can access a file in a locked Pack file in a matter of milliseconds rather than seconds.
Is it a compressed database?:
No. It is a container for files and raw data. Projects like sqlite-zstd are for any database for your projects. They are not made for files.sqlar:
Pack is a new format. sqlar inspired me to create Pack as a new improved solution.
Here is the latest sqlar result on Linux source code on the same test machine in warm state:
sqlar: 268 MB, 30.5 s
Pack: 194 MB, 1.3 sSQLite security:
It is one, if not the most secure, library out there. It is very hard to crack it, and it will not allow running any harmful code on a machine. It is used in almost anything with a computer, partially because of its security and reliability.
File system:
Noted projects like dwarfs are file systems.
It is read-only; Pack is not. Update and delete are not just public yet, as I wanted people to get the taste first.
It is clearly focused on archiving, rather than Pack wanting to be a container option for people who want to pack some files/data and store or send them with no privacy dangers.Big files instead of many small files:
Reading many files (81K in this test) is way slower than reading just one big file. For bigger files, Pack is much faster. Here is a link to some results from a kind contributor: https://forum.lazarus.freepascal.org/index.php/topic,66281.msg507177.html#msg507177
(Too long to post here)tar.zst:
As requested, here are some numbers on tar.zst of Linux source code (the test subject in the note):
tar.zst: 196 MB, 5420 ms (using out-of-the-box config and -T0 to let it use all the cores. Without it, it would be, 7570 ms. And it is done in two steps: first creating tar and then compression.)
Pack: 194 MB, 1300 ms Slightly smaller size, and more than 4X faster. (Again, it is on my machine; you need to try it for yourself.)
Honestly, ZSTD is great. Tar is slowing it down (because of its old design and being one thread).
Pack does all the steps (read, check, compress, and write) together, and this weaving helped achieve this speed and random access.Rate of compression:
7-Zip and other similar tools are focused on compression rate. Pack is on another chart, which is why I proposed CompressedSpeed [2]. The speed of getting to compression needs to be accounted for. You can store anything on an atom if you try hard enough, but hard work takes time. Deduplication step may get added, but in Hard Press [3].RAR compression speed is great too. Many times, it can do better than Pack. My argument is that does it worth the wait? After all, if you can use Pack for those cases too,. Hard Press [3] creates a more compressed pack for cases of pack once, unpack many.
[1] CompressedSpeed = (InputSize / OutputSize) * (InputSize / Speed). Materialized compression speed.
[2] You can choose --press=hard to ask for better compression. Even with Hard Press, Pack does not try to eat your hardware just to get a little more; it goes the optimized way I described.User experience:
Pack value comes from user experience, and speed is being one. I was not following the best speed or compression; I wanted an instantaneous feeling for most files. I wanted a better API, an easier CLI, improved OS integration (soon), and more safety and reliability.
On a final note, I suggest trying Pack for yourself and on your machine. I will be glad to hear more about your experience.
Thank you
>SQLite security:
>It is one, if not the most secure, library out there. It is very hard to crack it, and it will not allow running any harmful code on a machine. It is used in almost anything with a computer, partially because of its security and reliability.https://www.blackhat.com/docs/us-17/wednesday/us-17-Feng-Man...
Yes, I have read https://www.sqlite.org/security.html , but
* I still don't believe it is possible to make SQLite secure as an exchange format, there is a long trail of vulnrs in it allowing to achieve an RCE triggered by just opening a maliciously crafted database file and SELECTing from it.
* IMHO quality metrics for a good RDBMS are different from the ones of a good archiver. Everything is a tradeoff and there is ain't no such a thing as free lunch. RDBMS are information retrieval tools, they require good performance on wide ranges of queries and are usually operated on trusted data, so sacrificing some amount of security for performance is a tradeoff good RDBMS have to make. Archivers also need to be performant, but they are almost always operated on files from untrusted sources (downloaded from the Internet from random web pages) and so first of all they need to be secure, and then queries for them are pretty limited (basically it is a key-value storage), so a good archiver should optimize storage format for that purpose.I know that when one has a hammer, all problems look like a nail, but let's drive nails with hammers, not with microscopes ("drive nails with microscopes" is a Russian idiom, I hope you get its meaning).
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.
All are an will be statically linked. They are not considered a shared library to the program, but part of the source.
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.
Ты просто не пользовался скулайтом, он примерно всегда бандлится. Или не заметил. Ну и все мейнтейнеры жрут, что им навалят разрабы, странный аргумент. Потому что шляпа вроде ffmpeg или libvpx регулярно ломает совместимость, но узнаешь ты об этом только когда пользователи начнут ныть (подход компилируется значит работает очень популярный у мейнтенеров). Или другой пример именно статически линкуемого компонента неизвестной версии это zlib.
>Ты просто не пользовался скулайтом, он примерно всегда бандлитсяУ неадекватов всё подряд бандлится, причём с обоснованием уровня "а вот я тут главный, хочу так, и ниипёт". Некоторые доходят до того, чтш используют 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-подмодулях или вообще просто скопировано в дерево исходников.
Дело не в этом. Лучше смотри на это с позиции когда мейнтенеры не будут возиться с разбандливанием и разгребанием багов в каждой поделке (а они там будут). Если говорить о скулите, то дистрибутивная версия может быть собрана без secure-delete (потому что это угрожает производительности), а та, что поставляется, например, с браузером, компилируется с этим флагом. Версии, поставляемые с браузером, во многих случаях будут более новые, либо с применёнными (иными) патчами. В целом, особенно актуальны вопросы совместимости для программ на плюсах, сишные в значительной мере совместимы. Но всё равно нельзя взять и подсунуть произвольную версию и только разрабы знают какая подходит и почему, не мейнтейнеры. Куда чаще проблема не в том, что разрабы не разбираются, а в том, что мейнтейнеры разбираются недостаточно хорошо.
Да, есть такая проблема. И это проблема в том числе самого SQLite. Слишком многое там конфигурируется во время компиляции флагами компиляции. Потому что нефиг на Си писать. Писать надо было на плюсах и юзать шаблоны, создавая где очень критично к производительности 2 версии кода, и не через макросы, а через ifы/switchи, где в каждом варианте все ветви кроме гдной будут выоптимизированы компилятором. Ещё проблем добавляет модель разработки SQLite - "мы не будем брать ваши патчи, мы возьмём только заказ на работу и гонорар за его исполнение". Костыльный вариант решения я вижу таким — запакетировать несколько бинарных вариантов либы под распространённые use case и линковать приложения к нужному варианту.>Но всё равно нельзя взять и подсунуть произвольную версию и только разрабы знают какая подходит
Поэтому в программы и либы приходится пихать рантайм-диагностику, анализирующую флаги сборки и фичи, где целесообразно - включающую fallbackи и генерирующую рекомендации о том, какие флаги нужны.
HeyI 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.
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.
Some moar things I forgot to add:
* If this format gets adoption, insecure implementations in other languages will emerge. Just because it is easier and more correct to use the systemwide- or standard-lib-shipped SQLite lib rather than a custom-built one. For example a Python impl will just use the one available via import sqlite3, and it is the systemwide libsqlite3.so optimized fir speed and versatility.
* SQLite database can contain garbage, that can contain sensitive information. It can be cleaned though, but vacuuming takes a twice as large space as the file is, because for fail-recovery purposes it makes a copy first, and then clears the original file.
* SQLite databases can produce additional files alongside with database files. Journals and wrute-ahead logs. Deleting such files before they are merged into a main database file corrupts that database.
Thank you for the interest.- As long as they use the official work, it will be securely checked and verified.
- If anyone attempts to rewrite, they need to take security seriously too. Just as different implementations of JPEG have different security flaws that need to be taken care of,. And a big reason most will use the official.
- One good point about Pack is that if they use SQLite, almost all will be secure from bad memory access problems, as SQLite is much more tested and reliable.
- SQLite has secure delete too, which does not take much extra time: https://www.sqlite.org/pragma.html#pragma_secure_delete- Your point about updating, and while doing that, those files are locked by OS. No one can delete them unless they force it.
>SQLite has secure delete too, which does not take much extra time: https://www.sqlite.org/pragma.html#pragma_secure_deleteThe fast variant doesn't guarantee cleanup. The slow one results in additional I/O = SSD wear. And you position your archiver as a faster alternative to zip, and additional cleanup will make it less fast.
>If anyone attempts to rewrite, they need to take security seriously too
Let's say it clear — IRL security of software is not a problem of software author, it is a problem of software user. Most of software have licenses, and every sane license disclaim any liabilty. For software not having licences you get no warranty either. Software is distributed AS IS and its users are liable themselves that they have to use software written by assholes. Ones who is not OK with that have to create an own "Juche"-software, in the extreme case of total so-called "supply-chain security" - the whole stack: own research facilities, own foundries, own hardware, own microcode, own firmware, own OS, own libraries, own applications, own Internet to use their Juche-stack with (because Juche-stack will never pass Web Environment Integrity check), own everything :), and hold liability themselves and blame themselves solely. This will never happen in real world. You know it (don't pretend you don't!), because everyone, including you, uses insecure (and often - intentionally backdoored) software and hardware created by assholes.
In real worlde cannot expect that all the implementers will implement software "securely" when implementing it "securely" faces serious challenges. In this case it is very tempting to just use an SQLite lib from the distro/programming language and add a few code above it. Using another SQLite lib is not easy ... for example in the case of Python
a) one needs a dependency, `apws` package
b) since it is implemented in C, it has to be built, which is a big issue in Windows hosts
c) one needs a hardened SQLite lib
d) it also has to be built
e) one needs a way to plug that hardened SQLite lib into the programming language lib ... surprise, there is no such a feature in `apws`, its author's build scripts link it to hardcoded source-level included SQLite. There are ways to link it to external `libsqlite3.so`, but it seems they are jntentionally made pain in the ass. So one has to implement the feature in `apws` to load a certain shared SQLite lib per connection, persuade the maintainer of `apws` it is needed, upstream it to `apws`, backport that version of `apws` to all legacy versions of Python needed (and some of them are needed because assholes in PSF have decuded to drop certain versions of OSes, so to have a new version of Python one has either to maintain an own fork of it or buy a new PC with a license to a new version of the OS, and given that that OS was created by assholes, that version of the OS should never be used at all, so one has to use a hacky workaround to install a new version of Python onto a dropped version of OS that can break any time), persuade a user that he needs a tool with a dependency...So in real world the only viable tradeoff a dev has to make is just to use `sqlite3`. And the only viable tradeoff users (including the dev himself) have to make is just use insecure shitware written by assholes in order to just not to create own software and not to withstand the pressures to create a yet another piece of shit, and pray that the files they have to open are not exploits, instead of trying to live without those files. So people will just have to use insecure impls made by assholes. Real world issues caused by the format proposed by you strongly outweight all the benefits your format claims to provide.
>One good point about Pack is that if they use SQLite, almost all will be secure from bad memory access problems, as SQLite is much more tested and reliable.
Just use Kaitai (optionally with Rust/Python/Java/C# target) for parsing of properly designed binary formats and you should be pretty safe from insecure memory access.
>Your point about updating, and while doing that, those files are locked by OS. No one can delete them unless they force it.
Mandatory locks have to be explicitly be enabled in kernel during compilation. Kernels in distros are compiled without mandatory locks. Also, I have seen a lot of times additional files being kept after normal process termination. I have to open bases with `sqlite3` CLI tool to get rid of the unneeded files in those cases (usually backup). And if a process crashes mid-operation, they are always present.
>Just as different implementations of JPEG have different security flaws that need to be taken care of,. And a big reason most will use the official.
JPEG is not based on misusing preexisting widely-available lib that is insecure for that use case. JPEG doesn't create such drastic incentives to create ihsecure shit.
If you want to create a new archive format, just leave SQLite alone and design an own format and own lib, not based on SQLite, not using its source code, but written from scratch, using memory-safe subset of languages, with security-first design, using some ideas from fast databases.
Предпочитаю squashfs для архивирования. У него встроенное сжатие, но главное можно примонтировать и читать файлы с произвольным доступом без необходимости распаковывать весь архив.
Рекомендую dwarfs, он лучше
> Рекомендую dwarfs, он лучшеОк, подождём лет десять, как появится в репах дистрибутивов и если проект не будет заброшен, можно будет попробовать.
👍 прект наебалго, разница скорости между Ним и 7zip zstd примрено 15% по скорости, то есть, проект pack не создаёт ни хэша файла, ни фаловой иерархии внутри. И поэтому на примерно 15% быстрее
File hierarchy is implemented using recursive ID. In Item table, every Item gets linked to its parent by Parent field. On unpacking, they will be queried and verified.The hash of any compressed data is already stored and verified at the unpack step. It does not have an extra field, as it is stored together with the content.
Each file or piece of data gets separated and/or joined with others as content, then compressed if seen as beneficial. Zstandard (the internal compression algorithm) uses xxHash together with a header to verify decompression.
On unpacking, all needed Items (files or folders) get queried and checked, followed by all the ItemContents and related Contents. Each gets verified to be the correct size to prevent invalid memory access, and if decompression is needed, they will be double verified with their corresponding hash.
В 7z мне не хватает CRC.
некорректный дизайн теста. паскаль. no comments