> Я даже не знаю, что на это можно ответить. Смотри, мы начали с вопрос "зачем zbox может
> понадобиться". Я привёл примертебе ткнули носом - что эта функциональность уже реализована именно в твоем примере, в 2005м году. Без всяких zbox'ов и rustов обошлась.
Причем реализована правильно, это еще те программисты писали, хорошие, только сильно затраханные - при открытом коде нет смысла скрывать структуры, только сами данные - поэтому шифруются поля в стандартных базах sqlite или json, а не базы (иначе ты даешь прекрасный материал дешифрующему). Ключом, превышающим размер шифруемого (что снимает вопросы к немного устаревшей криптографии - в zbox это будет больным местом даже при неустаревшей)
Ты зачем-то начал вилять и юлить, что не все файлы пошифрованы - хотя причем бы тут конкретный механизм? Это уже решение авторов кода, использовать его только для критичных, по их мнению, данных.
Поправить код мазилы ты вряд ли сможешь, иначе, опять же, тебе не надо бы было пихать туда новое-модное, достаточно было бы задействовать штатный механизм еще для десятка полей (по строчке кода на поле). Соответственно, тебе лично от zbox'а толку ровно ноль, параноиков вида "они увидят мои куки" спасет только geli с паролем при загрузке. (кстати, расскажите кто-нибудь этим любителям rust, что в windows шифрование встроено в ntfs с 2007 года - и оно по сей день ни у кого вопросов не вызывало, в отличие от устаревшей и полузаброшенной автором encfs)
Возвращаемся к исходному вопросу - так зачем нам эта модная поделка? Берущая на себя функции, помимо шифрования, которые вряд ли может реализовать хорошо (про конкурентный доступ не подумали, молодцы), а все остальное - стандартные библиотеки (вряд ли хорошие)
Если бы я был разработчиком - я бы смотрел в сторону исправления ошибки в nss. Bug 198090, если кто захочет исправить. 15 лет висит в status new. "no one asking". Менеджер лопатой по горбу не дал - ничего не сделано. Обратить внимание - no api change, изначально было задумано как надо, просто очень спешили и не доделали.
