Дэниэл Бернштейн (Daniel J. Bernstein), известный эксперт в области криптографии и создания защищённого ПО, разработавший такие проекты, как qmail, djbdns, NaCl, Ed25519, Curve25519 и ChaCha20-Poly1305, опубликовал выпуск проекта cdb 20250121, предлагающего формат хранения данных и сопутствующую библиотеку для встраивания в приложения функций для работы с БД в форме ключ/значение. Выпуск сформирован спустя более 25 лет с момента прошлого обновления cdb 0.75, сформированного в феврале 2000 года...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=64352
хоть бы пару про бд, а то вообще непонятно зачем
* слов
Ещё бы
Это как BerkleyDB до внедрения SQL.
> Это как BerkleyDB до внедрения SQL.Вообще совсем не похожи.
1) У BDB больше оверхеда на запись в обещм случае.
2) Зато BDB позволяет нормальную запись.А CDB как таковой не может добавить запись к существующей базе как я помню. Только заново перегенерить базу. В этом смысле какой-нибудь tokyo cabinet даст мастеркласс сабжу, ибо оверхеда на запись тоже мало - зато полноценная запись все же есть. Даже ACID если это надо. Есть и более педальные версии типа gdbm/qdbm/... - тоже с записью, но старинные.
Схерали не похожи? Я ж не сказал, что идентичны. Я сказал, что это как BerkleyDB. Т.е. C-библа для дисковой kv-базы-данных.
> Схерали не похожи?Read only VS read write это принципиально разный уровень возможностей. В BDB вы можете на лету добавить запись в базу. В CDB вы идете генерить всю базу заново. Это ооооочень большая разница.
Gdbm прекрасная вещь, но acid не умеет (хотя с моими юзкейсами проблем не возникало, но это пока питание не отключалось неудачно). Но единственная альтернатива на практике это sqlite3 (отключай питание сколько хочешь, если не затвикаешь предварительно).
> Gdbm прекрасная вещь, но acid не умеетИсторически это как-то так было: *никсные dbm -> gdbm -> qdbm и проч, а потом появились штуки по мотивам *dbm, типа tokyo cabinet. С похожей идеей, ниже оверхед, нет лимитив оригинала, есть ACID и проч. Ну и дальше пошло поехало и сейчас есть эн разных key-value по вкусу.
> Но единственная альтернатива на практике это sqlite3 (отключай питание сколько
> хочешь, если не затвикаешь предварительно).Вообще не альтернатива key-value как таковой. Намного более здоровенная либа, перфомансом не блещет, под key-value не делался особо. А SQL <-> key-value это все же разные миры. С очень разным перфомансом, уровнем сложности и проч.
Sqlite можно использовать в шелле и питоне. И через схожий с gdbm интерфейс в питоне. Я же говорю, на практике. Остальные варианты не столь foolproof и норовят рассыпаться с повреждением/утерей данных при не связанных обстоятельствах (например, ты забыл закрыть файл при исключении и просто упал, забудь про данные в файле leveldb) и грозят постоянной вознёй с регулярными перекомпиляциями при обновлении либ.
> Sqlite можно использовать в шелле и питоне.В них можно использовать даже мускуль и постгр если задаться такой целью. Но вот эквивалентом key-value оно от этого не станет. SQL в целом подразумевает иной перфоманс за счет оверхеда от парсера и вообще.
> Остальные варианты не столь foolproof и норовят рассыпаться с повреждением/утерей
> данных при не связанных обстоятельствах (например, ты забыл закрыть файл при
> исключении и просто упал,В упомянутом токийском кабинете точно есть транзакции - я проверял. И это работает так же как и любой иной ACID. Конечно с соответствующим импактом перфоманса writer'а если сыпать кучей микротранзакций, чудес не бывает.
А юзать мускуля как dbm можно конечно - но он жирней в эн раз - и что - он что-то стоящее кажет по перфомансу как вот именно key-value? Сравнимое с другими базами? Если нет - а нахрена такой key-value вперся?
А мы к тому же в треде про readonly базу - где writer'ов вообще изначально нет и ваша трабла не существует как класс.
> и грозят постоянной вознёй с регулярными перекомпиляциями при обновлении либ.
Не знаю кто там с чем возится, я прочто зацепил токийский кабинет из того что в пакетном манагере и оно себе работает сколько там дистр существует. Вообще ноль внимания к либе. И какие никакие доки и примеры на апю есть.
Да, я из сей и проч дергал это. Но если я key-value хотел - я хотел и оверхед и перфоманс под стать, чтобы конструирование схемы БД мануально - воздавалось хотя-бы. Занафига мне там питон вопрется с key value я не знаю, это бессмысленное и беспощадное комбо какое-то. Взять скоростную базу чтобы профакать перфоманс в цать раз питоном? Это вы сами так.
А чё там в mysql или postgres уже достаточно просто писать в файл с данными? И можно делать это с такой же простотой и удобством? Рассуждения какие-то не релевантные.
> А чё там в mysql или postgres уже достаточно просто писать в
> файл с данными? И можно делать это с такой же простотой
> и удобством? Рассуждения какие-то не релевантные.Простите, там вместо mysql имелся в виду sqlite. Если вы вдруг не поняли - key-value с интерфейсом по типу *dbm или что там у кого - юзают чаще всего для СКОРОСТИ.
А скулайт - сам по себе не особо туда метил изначально. А сдобреный питоном - этов вообще другая ниша.
Нет, не для скорости. Скорость подразумевает ограничения. Например, LMDB накладывает нездоровые ограничения на размер ключа при компилировании, что также раздувает структуры, а leveldb без acid и рассыпается при любом чихе вместе с его журналами. У sqlite3 acid и журналирование -- надёжность, это то, что выгодно её отличает. Скорость не критична, скорость никогда не критична и замечательно масштабируется при необходимости. Да и потом, там, где нужна скорость, используются решения для скорости (те же redis или memcached).Собственно, нет универсального решения, какие-то лучше для конкурентных записей (тут обойти sqlite не сложно), какие-то для чтений, у каких-то меньше накладные/сопутствующие расходы. Sqlite3 это синоним надёжности, универсальности, и отсутствия проблем. Он может быть быстрым, но тогда это будет либо inmemory (к слову, если хранилище быстрое, замечательно ускоряется и в обычном режимо), либо с пониженными гарантиями надёжности в нештатных ситуациях.
Вот если бы
Быстрая read-only БД в виде одного файла. Например, генеришь список reject или редиректы для postfix и раскидываешь по серверам.
стойкое ощущение, что что-то подобное про Редис было
только там "быстрое, т.к нет избыточности по многопоточности, а то что данные потеряются при отключении э/э - не страшно ибо это кеш или недолго-живущие ключи"
Или про Мускул, где аккурат один файл
Это не совсем БД, а просто неизменяемый справочник записей.
После создания его нельзя изменять, но можно моментально переключиться на новый.Неплохо подходит для DNS и других случаях, где очень-очень много чтений при крайне редких обновлениях.
вот это я понимаю качество и обратная совместимость
круче только “буханка”, 65 лет без патчей и обновлений
Про его софт нехорошие вещи говорят, мол, много бэкдоров и заброшено. В научной среде относятся достаточно скептически к этой васянокрипте. Какова вероятность, что и личность -- проект спецслужб? А если учесть, что уязвимости в алгоритмах эллиптических кривых (как раз продвигаемых различными американскими службами) уже находили?
> Про его софт нехорошие вещи говорятспециалисты с хабра?
> много бэкдоров
ссылочку хотя бы на один бэкдор, пожалуйста.
> В научной среде относятся достаточно скептически к этой васянокрипте
ссылочку на научные работы, пожалуйста.
> уязвимости в алгоритмах эллиптических кривых ... уже находили?
уязвимость уровня "если мы заранее знаем IV и nonce, а шифрованный текст короче 64 байт, то мы можем его сбрутить на гигакластере из 99999 видеокарт Nvidia H200 всего за год"?
Там были уязвимости уровня использовался предсказуемый /dev/urandom (обрати внимание, как практически весь софт перевели с криптографического /dev/random на удобный /dev/urandom) и можем расшифровывать в реальном времени. Не алгоритмы Бернштейна, что характерно, мол, пользуйтесь дальше спокойно.
Ничего себе, информация из восьмидесятых. Они одинаковые уже давно, один блокирующий, другой нет.
Лет 10 прошло? Тут вопрос больше к тому, что подмешивали. Генератор случайных чисел из процессора, ага. У /dev/urandom криптографическая стойкость никакая, если подмешиваемые числа хорошо предсказуемы. По этой причине подмешивают сейчас больше и не полагаются на аппаратные генераторы, а ещё есть сноска, что у /dev/urandom должно быть достаточно энтропии прежде чем его можно использовать (также сохраняется энтропия для следующей загрузки, но это костыли).
А в каких не находили?
Вот это набор бреда, лол.
А ты кстати кто такой, чтобы создателя прогрессивных алгоритмов называть васяном. Ты же ноль полный. Не ноль просто не мог написать такой комментарий. Не ноль понимает нерелевантность такой постановки вопроса.Есть алгоритм, который как математическая теорема, "доказан" в коде. Это не вопрос какой-то вероятности или принадлежности к "проекту". Сомневаться в реализации абсолютно правильно. Скатываться к доверяю/не доверяю - неправильно. Криптография - это недоверие всегда. Это математика в первую очередь. Если сам не можешь проверить алгоритм математически и удостовериться в корректности реализации, используй рекомендованные решения. Не надо из себя ничего изображать.
>как раз продвигаемых различными американскими службами
Продвигали потому что DSA потерял актуальность и RSA для сохранения надежности требует удваивать длину ключа раз в 5 лет (с потолка, возможно еще чаще), уже сейчас она уже нездорово огромная. Переход на эллиптику продиктован целесообразностью.
Продвигают прежде всего для внутреннего использования, в том числе в госсекторе, где их рекомендации имеют добровольно-принудительный характер. Если в алгоритме есть бэкдор, его могут найти китайцы/русские/северокорейцы/инопланетяне/итд/итп и обнулить их госсектор.
Я безмерно уважаю Бернштейна как математика, это то, чего мне никогда не достичь. Только математик вполне может оказаться и петрушкой. Не как программиста. Ты помнишь такого Paul Le Roux? Вот тут код примерно того же уровня, что у и того. Ему пришлось нанимать настоящих программистов, чтобы его доработать.А что для внутреннего использования, там интересные оговорки по криптостойкости в зависимости от шифруемых данных. И рекомендуемый bitlocker с аппаратными криптогенераторами для определённых данных, это, как бы сказать, попахивает тоже. Что до RSA, его криптостойкость обеспечивается на годы вперёд и при уязвимой сложности всё ещё потребует вычислений. Доквантовая криптография что-то до сих пор не рухнет никак.
То, что алгоритм публично продвигают для работы с гостайной, ещё не означает, что работающим с гостайной не были даны секретные рекомендации "используйте вот эту реализацию алгоритма, не очень совместимую с публичной, в отчётах и во всей документации будет обозвана тем же именем".
Поэтому, если телефон, то только Хуаэвэй. Там это коллективное западное *овно выпилено.
> Поэтому, если телефон, то только Хуаэвэй. Там это коллективное западное *овно выпилено.Отморозил назло бабушке уши. В хуавэях, особенно новых, 100500 бэкдоров и спайвари которая гребет данные лопатой на мутные китайские сервера, а порой и на гугловские заодно. Денег много не бывает.
Кстати китай к РФ географически ближе, активно колониз^W инфиль^W заселяет определенные регионы, и вообще-то глядя на некоторые вещи тоже решил провести некоторые исторические ревизии на тему кому что принадлежало. Конечно врядли они будут напрямую бомбить Владивосток, но это и не их стиль. Их - "китай там где китайцы" :)
Точно в Хуавее? Это не у него был самый чистый и защищённый андроид из представленных?
Я извиняюсь, но я не помню ни одной новости, чтобы в софте djb находили бэкдор. Я сам софтом от DJB не пользовался, ибо неюзабелен за исключением NaCl, но о нём ходят легенды что будто-бы этот софт высочайшего качества. Сам не проверял, не знаю.
Софт написан до того как дыры стали мейнстримом и никто не заинтересован их искать. Sendmail дырявый, qmail никак не может быть менее дыряв, только никому не интересен.
sendmail заднеприводными был написан, как же им - и без задней дыры?
> sendmail заднеприводными был написан, как же им - и без задней дыры?Это ещё что, Алан Тьюринг был из этих. Срочно откажись от компьютеров!
> При сборке активирован флаг "-Wall", а код почищен для устранения предупреждений.Я так понимаю никакого стат анилиза и санитайзеров у него нет?
Какой-то жирный намёк на то, что там всё забагованно и сплошные CVE. Ну тогда покажи где.
Это конкретно ваши фантазии. В оригинальном комментарии — констатация факта, выведенного из текста новости.
В оригинальном комментарии предполагается, что отсутствие стат анилиза и санитайзеров - это ужасный ужас и без них ну просто никуда, и весь софт всенепременно всё это использует направо и налево, и в борще, и в каше, и без этого ну просто не жизнь.
> Какой-то жирный намёк на то, что там всё забагованно и сплошные CVE.
> Ну тогда покажи где.Никакой это не намек. Просто странно не видеть этих инструментов в крипто либе. Просто если только сейчас включили Wall, странно спрашивать...
Ему за полтинник - может, он из тех самых Сишных дидов, которых любят поругивать в комментариях?
На плечах таких людей держится GNU/Linux.
https://en.wikipedia.org/wiki/Qmail
> Ему за полтинник - может, он из тех самых Сишных дидов, которых
> любят поругивать в комментариях?Как связан возраст и мой вопрос? Ему 54, а не 94. К слову Chris Lattner тоже под 50.
Larry Wall много полезного за прошедшие 20 лет сделал, а ведь 20 лет назад все дороги были.
Не, из тех самых дидов скорее Eric Paul Allman(September 2, 1955), автор Sendmail и его муж Marshall Kirk McKusick(January 19, 1954), один из создателей FreeBSDА Daniel Julius Bernstein следующее поколение(он 1971го), из «отцов-сишников», а не «дидов-сишников»
Наоборот - КОТОРЫЕ любят поругивать молодых 6олвaнов за некомпетентность.
Ну найди у него ошибку если ты такой умник.
> известный эксперт в области криптографии и создания защищённого ПО, разработавший такие проекты, как qmail, djbdnsВидим, ага, без релизов со времён убунты 14 и с тех же времён неисправленными уязвимостями.
- https://repology.org/project/qmail/versions
- https://repology.org/project/djbdns/versions
Тут есть тонкость
В qmail уязвимостей нет, потому что он минималистичный и тупой, как пробка, без патчей почти ничего не умеет(потому и есть премия за уязвимости за все десятилетия никем не полученная). А в репах qmail со сторонними патчами за которые автор типа не отвечает
Эксперт в области заброшенного совта.
Интересно бы было, если бы он сразу верификацию сделал, как в hacl* и код на С сгенерил. Вот тогда бы красота была.
> Интересно бы было, если бы он сразу верификацию сделал, как в hacl*
> и код на С сгенерил. Вот тогда бы красота была.DJB в вопросах крипто и верификации сам - верификатор что надо. Более того - он учитывает многие топики о которых горе-верификаторы с формальными бла-бла не в курсе вообще. Типа постоянного времени операций и - отсутствия утечек инфо по сторонним каналам в результате.
А ваши супер-верификаторы могут наверифицировать свое спагетти - а потом окажется что допустим ключ можно побайтово рекаверить за счет анализа таймингов. Или еще какая лажа глупая вылезет. DJB как эксперт в области - может уповать на себя а не на магию черных ящиков и мегатулов делающих ЗБС каким-то нонейм винтикам, компенсирующих свою невхожесть в топики убер-тулами. В таком виде крипто намного лучше. И лажа в его коде - ГДЕ? За столько лет никто ничего не нашел. А ваш код - похвастается таким же?