wadmanhlopotun,

можно удалить текст процедур и функций.

но исходник можно довольно легко декомпилировать из двоичного формата.
Не знаю только, в 3й версии появившееся шифрование затрагивает эти двоичные данные или нет.

wadmanMikhail Tchervonenkoпропущено...


но исходник можно довольно легко декомпилировать из двоичного формата.
Не знаю только, в 3й версии появившееся шифрование затрагивает эти двоичные данные или нет.
В 2.х умельцам удалось практически идеально.
С тройкой всё сложнее. Пока гугл об этом не знает.

надо будет порыться в исходниках а пока было бы интересно услышать мнение разработчиков насчёт тройки.
Есть ли цифрация бинарного кода, а если нет то насколько сложна его декомпиляция. Кстати интересен процесс инсталляции обновлений в такую базу. Сначала с исходниками потом компиляция и удаление исходников или возможно сразу напрямую перенести/обновить скомпилированные заранее бинарные данные.

Mikhail Tchervonenko,

кстати в MSSQL вроде была (хоть и слабая) шифрация хранимок.

wadmanMikhail Tchervonenkoвозможно сразу напрямую перенести/обновить скомпилированные заранее бинарные данные.
Думаю, что это возможно, но придется для каждой версии сервера хранить свой бинарный код.
С компиляцией и удалением много проще.

но понижает защищённость. Кстати на MSCQL тоже шифрование ломалось довольно легко (про последние версии судить не могу, возможно залатали)

wadman,

кстати, шифрование, по идее, пожно прикрутить своё. Надо глянуть исходники и что там можно предпринять. Может что то на уровне UDF можно сделать.

hvladMikhail Tchervonenkoцифрация бинарного кода???
шифрация

hvladMikhail TchervonenkoНе знаю только, в 3й версии появившееся шифрование затрагивает эти двоичные данные или нет.Шифруются все данные, независимо от их принадлежности.

PS Долго думал над "затрагивает"...
т.е. скомпилированный код хранимых процедур можно шифровать, правильно?

hvlad,

причём интересно шифровать скомпилированный код отдельно от остальных данных. В доке написано только про "Не весь файл базы данных шифруется: только страницы данных, индексов и blob" и необходимость написания своего плагина для шифрования. "Для того чтобы сделать шифрование базы данных возможным необходимо получить или написать плагин шифрования базы данных". Но в случае защиты интелектуальной собственности разработчика шифровать все данные нет необходимости и даже, зачастую, неприемлемо. Может в самом этом плагине можно ограничить что шифровать, короче заинтересовало. Пороюсь на досуге, в исходниках где то мустер такого плагина вроде должен быть.

Mikhail Tchervonenko,

исходники тут examples\dbcrypt\

Dimitry SibiryakovMikhail TchervonenkoМожет в самом этом плагине можно ограничить что шифровать

Нельзя. И совершенно нельзя ограничить - что расшифровывать при запросе.

Другими словами обойти ограничение на полное шифрование данных нельзя.
Кстати, посмотрел в IBExpert не нашел где указывать ключ при соединении с подобной базой (или все пихать в Befor Connect и After Connect?).
ДокаОсновная проблема с шифрованием базы данных состоит в том, как хранить секретный ключ.
Firebird предоставляет помощника для передачи этого ключа от клиента, но это вовсе не
означает, что хранение ключей на клиенте является лучшим способом: это не более чем одна
возможных альтернатив. Хранение ключей на том же диске что и база данных является очень
плохим вариантом.
Для эффективного разделения шифрования и доступа к ключу, плагин шифрования базы
данных разделён на две части: само шифрование и держатель секретного ключа. Это может
быть эффективным подходом, когда вы хотите использовать некоторый хороший алгоритм
шифрования, но у вас есть собственный секретный способ хранение ключей.
После того как вы определитесь с плагином и ключом, вы можете включить процесс
шифрования.

Кто то уже реально пользовался шифрованием в FB3. Как впечатления? Понятно что скорость зависит от реализации плагина, но если её отбросить то насколько удобно и применимо на практике?