"Oleg LOA" ...
> Собсно в Ya 890 я по просьбам трудящихся добавил поддержку
> isc_dpb_encrypt_key.
Так, как оно было заложено борландом ? Кака
> Так вот открывая такую базу с кривым паролем имеем падения сервера в разных
> местах.
А как же. Какая "архитектура" - такое и поведение. Неправильный encrypt_key
должен
отсекаться на этапе аттача, а не когда уже поздно.
> Т.к. код становится нестабильным, в силу отсутствия алгоритмов верификации
> содрежимого страниц.
>
> У меня шифровались страницы типов, причём заголовок страницы (PAG) не
> шифруется.
>
> #define pag_data 5 /* Data page */
> #define pag_root 6 /* Index root page */
> #define pag_index 7 /* Index (B-tree) page */
> #define pag_blob 8 /* Blob data page */
Угу, заголовок не надо шифровать, я тоже к этому пришёл
> Я в своё время кидал идею добавленияв код PIO_ перед запись и чтением
> механизма проверок
> того а что мы вообще пишем и что мы читаем. Хотя бы с точки зрения
> логического соответствия
> заголовка страницы с её содержимым.
Не в курсе. Можешь повторить ?
> Предлагаю обсудить в этой ветки возможные алгоритмы проверки старницы
> (отдельно для каждого типа)
> которые имело бы смысл включить в FB с целью повышения стабильности сервера.
> Обращаю внимание
> на то, что такая проверка более важна даже не столько при чтении страницы,
> т.к. можно контролировать
> через CRC, а при записи. Т.к. в случсе возниконовения нестабильности кода и
> затирания памяти, возможно
> разрушение старнц в кэше сервера с последующей записью в файл БД мусора.
Имхо такой "нестабильности кода " просто не должно быть в релизных версиях.
А на 100% защиту
всё равно не придумаешь.
--
Хорсун Влад
PS Ничё, что я влез ? :-D
--~--~---------~--~----~------------~-------~--~----~
-~----------~----~----~----~------~----~------~--~---
