>> Ты продолжаешь критиковать частный use-case
> Другой тебе не придумался.Не мне не придумывается, а тебе не придумывается. Мне не нужны другие юзкейсы, потому что мне этого юзкейса хватает за глаза и за уши, чтобы размышлять об общей ситуации на частном примере. Это *тебе* не удаётся абстрагироваться, это *тебе* не хватает юзкейсов для абстрагирования, они нужны *тебе*, а не мне. Поэтому говорить в этой ситуации, что *мне* не придумывается не надо. Мне они не нужны.
Ты хочешь, чтобы я придумал тебе ещё десяток юзкейсов? Мне совершенно не хочется этого делать, потому что хоть я и готов обсудить общий случай, но мне совершенно без интереса обсуждать частные. Это слишком долгий путь к более глубокому осознанию полезности zbox, чтобы я выбрал именно его. Если тебе необходим именно этот долгий путь, и более коротких ты не приемлешь, то иди долгим путём, но не надо меня туда тащить.
> Я вот не могу придумать реальной ситуации, когда такая штука была бы
> нужна вместо либо шифрования вместе с диском, либо шифрования данных отдельно
> от системы их хранения.
Шифрование диска упирается в усложнение поддержки кроссплатформенности приложения. Шифрование же отдельных данных упирается в длинный и сложный процесс внесения изменений в код. Zbox предлагает все изменения спрятать под API, которое уже используется в коде программы. Всё что нам надо -- это написать дефайнов типа "#define fopen zbox_fopen", "#define FILE zbox_FILE", ..., и реализовать десяток функций. Ситуация может осложниться, если всё же не все файлы следует класть в zbox, и тогда не удастся отвертеться от просматривания кода целиком, придётся где-то менять fopen на zbox_fopen, а где-то не менять, и каждый случай обдумывать. А может и не придётся -- может быть удастся решить эти проблемы динамически внутри zbox_fopen, анализируя пути к файлам. Хм... Таким подходом ведь можно вообще не трогая сорцов приложения (по-крайней мере, работающего поверх stdio.h), перевести его на защищённое хранилище: LD_PRELOAD в помощь. А можно ведь ещё сисколлы типа open/write перехватывать, тогда и вообще кого угодно... Правда это *nix'овое решение, в венде придётся по-вендовому извращаться.
Можно было бы выбрать какое-нибудь иное API, помимо fs, где можно относительно легко воткнуть шифрование. Например, взять API к SQL базе данных, и там это сделать. Но, во-первых, далеко не со всяким API к SQL базе данных это сделать просто, может быть придётся заменять sqlquery на zbox_sqlquery, которая будет парсить переданную ей строчку с запросом, шифровать то, что надо, потом собирать обратно в строчку и передавать в sqlquery. Ещё то веселье. Во-вторых, fs как API -- это наиболее распространённое API, и таким образом zbox получает максимальное число потенциальных кейсов, где его возможно применить. С тем же примером с sql: если такую библиотечку написать, то она будет применима только для тех программ, которые хранят данные в SQL. FS тоже имеет много разных API -- stdio.h, iostream, и тысячи других, но подавляющее большинство их функционально повторяет stdio, и повторить их поверх rust'ового std, выдав наружу C'шный API, а потом написав обёртку вокруг него на нужном языке программирования -- это развлечение на пару вечеров. Или не на пару... stdio.h можно за пару вечеров сделать, а в общей ситуации надо рассчитывать на неделю-две вечернего времяпровождения.
Если тебе непонятны эти рассуждения в абстрактном виде, то тогда у тебя есть единственный путь к пониманию: конкретный эксперимент. Возьми, скажем,... ладно, не надо брать ff, если тебе этот пример так неприятен, возьми claws-mail, или любой другой почтовый клиент, который не шифрует аутентификационные данные почтовых аккаунтов и локально хранимую почту. Скачай сорцы, создай там две ветки zbox и no-zbox. А потом попробуй в каждой из этих веток реализовать шифрование потенциально чувствительных к раскрытию данных. Сравни объёмы работ, которые тебе придётся выполнить в процессе. Я заверяю тебя, когда ты это проделаешь, ты вернёшься сюда рассказывать как это любовно и прельстиво шифровать диски целиком, и мы с тобой перейдём к обсуждению вопроса о том, существуют ли случаи, когда шифровать диски целиком -- менее удачное решение, чем шифровать данные на уровне приложения.
