"Oleg LOA" ...
> "Vlad Horsun" ...
> > "Oleg LOA" ...
> >> Собсно в Ya 890 я по просьбам трудящихся добавил поддержку
> >> isc_dpb_encrypt_key.
> >
> > Так, как оно было заложено борландом ? Кака
>
> В смысле?
Все клиенты должны знать ключ шифрования. Кривизна немерянная, имхо
> >> Так вот открывая такую базу с кривым паролем имеем падения сервера в
> >> разных местах.
> >
> > А как же. Какая "архитектура" - такое и поведение. Неправильный
> > encrypt_key должен
> > отсекаться на этапе аттача, а не когда уже поздно.
>
> Только по контрольной сумме первой зашифрованной старницы. Или ты предлагаешь
> в header page писать хэш от пароля?
Я считаю, что то, что передаётся с isc_dpb_encrypt_key, не должно быть
ключём шифрования.
В хидер нужно писать идентификатор алгоритма шифрования, ибо он не должен быть
зашит в
движке, - а значит, рано или поздно, он будет не один.
> > Не в курсе. Можешь повторить ?
> >
>
> Анализируем тип страницы а потом быстро проверям "контрольные точки" на
> странице
Угу, я так и предполагал. Быстрая проверка не гарантирует точности, а
медленная
(точная) нам не нужна. Если я ещё могу предположить быструю проверку для
data_page,
то для btr - уже не могу. Да и от decompression buffer overrun быстрая проверка
не
поможет
> > Имхо такой "нестабильности кода " просто не должно быть в релизных
> > версиях. А на 100% защиту
> > всё равно не придумаешь.
>
> Ну про "не должно быть" можно не обсуждать ;-). Случаи повреждения БД по вине
> сервера имеют место быть.
Когда пишется мусор на страницы ? При полностью исправном железе ? И
отсутствии кривых УДФ ?
--
Хорсун Влад
--~--~---------~--~----~------------~-------~--~----~
-~----------~----~----~----~------~----~------~--~---
