Доступен (https://github.com/zboxfs/zbox/releases/tag/0.1.2) первый выпуск новой файловой системы Zbox (https://github.com/zboxfs/zbox/), ориентированной на обеспечение конфеденциальности хранения данных в приложениях. Код Zbox написан на языке Rust и распространяется (https://github.com/zboxfs/zbox/) под лицензией Apache 2.0. Проект находится на стадии активной разработки, поэтому стабильность пока не гарантируется.
Zbox относится к категории встраиваемых ФC, предоставляющих слой для шифрованного доступа к файлам на уровне приложения. Подобный подход требует специальной адаптации программ для работы с Zbox, но избавляет от необходимости установки компонентов ФС в операционной системе и защищает канал передачи данных между приложением и операционной системой.
Zbox осуществляет хранение данных в форме зашифрованного репозитория, доступ к которому могут получить только авторизированные приложения, которые могут работать с содержимым Zbox как с традиционной файловой системой. Для остального мира хранилище Zbox представляет собой черный ящик. Хранилище не обеспечивает совместный доступ для разных процессов - каждый экземпляр Zbox работает только в адресном пространстве приложения, в каждый момент времени операции с ФС может выполнять только один процесс. Для хранения репозитория Zbox может использоваться как любые штатные системные ФС, так и оперативная память, СУБД и NoSQL-хранилища в формате ключ-значение (поддержка ожидается в будущих выпусках).Основные возможности:
- Полное шифрование информации, включая метаданные и структуру каталогов;
- Применение для шифрования и хэширования алгоритмов AES-256-GCM (hardware), XChaCha20-Poly1305 и Argon2 в реализации библиотеки libsodium;
- Поддержка дедупликации повторяющихся данных как на уровне содержимого отдельных блоков, так и на уровне целых файлов;
- Сжатие данных с использованием алгоритма LZ4;
- Гарантирование целостности данных, благодаря применению методов аутентифицированного шифрования (AEAD (https://ru.wikipedia.org/wiki/AEAD-%D1%80%D0&...
- Поддержка снапшотов;
- Версионирование содержимого файлов;
- Семантика в режиме Copy-on-write (COW);
- Соответствие транзакций требованиям ACID (https://ru.wikipedia.org/wiki/ACID);- Возможность работы поверх различных типов нижележащих хранилищ и СУБД;
- Реализация на языке Rust, предоставляющем средства для безопасной работы с памятью.
Сравнение с системами шифрования на уровне диска (VeraCrypt) и ОС (EncFS, APFS, ZFS):Zbox
Реализации ФС на уровне ОС
Системы дискового шифрования
Шифрование содержимого файлов
✔️
частично
✔️
Шифрование метаданных
✔️
частично
✔️
Шифрование каталогов
✔️
частично
✔️
Контроль целостности данных
✔️
частично
✖️
Совместный доступ нескольких процессов
✖️
✔️
✔️
Дедупликация
✔️
✖️
✖️
Сжатие
✔️
частично
✖️
Семантика COW
✔️
частично
✖️
Транзакции ACID
✔️
✖️
✖️
Многослойное хранилище
✔️
✖️
✖️
Доступ через API
✔️
через VFS
через VFS
Символические ссылки
✖️
✔️
зависит от нижележащей ФС
Пользователи и контроль доступа
✖️
✔️
✔️
Поддержка FUSE
✖️
✔️
✔️
Поддержка Linux и macOS
✔️
✔️
✔️
Поддержка Windows
✖️
частично
✔️URL: https://github.com/zboxfs/zbox/releases/tag/0.1.2
Новость: http://www.opennet.me/opennews/art.shtml?num=47716
Всех благ проекту! За Раст + в карму.
Смущают крестики напротив "Совместный доступ нескольких процессов", "Пользователи и контроль доступа" и "Символические ссылки". Надеюсь, что онм просто WIP.
Похоже из всей новости ты прочел слова "файловая система" и посмотрел табличку
он ещё увидел слово Rust
Не совсем пойму, реентарабельна ли эта штука?
В табличке можно все кресты в колонке 'Системы дискового шифрования' заменит на 'зависит от нижележащей ФС', софтовый raid и аппаратная виртуализация уже с нами, ничего нового ^это не дает
> ничего нового ^это не даетНовое всегда хорошо?
Тогда в чем профит
> Тогда в чем профитЯдерной войны ещё не было. Новое, чо!
Такая крутотень, ещё и на Расте, прям фантастика. Жаль, что на десктопе её не поюзаешь.
> Такая крутотень, ещё и на Расте, прям фантастика. Жаль, что на десктопе
> её не поюзаешь.Такая крутотень, только не понятно нафиг нужна. Нормальные операционки и так это все умеют.
> защищает канал передачи данных между приложением и операционной системойЧитай внимательно, брат Аноним.
> Читай внимательно, брат Аноним.Прочитал. Еще и приложения надо переписывать? Всю жизнь мечтал.
Вот ЛИЧНО ВАМ, от раста в файловой системе какой прок?
> Вот ЛИЧНО ВАМ, от раста в файловой системе какой прок?Автоматическое управление памяти встроенное в язык, этого достаточно, чтобы приложения связанные с обеспечением шифрования писались только на нем. Ну и высокий порог вхождения в язык как один из факторов.
Кажется это было в С++11\14
> Автоматическое управление памяти встроенное в язык, этого достаточно, чтобы приложения
> связанные с обеспечением шифрования писались только на нем. Ну и высокий
> порог вхождения в язык как один из факторов....а потом Intel встраивает бекдор в процессор и хана твоему шифрованию.
>> Автоматическое управление памяти встроенное в язык, этого достаточно, чтобы приложения
>> связанные с обеспечением шифрования писались только на нем. Ну и высокий
>> порог вхождения в язык как один из факторов.
> ...а потом Intel встраивает бекдор в процессор и хана твоему шифрованию.Ну, если ты на сях или плюсах напишешь тогда интел обломается с бэкдором, получается?
дадада, ручное управление памятью это изи стайл, а на С/С++ вообще одни несерьезные дяди пишут
Ну, просто время ваше вышло, через несколько лет вымрете как перловоды, а раст будет в тренде, видно что язык взлетает. Не думай, что я тебя троллю только, можешь скринить, все так и будет.
я фразочки "Си вымрет благодаря Расту" уже лет 7 слышу, пока 0 шагов в этом направлении вышло. Подождем еще 7, а потом посмеемся. И да, Перл по-прежнему в 100 раз популярнее Раста. Хороший перловик за 3 дня найдет работу хоть в России, хоть в Европе (особенно в бриташке), а кому нужны растеры, их вообще кто-то хайрит?
> я фразочки "Си вымрет благодаря Расту" уже лет 7 слышуРаньше была ява и дотнет. Которые не тормозят и вообще могут офигенно оптимизировать код прямо под вот этот проц. Где-то там, в теории. У хипстеров стадный инстинкт и потому падкость на хайп.
я такое лет 10 назад про Ruby слышал...
> я такое лет 10 назад про Ruby слышал...ужо 25 лет слышу,ка оно вымирает.Каждые 5 лет вымирает.Ада,D,руст,питон,го ....
Потрясающее заявление - "вымрет курица(С,C++), которая несет яйца (языки более высокого уровня)". И такие граждане называют себя программистами?? :)
> Потрясающее заявление - "вымрет курица(С,C++), которая несет яйца (языки более высокого
> уровня)". И такие граждане называют себя программистами?? :)Наверное, те, кто не хочет, чтоб им как тебе вынесли яйца?
А что, у вас какие-то проблемы с яйцами, что заставило два добавить в ник? Раст это уже другая птица нового вида эволюционирующая и пока живородящая, лет через десять будет понятно какие яйца она снесёт, но уже сейчас ясно, что не простые. Минус плюсовой курицы в том, что она склевывала себе лапки рано или поздно, в растовую добавили гмо и теперь чтобы заставить её склевать их нужно спецом намазать их мёдом.
> Ну, просто время ваше вышло, через несколько лет вымрете как перловоды,Свежо предание. И лет ему столько же сколько яве и дотнету, если не большй. Но почему-то ты не рвешься пользоваться операционками и системным софтом на этом.
> Автоматическое управление памяти встроенное в язык, этого достаточно, чтобы приложения
> связанные с обеспечением шифрования писались только на нем....так что криптографические примитивы будут обладать непредсказуемыми свойствами, что подставит шифрование там и тут.
А автоматическое управление памятью позволит давно уже не нужному ключу застрять в памяти на полчаса, или когда там GC раздуплится. Ну а что, позаботимся об атакующих. Если ключ в памяти всего 2 секунды - припершийся наудачу атакующий мог и не успеть его сдампить. Это ж форменное свинство по отношению к атакующим.
> А автоматическое управление памятью позволит давно уже не нужному ключу застрять в
> памяти на полчаса, или когда там GC раздуплится.Интересно, откуда уважаемый Ыксперт GC в контексте раста взял? Отсутсвие GC как раз главная фишка этого управления и мусолится с наслаждением хипстерами в каждой новости.
Правда, любители смузи почему то скромно умалчивают тот факт, что автоуправлялка только не даст забыть вставить free, но вот понимать, где и как их нужно было бы расставить, для написания кода все так же необходимо.> Ну а что, позаботимся об атакующих. Если ключ в памяти всего 2 секунды -
> припершийся наудачу атакующий мог и не успеть его сдампить. Это ж
> форменное свинство по отношению к атакующим.Представитель славного племени Ыкспертов опеннета разве не в курсе, что вызванный ручками free тоже не уберет ключ из памяти? Его желательно сразу после использования занулить.
А еще, не менее желательно, чтобы ключ и не только не попали в своп, так что man mlock.
> Интересно, откуда уважаемый Ыксперт GC в контексте раста взял? Отсутсвие GC как
> раз главная фишка этого управления и мусолится с наслаждением хипстерами в каждой новости.Да какая нафиг разница? В крипто очень желательно именно ручное упрвление всем и вся. Чтобы ключ жил ровно столько сколько нужен. Чтобы все операции завершались именно так как задумал криптограф, да еще и за постоянной время. А чем больше рантайм пытается умничать, тем больше там будет факапов. Крипто штука деликатная, даже обычный memcmp() в половине случаев оказывается дырой. Он видите ли вываливается за разное время при разном результате, что позволяет побуквенно подобрать 20-символьный пароль, угадывая по букве за раз. И так везде.
Поэтому если какая-то макака верит что автоматика в крипто рулит - эта макака ничерта в крипто не понимает, для начала. Это просто индикатор криптоламера, который не понимает что творит.
> Правда, любители смузи почему то скромно умалчивают тот факт, что автоуправлялка только
> не даст забыть вставить free, но вот понимать, где и как их нужно было бы расставить,
> для написания кода все так же необходимо.Более того, в крипто они с этим налажают по черному и у криптоалгоритма будет пара дюжин нежелательных свойств, так что атакующие чего доброго смогут взламывать это каким-нибудь оригинальным методом, про который криптоламеры даже не задумывались.
> Представитель славного племени Ыкспертов опеннета разве не в курсе, что вызванный ручками
> free тоже не уберет ключ из памяти?Поэтому кроме всего прочего, важные регионы памти протирают явно. Автоматика же в этом начинании может только помешать и нагадить.
> Его желательно сразу после использования занулить.
Спасибо, Кэп.
> А еще, не менее желательно, чтобы ключ и не только не попали
> в своп, так что man mlock.Как будто я про него не знаю, кэп...
Гораздо меньшее количество багов и дыр
Шёл 2017 год. Наивные анонимы всё ещё думают, что от языка что-то зависит.
…сказал аноним, стабильно ругающий иные проекты за то, что их авторы выбирают PHP.
> …сказал аноним, стабильно ругающий иные проекты за то, что их авторы выбирают
> PHP.Сказал аноним, который думает, что я тот аноним. Я не языкофоб\тулкитофоб, в отличии от других. Мне плевать на чём они пишут, лишь бы работало. Другое дело, что криворукие программисты даже на Rust\GO\Java наделают кучу дыр, от языка это ну никак не зависит. А ещё есть хардварные бэкдоры и скомпрометированные системы, так что это управление памятью только помощь программисту, но никак не панацея.
> Другое дело, что криворукие программисты даже на Rust\GO\Java наделают кучу
> дыр, от языка это ну никак не зависит.Ты нуб и опозорился. От языка очень зависит количество дыр и багов. Когда компилятор не даёт заблудиться в указателях, это очень способствует качеству программ. А твоя акцентуация на криворуких программистах наталкивает на мысль, что мосье перфекционист чахнет над каждым глюком программы.
> баговАга, особенно багов, конечно. А программисту, конечно, голова на плечах не нужна, чтобы писать программы. Программа отжирает гигабайты памяти? Да так всё и должно быть! Это нормально! Мы тут тебе дерьма набросали в коде, но всё зашибись!
Тоже самое и про дыры. Если писать на отвяжись, то конечно можно дыр наделать в любом коде. А ещё я тебе по секрету скажу, что вся низкоуровневая фигня в расте пишется именно в блоке с "небезопасным" кодом. А файловые системы именно низкоуровневые. Делай выводы.
Это уже какая-то истерика. "Аааа, ты посмел сказать, что язык влияет на среднее качество программ на нём!!!! Это што теперь получается, садись обезьяна и пиши нормальный код??????77777". Это что, батхёрт извозчика при виде автомобиля?
Продолжим? В твей любимой ржавчине используются указатели во все поля. Не веришь?https://doc.rust-lang.org/book/second-edition/ch15-00-smart-...
> Smart pointers, on the other hand, are data structures that act like a pointer, but they also have additional metadata and capabilities. The concept of smart pointers isn’t unique to Rust; it originated in C++ and exists in other languages as well.
И тут они как бы намекают, что этот язык - велосипед.
> Когда компилятор не даёт заблудиться в указателяхДа что вы заладили со своими указателями. Тут у некоторых [смотрит в соседнюю статью] простой `require_once "http://..."` позволяет выполнить код, хостящийся на другом сервере, а вы всё про указатели. Не умеете указатели, пишите на яве.
ИЧХ, снова язык (ЯП) плохой, а не голова и руки.
> От языка очень зависит количество дыр и багов. Когда компилятор не даёт заблудиться в указателях, это очень способствует качеству программ. А твоя акцентуация на криворуких программистах наталкивает на мысль, что мосье перфекционист чахнет над каждым глюком программы.Сначала вам нужен интерпретатор который за вас разобреться где причина, а где следствие. Вам же это не удалось. Хотя лучше таким интерпретатором (ИИ) сразу заменить вас.
Разумеется, зависит. Ламер что ли?
> Разумеется, зависит. Ламер что ли?Я теперь молча буду тыкать на эту станицу: https://doc.rust-lang.org/book/second-edition/ch19-01-unsafe...
Любая обезьяна может сломать что угодно даже в Rust.
> Я теперь молча будуХорощо
Спец и на небезопасной™ сишечке норм напишет, а макаке только пересадка рук на плечи поможет.
Быть спецом в программировании и быть спецом в героическом преодолении граблей сишечки - несколько разные вещи, и всем будет лучше, если вторые спецы уйдут в прошлое.
Тем не менее на расте пишут 1.5 гика, на С весь мир.
По этому весь мир в ж...
> По этому весь мир в ж...Во!
Так вот в чём первоанальность мира!
> Так вот в чём первоанальность мира!Макофилы с этим поспорят.
Мощный аргумент
> Быть спецом в программировании и быть спецом в героическом преодолении граблей сишечки - несколько разные вещи, и всем будет лучше, если вторые спецы уйдут в прошлое.Тут такое... часто эти две области совпадают. Лично я не встречал спеца в программировании, который хотя бы на базовом уровне не умел сишечку.
А "грабли сишечки" пытаются преодолевать именно создатели всяких C++ и растов: "в си для нас много непонятного, поэтому давайте создадим свой язык, в котором нам будет понятно всё".
> Тут такое... часто эти две области совпадают. Лично я не встречал спеца
> в программировании, который хотя бы на базовом уровне не умел сишечку.То, что эти две области часто совпадают - суровая неизбежность в силу распространённости сишки, а не свидетельство того, что сишка прекрасна.
> не свидетельство того, что сишка прекрасна.это свидительство того, что те, кто умеют программировать, особых проблем с сишкой не имеют.
Они совпдаают потому что для того чтобы сколько-нибудь долго писать на сях нужно обладать некоторой базой, и эта же база нужна чтобы вменяемо программировать в принципе, во всяком случае в никсах, которые на C написаны.Ну, то есть я верю, что могут быть люди, понимающие, как организована память, как работают сисколлы, треды и прочее, но при этом C не умеющие - но никогда таких не встречал. Потому что в никсах всё это, собственно, на C и изложено, даже в манах и доках.
> Ну, то есть я верю, что могут быть люди, понимающие, как организована
> память, как работают сисколлы, треды и прочее, но при этом C
> не умеющие - но никогда таких не встречал.Это была бы экзотика. А вот хипстеры в этом ни в зуб ногой. А вот всего непонятного и неизвестного человек как известно боится. Поэтому хипстеры судорожно ищут инструменты и фреймворки которые позволят что-то делать, не понимая как работают компьютеры. Что-то делать конечно можно и так, но вот мысль о том что дрессированные макаки смогут заменить специалистов которые понимают - это wishful thinking макак.
Ну, конкретно в плюсах к этому подошли куда более вменяемо, по факту просто навернув слой абстракций сверху и явно заявив: "вот пачка инструментов, выберите те, какие вам нужны и пользуйтесь неправильных там нет, есть только неподходящие для вас".Собственно, что в борцах за раст/хаскелл/питон/го/whatever разражает больше всего - то, что они претендуют на то, что знают ответы на все вопросы в рамкакх какого-то одного подхода.
В них больше всего раздражает то что програмер считается фееричным кретином, которому даже зубочистку нельзя доверить из опасений что он выколет себе глаз.
> Спец и на небезопасной™ сишечке норм напишет, а макаке только пересадка рук
> на плечи поможет.Пересадка мозга же. Кстати, далеко не все макаки с разбега догадаются в чем подвох, а потом уже поздняк.
>> Жаль, что на десктопе её не поюзаешь.В чем проблема? Все современные ОС поддержаны
Нет симлинков и совместного доступа
В хранилище данных в форме зашифрованного репозитория?
Возможно придётся сменить имя файловой системы, эта торговая марка ZOTAC.
Zfs умеет в дедупликацию же, нет?
Sqlite же встравиваемая БД, или нет?
NTFS же вроде на винде только, или нет?
Создатель ReiserFS вроде в тюрьме сидит, или нет?
> Создатель ReiserFS вроде в тюрьме сидит, или нет?Сидит. Нечего было выбрасывать исключения при взаимодействии с русской женой.....
> Нечего было выбрасывать исключения при взаимодействии с русской женой.....Она FreeBSD любила.
Оправдать!
Нет.
>ZfsНа десктопе и смартфонах не годится. Ждем Bcachefs.
А чем не годится на десктопе внезапно?
на десктопе для оперативки найдутся более важные задачи, котиков в браузере скроллить, например
без дедупликации жрёт меньше браузера
> без дедупликации жрёт меньше браузераВ наше время "меньше браузера" вообще ничего не значит.
А сколько ж у тебя на десктопе оперативки и дисков? Ибо гиг на тер - это не так много сегодня.
> гиг на терА нафига вы на десктопе дедупликацию включаете?
А кто сказал, что я ее включаю?
Указанное соотношение позволяет zfs комфортно и шустро работать без дедупликации, с нормальной работой ARC.
> Указанное соотношение позволяет zfs комфортно и шустро работатьНу вот: ей позволяют. Чё ж она не работает?
> Указанное соотношение позволяет zfs комфортно и шустро работать без дедупликации, с нормальной
> работой ARC.Единственной небольшой проблемой является вылет приложений к чертовой бабушке при попытке выделить себе память в системх где ARC не интегрирован с управлением памяти ядра. Это пофиг для файлсервера, но вот на десктопе уже не то.
Юзай squanshFS
ну рас вы тут все таки остряки и умники, и zfs умеет в дедупликацию, какого черта в таблице крестик стоит в колонке "Реализации ФС на уровне ОС"?
> Zfs умеет в дедупликацию же, нет?Умеет, но только блочную.
"Кусками произвольной длины" может быть сильно эффективнее - при "сдвиге" данных даже на один бит все блоки будут другие, а вот кусками (сhunks, см. rolling hash) это вполне локализуется.Другое дело, что оно таки (сравнительно) небыстрое¹, нужны индексы (которые могут неплохо жрать память) и прочее.
Ну и стоит осознавать недостатки таких систем - к примеру, при бэде в часто используемом кусочке, северный пушистый лис придет к целой куче файлов.
Зато "снапшоты" практически встроенные и вообще, очень подходит для тех же инкрементальных бэкапов, передаче по сети и прочем (см. rsync, zsync, zbackup, borg).
дедупликация дорогое дело, у вас есть бабла на примерно 128 гигов оперативы и соответственно сервак способный их использовать?
дедупликация не нужна и вредна, так как один сбой рушит ваш уютный архивчик в гумус. на фоне тех многотерабайтных винтов вообще скоро будет рудиментом для придурков.
> дедупликация дорогое дело, у вас есть бабла на примерно 128 гигов оперативы
>> нужны индексы (которые могут неплохо жрать память) и прочее.
> дедупликация не нужна и вредна, так как один сбой рушит ваш уютный архивчик в гумус
>> Ну и стоит осознавать недостатки таких систем - к примеру, при бэде в часто используемом кусочке, северный пушистый лис придет к целой куче файлов.Я так понимаю, классическое опеннетное "не читал, но отвечаю"?
Зато циферки от балды про гигабидзы памяти (на самом деле, при нормально выбранных параметрах, тот же дедупликатор zbackup жрет ~1ГБ рамы на 1ТБ данных) и размышлизмы про ненужность и вредность тех же снэпшотов и рефлинков в ZFS/BTRFS (или незнание принципа работы COW-ФС?) из-за многотерабайтных винтов ...
> Зато циферки от балды про гигабидзы памятидитё, ты видел и щупал за влажное вымя сервера, например sun m5000 забитые под завязку и массивы под петабайт? сиди тихо попой на стуле.
Культ потребяства случается и у админов...
> Культ потребяства случается и у админов...это так называемая бигдата, я больше архитектор чем админ.
хотя да, и админ тоже,уже более 30 лет. (а ума всё нет -- шутка)
по поводу дедуплекации - полная фигня, тормоза, пользы ноль.
всю ту ересь что несли оппоненты - оно полезно для бэкапов.
оппоненты просто не имели делов с такими объёмами, тут бэкапы не катят.
попробуйте сбэкапить даже 600 терабайт массив в приемлемое время?
по поводу ZFS очень перспективная, но оракакель её старательно похоронил.
Хорошо, что есть иллюмос и проект ZOL.
уроды оракакель развивают свою глючную недоделку бтрфс.
> это так называемая бигдата, я больше архитектор чем админ.Если бы ты был действующим архитектом то стеснялся бы гордиться такой "архитектурой".
Архитектуре есть смысл учиться у гуглов и фэйсбуков, коинов, торентов, амазона, CDNов и т.п. - они покажут как далать очень большие структуры очень надежно, бесконечно масштабируемо и без дорогого оборудования.
> хотя да, и админ тоже,уже более 30 лет. (а ума всё нет -- шутка)
В каждой шутке лишь доля шутки.
> попробуйте сбэкапить даже 600 терабайт массив в приемлемое время?
Сама постановка проблематики выдает факап с архитектурой и прожектменеджментом. О чем горе-фирма узнает когда например пожар в ДЦ или что там там еще вынесет хню на 600 терабайтов за раз. И сколько потом все будет в дауне? И что случится с продакшном, когда это уйдет в даун? Там случайно не упадет все живое?
> уроды оракакель развивают свою глючную недоделку бтрфс.
У нее на уровне архитектуры возможности поинтереснее будут. Например разные уровни RAID для разных файлов. Кто еще так сможет? Там как раз задались на уровне архитектуры сделать менеджмент менее утомительным и более логичным. В отличие от всех остальных.
> О чем горе-фирма узнает когда например пожар в ДЦу нас три ДЦ разнесённых территориально и данные зеркалируются, по сути это RAID1. Так что мне плевать на ваше некомпетентное мнение.
> у нас три ДЦ разнесённых территориально и данные зеркалируются, по сути это
> RAID1. Так что мне плевать на ваше некомпетентное мнение.С нетерпением ждем новых гуглей и фэйсбуков на ваших мощностях.
> у нас три ДЦ разнесённых территориальноДержатель локалхоста в трёхкомнатной квартире?
>> Зато циферки от балды про гигабидзы памяти
> дитё, ты видел и щупал за влажное вымя сервера, например sun m5000
> забитые под завязку и массивы под петабайт? сиди тихо попой на стуле.А в огороде бузина, дедуля?
Ну ка, покажи мне планшеты и ноуты с "массивами" хотя бы под пару терабайт. Мир, внезапно, не ограничивается серверами (и даже там в ходу не только древности и файло-тырьпрайс).
Хотя, о чем это я. Дедуле похоже не хвататет внимания прочесть и осмыслить -- приходиться высматривать знакомые слова и отвечать, додумав остальное?
Или просто хотелось просто похвастаться доступом к оборудованию за стопицот денег?
А где сравнительный тест с lvm+luks ext4 и xfs?
Не думаю, что в этом есть смысл. Это не то, чтобы настоящая файловая система, это просто некое хранилище (хз как оно выглядит извне, может директория, может файлик...), с неким интерфейсом для приложений, чтобы они могли с ним работать, как с обычной ФС.То есть связки luks+lvm и lvm+luks оно не заменит -- это именно что абстракция на уровне приложения.
Они написали какую-то примитувную СУБД с шифрованием на расте и назвали её файловой системой, я правильно понял?
Всё верно. Крайне странно видеть сравнение с VeraCrypt и обычными FS. Я бы скорее ожидала увидеть сравнение с SQLite.
> Я бы скорее ожидала увидеть сравнение с SQLite.так первым же вопросом было бы - ну и как у вас производительность "в сравнении с sqlite". А на него может получиться очень неудобный для вчера-прочитал-книжку-по-rust,сегодня-я-у-мамы-мастер-файловых-систем ответ.
Правда, за сравнение надо заплатить $2k, see ни разу не халявна, но, если данные не стоят столько, они, скорее всего, вообще ничего не стоят.
> Они написали какую-то примитувную СУБД с шифрованием на расте и назвали её файловой системой, я правильно понял?Во. Это кстати очень дельное замечание. Никакая это не ФС.
> AES-256-GCM (hardware)256 > 128, поэтому так якобы надёжнее, и пофиг на тормоза?
>> AES-256-GCM (hardware)
> 256 > 128, поэтому так якобы надёжнее, и пофиг на тормоза?Мистер Одинокий Лось: 256 лучше 128, т.к. больше цифр. Разве не очевидно, а процессор все равно простаивает, так от него хоть польза будет. А то только жрет электричество понапрасну. На сэкономленные деньги сможешь купить больше водки и порадовать свою скво ремнем или кочергой.
в какую цену биткойн у вас в прошлом? потерпите малость, процы с aes уже на подходе
> в какую цену биткойн у вас в прошлом? потерпите малость, процы с
> aes уже на подходеAes не поможет в майнинге биткоинов. Там sha256 в основном надо. И то - вон там фотка фермы в исландии, склад забит майнерами на основе ASICов, где каждый кристалл - массив специализированных считалок хэшей. Твой проц на фоне ASIC - ничто.
> 256 лучше 128, т.к. больше цифр. Разве не очевидноШнайеру не очевидно. Кто я такой, чтобы мне в таком случае было очевидно?
Если ты думаешь что разница в производительности между 128 и 256 - два раза, то ты ошибаешься, она много меньше.
10 раундов против 12. И вроде что то на этапе инита различается, но врядли тут инит происходит более одного раза.
> 10 раундов против 1214. 12 раундов в AES-192. То есть почти в полтора раза медленнее, но при этом для сопоставимой с AES-128 стойкости к алгебраическим атакам надо было бы ещё пяток раундов добавить.
>> AES-256-GCM (hardware)
> 256 > 128, поэтому так якобы надёжнее, и пофиг на тормоза?вы сравните sha256 и sha512 - сильно удивитесь
А ты сравни зелёное с глубоким, тебе не привыкать.
Нафига это нужно? Это может работать только в сочетании и бекдорнутым SGX и ему подобными. Если ОС скомпрометирована, а на десктопах - даже в чистой ОС с вредоносной программой с правами того же пользователя, то нет проблем прочитать ключ из оперативной памяти. Если же ОС не скомпрометирована, то она разграничивает права сама, и использование этой фигни создаёт лишние проблемы.
> Если ОС скомпрометирована, а на десктопах - даже
> в чистой ОС с вредоносной программой с правами того же пользователя,
> то нет проблем прочитать ключ из оперативной памяти.
> с правами того же пользователя,Если этот пользователь рут?
А то ведь даже под форточками нужне доп. права на считывание памяти не дочерних процессов.
> А то ведь даже под форточками нужне доп. права на считывание памяти
> не дочерних процессов.Не нужны. Пунтосвитчер работает без рута.
>> Если ОС скомпрометирована, а на десктопах - даже
>> в чистой ОС с вредоносной программой с правами того же пользователя,
>> то нет проблем прочитать ключ из оперативной памяти.
>> с правами того же пользователя,
> Если этот пользователь рут?А если диск выкрутить?
>>> то нет проблем прочитать ключ из оперативной памяти.
>>> с правами того же пользователя,
>> Если этот пользователь рут?
> А если диск выкрутить?И?
ЗЫ: опять кто-то минусо-бота на тему натравил и этот кто-то совсем не палиЦЦо)
>>>> то нет проблем прочитать ключ из оперативной памяти.
>>>> с правами того же пользователя,
>>> Если этот пользователь рут?
>> А если диск выкрутить?
> И?
> ЗЫ: опять кто-то минусо-бота на тему натравил и этот кто-то совсем не
> палиЦЦо)Вот как запретят Анониму жмакать на минусы, тогда обсудим.
А пока эти дятлы жмут на минусы от своей тупости. И плюсуют идиотские высеры на два слова.
>> Если ОС скомпрометирована, а на десктопах - даже
>> в чистой ОС с вредоносной программой с правами того же пользователя,
>> то нет проблем прочитать ключ из оперативной памяти.
>> с правами того же пользователя,
> Если этот пользователь рут?
> А то ведь даже под форточками нужне доп. права на считывание памяти
> не дочерних процессов.а если ето анальный зонд интель МЕ?
> Нафига это нужно?Вот смотри. Купил ты ноут, поставил на него ff и радостно начал лазать по сайтам. FF тебе в этом помогает как может -- запоминает запомненные логины, пароли, заполненные формы, хранит историю, кеширует интернет, бла-бла-бла... И тут ты хоп и потерял ноут. А Вася его нашёл. Вася открыл твой ноут, посмотрел на него, загрузил с флешки обошёл пароли системы, и видит что у тебя в домашней директории лежит ~/.firefox, а там профили со всякой разной информацией. И тут ты выясняешь, что потерял не только ноут, но ещё и деньги с кредиток, и несколько важных для тебя аккаунтов на различных ресурсах.
А вот если бы ff пользовался чем-то типа Zbox для хранения своих файлов, то Вася бы обрёл только ноут, но не сенситивную информацию. Это, правда, требовало бы от тебя вводить мастер-пароль в ff каждый раз, когда ты его запускаешь, но может быть оно того стоит всё же?
> бла-бла-бла... И тут ты хоп и потерял ноут. А Вася его
> нашёл. Вася открыл твой ноут, посмотрел на него, загрузил с флешки
> обошёл пароли системы, и видит что у тебя в домашней директории
> лежит ~/.firefox, а там профили со всякой разной информацией. И тути лежит там полеживает прекрасный такой файлик key3.db
И пользы от него - никакой.Но да, надо вводить master password.
там, правда, по-моему по сей день 3DES онли из-за бага в libnss, но для паролей должно хватить.
> и лежит там полеживает прекрасный такой файлик key3.dbНе только. Там ещё лежит история, заполненные формы и кукисы.
>> и лежит там полеживает прекрасный такой файлик key3.db
> Не только. Там ещё лежит история, заполненные формы и кукисы.ну так не оставляй истории на сайтах, которые неправильно делают формы с номерами кредиток (лучше бы по таким и вовсе не ходить, мало ли что еще они делают через задницу).
На нормальных они (или хотя бы cvv) не сохраняются файрфоксом, а auth cookies привязываются к ip и имеют ограниченное время действия.мазила совершенно правильно не создает ненужных трудностей тем, кто хочет что-то извлечь из собственных профилей, гемора с signons.json вполне всем достаточно.
>>> и лежит там полеживает прекрасный такой файлик key3.db
>> Не только. Там ещё лежит история, заполненные формы и кукисы.
> ну так не оставляй истории на сайтах, которые неправильно делают формы с
> номерами кредиток (лучше бы по таким и вовсе не ходить, мало
> ли что еще они делают через задницу).
> На нормальных они (или хотя бы cvv) не сохраняются файрфоксом, а auth
> cookies привязываются к ip и имеют ограниченное время действия.
> мазила совершенно правильно не создает ненужных трудностей тем, кто хочет что-то извлечь
> из собственных профилей, гемора с signons.json вполне всем достаточно.Я даже не знаю, что на это можно ответить. Смотри, мы начали с вопрос "зачем zbox может понадобиться". Я привёл пример зачем. Так? Ты начал доказывать, что в этом случае zbox не нужен, что тут правильнее было бы пользователей обучать пользоваться браузером. Допустим ты прав. И что? Ну, вот чего ты ждёшь от меня? Что я сейчас подорвусь и высосу тебе из пальца ещё один use-case для Zbox? Но я не буду этого делать, потому что вне зависимости от того, нужен ли браузеру Zbox или нет, мой пример в любом случае отлично демонстрирует идею того "зачем zbox может понадобится". Может быть zbox не лучший способ решения проблемы приватных данных в профиле firefox'а, но тем не менее это способ, причём такой, который будет работать и в венде, и в линуксе, и на андроиде, не требуя никаких особенных вещей от системной файловой системы. В том смысле, что в качестве альтернативы zbox'у можно поставить систему поверх криптованного раздела, и будет, наверное, даже лучше. Но такое решение не удастся внедрить в приложение так, чтобы то своим инсталлятором настраивало бы нужным образом любую систему, на которую приложение может быть поставлено. И все эти нюансы отлично демонстрируются моим примером use-case'а, который ты так рьяно кинулся громить своей критикой. Так что я не буду придумывать другого use-case'а, останусь при этом. Если тебя это не устраивает, ничем не могу помочь.
> Я даже не знаю, что на это можно ответить. Смотри, мы начали с вопрос "зачем 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, изначально было задумано как надо, просто очень спешили и не доделали.
Ты продолжаешь критиковать частный use-case, в слепой надежде на то, что, разгромив частный случай, ты разгромишь и общий тоже? Любопытный случай. Откуда такое застревание и неспособность изменить поведение? Может быть ff для тебя больная тема? Если так, то, соглашусь, что пример был неудачным: на нейтральном примере тебе было бы проще вычленить из частного примера общую идею.> Возвращаемся к исходному вопросу - так зачем нам эта модная поделка?
Несмотря на то, что вроде как мы нашли причину неудачности use-case'а, я всё же останусь при своём: я не буду придумывать другого use-case'а. Если тебе не справиться со своим эмоциональным отношением к ff, то это всё же твои проблемы, и решать их тебе.
> Ты продолжаешь критиковать частный use-caseтак ведь твой use-case.
Другой тебе не придумался.
Придумаешь - окажется что и там это ненужное - ненужно, потому что либо это сознательное решение разработчиков, либо уже реализовано нормально и прямыми руками, либо, как в случае с твоей первой попыткой - то и другое одновременно, то есть та часть что было необходимо - зашифрована, остальное оставлено так, чтобы было удобно пользоваться.Я вот не могу придумать реальной ситуации, когда такая штука была бы нужна вместо либо шифрования вместе с диском, либо шифрования данных отдельно от системы их хранения. Даже абстрагируясь от конкретной реализации (то есть предположим, что они сделали - хорошо).
Причем именно с позиции разработчика - у юзера нет возможности ее применять by design
(и для него существуют и работают другие решения)
>> Ты продолжаешь критиковать частный 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. А потом попробуй в каждой из этих веток реализовать шифрование потенциально чувствительных к раскрытию данных. Сравни объёмы работ, которые тебе придётся выполнить в процессе. Я заверяю тебя, когда ты это проделаешь, ты вернёшься сюда рассказывать как это любовно и прельстиво шифровать диски целиком, и мы с тобой перейдём к обсуждению вопроса о том, существуют ли случаи, когда шифровать диски целиком -- менее удачное решение, чем шифровать данные на уровне приложения.
> Ты хочешь, чтобы я придумал тебе ещё десяток юзкейсов?да что-то реального пока - ни одного.
> Шифрование диска упирается в усложнение поддержки кроссплатформенности приложения.
лолшта?
Приложению ничего об этом шифровании знать не надо - это выбор пользователя, хочет он тратить ресурсы и рисковать потерять все сразу, или нет.> Шифрование же отдельных данных упирается в длинный и сложный процесс внесения изменений в код.
в случае мазилы это одна строчка на шифруемый айтем - лишний вызов функции перед sql insert. Ахрененно сложно, конечно же, гораздо проще всосать в код неведому зверушку на расте. Дайте два.
(и да, напоминаем искателям "легких путей", что "конкурентный доступ не поддерживается", попытка запустить второй экземпляр разнесет все в клочья. Сделать это будет, кстати, не так-то и просто.)
Сложно только одно - убедить других разработчиков, что это нужно кому-то в мире кроме тебя.> возьми claws-mail, или любой другой почтовый клиент, который не шифрует аутентификационные
> данные почтовых аккаунтов и локально хранимую почтупопробуй отделить "аутентификационные данные" от почты - и тут же окажется, что и в этом случае проще использовать хоть ту же nss.
И нет, мне вот не нужна шифрованная почта, совершенно - а когда будет нужна, я обойдусь без кривых embedded решений, из которых потом ее не восстановишь.
Соответственно, вместо упрощения работы, получаем усложнение - надо отдельно на каждую операцию с fs проверять - включен ли в конфиге флаг "я параноик, ниасиливший fs-шифрование", или нет, и нужно обращаться к тем же файлам через другой api.
И отдельно с конфигом - который, кстати, может содержать что-то, что лучше бы не хранить в нешифрованном виде. И который при этом хорошо бы уметь прочитать отдельно от приложения.
>> Ты хочешь, чтобы я придумал тебе ещё десяток юзкейсов?
> да что-то реального пока - ни одного.
>> Шифрование диска упирается в усложнение поддержки кроссплатформенности приложения.
> лолшта?
> Приложению ничего об этом шифровании знать не надо - это выбор пользователя,
> хочет он тратить ресурсы и рисковать потерять все сразу, или нет.Ты продолжаешь жить в тесном мирке частных случаев.
> И нет, мне вот не нужна шифрованная почта, совершенно - а когда
> будет нужна, я обойдусь без кривых embedded решений, из которых потом
> ее не восстановишь.Отказываясь от этого, ты потерял все шансы понять. Уже видно, что абстрактные рассуждения не по плечу тебе, а обретение знаний через опыт упирается в нежелание и лень набирать опыт. Знание и понимание -- это то, что никто не может вложить в твою голову. Ни знания, ни понимание не передаются по воздуху. Единственный источник знаний и понимания в психике -- это работа данной психики, в первую очередь процесс мышления. Только ты сам может создать понимание чего-либо для себя, и никто другой не может сделать это за тебя. Ты зря поэтому надеешься, что я каким-то магическим путём вложу в твою голову своё понимание, одолевая при этом твоё сопротивление моим попыткам. Моё понимание -- это моё понимание и оно недоступно никому другому. Я могу использовать своё понимание, чтобы помочь тебе создать твоё, но это будет именно помощь, которая будет эффективной только при выраженной твоей активности, нацеленной на создание смыслов.
Ещё какие-нибудь вопросы ко мне есть?
> Ты продолжаешь жить в тесном мирке частных случаев.С другой стороны, если чрезмерно обобщать это другой крайний случай. Который не очень хорошо работает.
> в психике -- это работа данной психики, в первую очередь процесс мышления.
У поха процесс мышления просматривается в 1 сообщении из 20, и то хило.
>> Ты продолжаешь жить в тесном мирке частных случаев.
> С другой стороны, если чрезмерно обобщать это другой крайний случай. Который не
> очень хорошо работает.Да. Но в этом случае я не вижу как можно обойтись без обобщений. Любой частный юзкейс всегда можно раскритиковать. Потому что вообще любое техническое решение -- это компромисс, и поэтому его всегда можно раскритиковать. В силу общей нацеленности поха на "разгромить критикой всё" -- совершенно бесполезно поэтому придумывать частные случаи. Точнее, придумывать можно, и я придумал парочку, но мне совершенно неинтересно их излагать, потому что я заранее и чуть ли не дословно знаю, что пох мне в ответ скажет. Какие минусы он выделит, и как он будет отметать плюсы, убеждая меня что они не плюсы.
Более того, если мы зададим себе вопрос "зачем нам знать, для чего нужен zbox", то на него напрашивается ответ: чтобы вспомнить о zbox в той ситуации, когда он может оказаться полезным нам. А для этого нужно очертить класс ситуаций, в которых имеет смысл подумать о том, не будет ли он полезен. А как только мы заговорили про класс -- это уже обобщение.
> У поха процесс мышления просматривается в 1 сообщении из 20, и то хило.
Он просто слишком увлечён целью победить в споре, и когда процесс мышления начинает мешать этой цели, он отключает мышление. На условном примере -- это как если бы я доказывал, что теорема Пифагора неверна, но заглянув в доказательство почувствовал бы, что доказательство то верное, и, чтобы не признавать свою неправоту, отключил бы мышление, включил бы демагогию и начал бы всеми путями уводить топик в сторону: рисовать прямоугольные треугольники на сфере, демонстративно безуспешно искать хоть одну идеальную математическую плоскость в реальности, рассказывать про искажения пространства гравитацией, аппелировать к квантовой неопределённости и невозможности точно измерить расстояния... ну и прочими такими вещами заниматься.
> обобщений. Любой частный юзкейс всегда можно раскритиковать. Потому что вообще любое
> техническое решение -- это компромисс, и поэтому его всегда можно раскритиковать.Да. Но все-таки иногда еще бывает так что некто изобретает велосипед, при том с квадратными колесами, а потом доказывает что теперь все должны взять лопаты в руки и "исправить" дороги под правильную форму колеса. Сабж на это похож - мол, а давайте вы приложения перепишете?
За всю жизнь я видел лишь пару вещей где что-то такое могло быть полезно. Специфичных. Несколько в ином виде. И не на rust. Оно к чему-то кроме ржавчины вообще прикручивается? Ладно для вебни это пофиг. Но встраиваемая файлуха это претензия на либу, чтоли. Чуть ли не системную.
> В силу общей нацеленности поха на "разгромить критикой всё" -- совершенно
> бесполезно поэтому придумывать частные случаи.Есть некоторые исключения, он не громит бсды и солярисы, чтоли. В общем у каждого есть свои причуды и предпочтения. Это может сделать суждения необъективными. В особо клинических случаях человек не может распознать ситуацию и получается упертый баран. У поха это в 9 случаев из 10.
> скажет. Какие минусы он выделит, и как он будет отметать плюсы,
> убеждая меня что они не плюсы.На самом деле всегда можно и пару плюсов найти,
> этого нужно очертить класс ситуаций, в которых имеет смысл подумать о
> том, не будет ли он полезен. А как только мы заговорили
> про класс -- это уже обобщение.Вообще согласен. Но говоря начистоту, как мне кажется сабж если и реально куда-то прикрутить, то это какие-то экзотичные и нишевые случаи. Настолько, что само знание о том что есть такая штука начинает напоминать спам про онлайн казино. Я конечно благодарен что до меня донесли знание что есть такое казино, но не могу придумать куда мне это знание деть. Но я допускаю что кому-то это знание будет полезнее чем мне.
> Он просто слишком увлечён целью победить в споре, и когда процесс мышления
> начинает мешать этой цели, он отключает мышление.Я бы сказал позлее: он процесс мышления включает сильно иногда. Поэтому 9 раз из 10 это разговор слепого с глухим.
Доказать ему что-либо как мне кажется невозможно в принципе. Впрочем это очень распостраненная болезнь на территории exUSSR. Каждый эксперт во всем и истина в последней инстанции. А если потыкать палочкой "почему %s думает что %s истина" - начинаются громкие вопли, наезды и обиды. Не знаю откуда это берется, но далеко не любого человека можно раскрутить на демонстрацию логических цепочек. Большинство раскрутится на наезды и снобизм.
> За всю жизнь я видел лишь пару вещей где что-то такое могло
> быть полезно. Специфичных. Несколько в ином виде. И не на rust.
> Оно к чему-то кроме ржавчины вообще прикручивается?rust прикручивается к чему угодно. Сложнее чем C, потому что по-любому придётся на rust'е крафтить адаптер -- внешний API для библиотеки, который будет чисто #[repr(C)], но проще, или, по-крайней мере, не сложнее, чем C++.
> Вообще согласен. Но говоря начистоту, как мне кажется сабж если и реально
> куда-то прикрутить, то это какие-то экзотичные и нишевые случаи. Настолько, что
> само знание о том что есть такая штука начинает напоминать спам
> про онлайн казино. Я конечно благодарен что до меня донесли знание
> что есть такое казино, но не могу придумать куда мне это
> знание деть. Но я допускаю что кому-то это знание будет полезнее
> чем мне.Вот это может быть. В rust библиотека -- это что-то гораздо менее значимое, чем в C++. В C++ если библиотека, то значит что-нибудь весомое, над чем работали годами несколько человек. В rust пакет может, например, состоять из нескольких функций/типов работы со временем, или сводиться к генератору случайных чисел, или быть ещё чем-нибудь, что делается за два вечера одним человеком. В этом есть свои плюсы, но публиковать здесь все новинки с crates.io, конечно же, далеко не лучшая идея. И про Zbox, вероятно, не следовало писать.
Но здесь мне сложно судить, потому что мне лично эта информация была полезной. Не потому, что я сейчас рванусь использовать Zbox, а потому что есть вероятность того, что я когда-нибудь задумаюсь об его использовании. На самом деле я уже задумался об этом -- поверх этой штуки можно же сделать fuse-файловую систему, которая будет решать некоторые врождённые проблемы Zbox, и это было бы интересно сделать. Есть одна проблема -- я не знаю в точности зачем это может быть нужно. Перегнать Claws-Mail на защищённое храненение почты, не влезая в код ClawsMail вообще? Или может для того, чтобы создать решение, которое позволит пользователю, работая с любой фс, шифровать выбранные директории, храня при этом ключи на флешке или сталкиваясь с запросами паролей при первой попытке доступа? Ну, типа, утилитки командной строки вида:
encrypt [DIRECTORY] --auth-type=[password|keyfile|...]
Чтобы вызвал эту утилитку, и забыл, потому что дальше оно просто работает. При необходимости монтируется через fusermount, может быть само отмонтируется через 10 минут бездействия, а для приложений прозрачно и выглядит как заурядная директория. Не очень ясно, возможно ли приделать запрос пароля у пользователя прозрачно для приложения работающего с директорией. Более того неясно, стоит ли это делать, если это возможно... Но, я отвлёкся, я просто хотел сказать, что меня эта библиотечка реально наводит на размышления о том, как можно изменить мир.Да и вообще нравится идея иметь под рукой библиотеку, которая берёт на себя весь геморрой связанный с шифрованием. Вручную творить подобное замучаешься. Вообще писать код нагруженный криптографией не будучи экспертом в криптографии -- это совершенно не блестящая идея, но opensource библиотечка на github'е (даже если написана не экспертом), имеет достаточно шансов попасть в поле зрения экспертов и быть доведена до пристойного уровня. Таким образом, можно надеятся получить надёжную библиотеку берущую на себя вопросы создания зашифрованного хранилища в файле, которая инкапсулирует всю криптографию оставляя мне достаточно прямолинейный интерфейс типа "сделать всё хорошо", и которая будет делать всё если не совсем хорошо, то во всяком случае лучше, чем я (не являясь экспертом в криптогрифии) смогу сделать, даже потратив месяц на устранение пробелов в своём криптографическом образовании и написание кода. То есть, после того как я прочитал новость, я, по-любому, никогда не буду писать код, шифрующий файлы или sql-базы данных. Даже если мне это понадобится, я свалю всю работу на Zbox, вне зависимости от того, на чём там я буду писать -- на rust, C, python, lisp или чём угодно ещё.
Это я к тому, что мне как раз сложно понять была ли новость уместной здесь или неуместной. Это требует от меня сложных скиллов децентрации и умения представить себе, как к этому отнесётся обобщённый читатель новостей на Opennet, умения оценить количество тех, кому она была полезной. Я не могу просто полагаться на своё мнение, которое сводится к тому, что новость была мне полезной.
> rust прикручивается к чему угодно. Сложнее чем C, потому что по-любому придётся
> на rust'е крафтить адаптер -- внешний API для библиотеки,Ну и вот это вот - не, на плюсах так тоже делают, но вообще это грабли. Получаются (полу)замкнутые экосистемы которые между собой не дружат.
> Вот это может быть. В rust библиотека -- это что-то гораздо менее
> значимое, чем в C++. В C++ если библиотека, то значит что-нибудь
> весомое, над чем работали годами несколько человек.Не обязательно. Но все-таки это логически завершенная сущность. А несколько лет работы означают что она хоть кем-то хоть немного протестирована, блин, и не является откровенной домашкой по информатике очередного студебеккера.
> В rust пакет может, например, состоять из нескольких функций/типов работы со временем,
И без нескольких лет - можно будет узнать много нового и интересного. О времени, направлении его хода, числе секунд, дней в году и проч. На своей шкуре! Если это лаба по информатике - сработало у препа и черт с ним потом! А если в продакшн? Вылавливать за студебеккером все глюки наивного чукотского юноши, когда leap second накинут или daylight saving time активируется или ntpd время подбросит? В этом месте мы узнаем что качество софта не достигается за 5 минут.
> или сводиться к генератору случайных чисел, или быть ещё чем-нибудь,
И без нескольких лет окажется что горе автор не прогнал даже базовые тесты. Случайность окажется не случайной, кто угодно будет ломать супер-шифрование чуть ли не на тетрадном листочке. Известное дело.
> что делается за два вечера одним человеком.
Ты привел пару отличных примеров того что делается за два вечера одним человеком. Я воспользовался ими чтобы показать как это потом будет работать на практике, ибо плавали-знаем. Бонусом ты показал кто ЯПом пользуется и что ожидать... :\
> В этом есть свои плюсы, но публиковать здесь
> все новинки с crates.io, конечно же, далеко не лучшая идея.Вообще, такой карго-культ как мне кажется чреват. Если безбашенно подключать wannabe-либы писаные студнями за вечер, там будет глюк на глюке, а пара либ еще систему хакнет заодно при случае. Потому что автор только вчера появился и накатал ништяк. Код толком никто прочитать еще не успел, на чем кто-нибудь хитрый попробует получить профит, например. Как со всякими pip и npm. Интересно, это карго содержится столь же хипстерско-раздолбайски?
> что есть вероятность того, что я когда-нибудь задумаюсь об его использовании.
Мне когда-то была бы полезна подобная штука, но - не в таком виде. Не думаю что хипстеры с горящими глазами резко переписут кондовый с++ бинарь на мегабайты, в котором многие человекогоды.
> На самом деле я уже задумался об этом -- поверх этой
> штуки можно же сделать fuse-файловую систему,Вообще вариант. Fuse к тому же вроде достаточно кроссплатформенный.
> Перегнать Claws-Mail на защищённое храненение почты, не влезая в код ClawsMail вообще?
Проще наверное файлуху шифрованую сделать.
> Или может для того, чтобы создать решение, которое позволит пользователю,
> работая с любой фс, шифровать выбранные директории, храня при этом ключи
> на флешке или сталкиваясь с запросами паролей при первой попытке доступа?В андроиде половину этого сделали, собственно. Цепляют шифрованные блочные девайсы с юзерскими данными в диры. Немного зоопарк блочных девайсов но работает и так оверхеда мало.
> минут бездействия, а для приложений прозрачно и выглядит как заурядная директория.
Если честно, мне такое будет проще настроить средствами пингвина, почти без програмизма или с каким-то совсем минимумом оного. И наверняка там продолбов будет в 20 раз меньше.
> что меня эта библиотечка реально наводит на размышления о том, как можно изменить мир.
Это да, хорошие размышления. Но половину уже придумали раньше и даже активно используют.
> писать код нагруженный криптографией не будучи экспертом в криптографии -- это
> совершенно не блестящая идея, но opensource библиотечка на github'е (даже если
> написана не экспертом), имеет достаточно шансов попасть в поле зрения экспертовЭкспертов обычно к сожалению хватает на аудит core алгоритма. Остальное - не их. И вот там случаются ляпы. Крипто вообще штука очень деликатная, со множеством неожиданностей. Я бы сказал что там простое API и донесение как им правильно пользоваться очень важно. Как у DJB в TweetNaCl. Там трудно ошибиться даже дилетанту. А сделай api и алгоритмику как openssl - и в нем наломает дров кто угодно, на любом ЯП. Потому что для понимания что оно там делает и какие есть способы лажануться надо очень серьезно интересоваться областью. А это не про типового прикладника, которому это до кучи надо и он думает что за него дескать авторы либы подумали. А порой оказывается что фиг. И вот заметь, выдержка openssl сколько-то лет показала что это гэ. Отрицательный результат - тоже результат.
> которая инкапсулирует всю криптографию оставляя мне достаточно прямолинейный интерфейс
> типа "сделать всё хорошо", и которая будет делать всё если не
> совсем хорошо, то во всяком случае лучше, чем я (не являясь
> экспертом в криптогрифии) смогу сделать, даже потратив месяц на устранение пробелов
> в своём криптографическом образовании и написание кода.В этом месте ты решил рассказать, почему нормальная либа за вечер никак не получается. А хватит ли запала у тех кто хочет либу за вечер майнтайнить ее несколько лет, раскручивая процессы, пока эксперты не придут и юзеры не обтопчут грабли - вот это вопрос. Ведь если хотелось либу за вечер - наверное, это было не про то.
> То есть, после того как я прочитал новость, я, по-любому, никогда не буду писать код,
> шифрующий файлы или sql-базы данных. Даже если мне это понадобится, я
> свалю всю работу на Zbox, вне зависимости от того, на чём там я буду писать -- на
> rust, C, python, lisp или чём угодно ещё.А я для начала посмотрю что он из себя будет представлять через энное время. И нет ли более подходящих мне решений. А может быть, есть 20 способов сделать это проще и уже сейчас. Искренне сомневаюсь что авторы первые кто до этого додумался.
> Я не могу просто полагаться на своё мнение, которое сводится к
> тому, что новость была мне полезной.Если была - ок, нет проблем. А я был и до этого в курсе что так в принципе можно и при наличии такой задачи с практической точки зрения сделал бы например средствами операционки. Допустим файлухой в файле. Не портабельно, конечно, но говоря начистоту, я не вижу смысла защищать виндовых юзерей когда ms там нажатия кнопок собирает.
>> rust прикручивается к чему угодно. Сложнее чем C, потому что по-любому придётся
>> на rust'е крафтить адаптер -- внешний API для библиотеки,
> Ну и вот это вот - не, на плюсах так тоже делают,
> но вообще это грабли. Получаются (полу)замкнутые экосистемы которые между собой не
> дружат.Грабли -- это бездумно использовать внешние библиотеки без адаптеров. Даже если библиотека написана на том же языке, на котором пишешь ты, то всё равно стоит остановиться и подумать об адаптере -- библиотека может быть написана в ином стиле, или может быть тебе потом захочется заменить эту библиотеку другой, или разработчики поломают API этой библиотеки. Вариантов много, и прежде чем использовать внешнее API непосредственно и из разных частей программы, следует серьёзно подумать и оценить риски.
>[оверквотинг удален]
> проч. На своей шкуре! Если это лаба по информатике - сработало
> у препа и черт с ним потом! А если в продакшн?
> Вылавливать за студебеккером все глюки наивного чукотского юноши, когда leap second
> накинут или daylight saving time активируется или ntpd время подбросит? В
> этом месте мы узнаем что качество софта не достигается за 5
> минут.
>> или сводиться к генератору случайных чисел, или быть ещё чем-нибудь,
> И без нескольких лет окажется что горе автор не прогнал даже базовые
> тесты. Случайность окажется не случайной, кто угодно будет ломать супер-шифрование чуть
> ли не на тетрадном листочке. Известное дело.Если вдруг случилось, что пакет date был написан студиозисом, то работа со временем превратилась в вечное проклятье для rust-программистов? Есть crates.io, оттуда есть ссылки на github. Тебе доступна куча информации о пакете, о том как он разрабатывается, насколько широко и кем используется. Ты можешь заглянуть в issues, ты можешь посмотреть историю активности, ты можешь заглянуть в код и оценить его качество. Ты можешь взять и посмотреть в коде, каким образом там обрабатываются leap-секунды, какие алгоритмы генерации случайных чисел используются или откуда берётся энтропия. В конце-концов, ты можешь спросить в каком-нибудь сообществе, какую библиотеку лучше использовать для тех или иных задач.
Ты так рассказываешь, будто бы ты при написании кода на C++, выбираешь библиотеки не проводя исследования того, что эти библиотеки представляют себя с точки зрения качества кода. C++ отличается тем, что там слишком сложно использовать внешние библиотеки, и поэтому широко используются только библиотеки включённые в дистрибутивы. Но это приводит к другим косякам, типа regex-кода в boost, который, как внезапно выяснилось, написан в стиле C++ девяностых годов, пропитан арифметикой указателей, и вообще гумно. Много мелких пакетов, вместо единой свалки для многих пакетов, позволяют пойти и найти другую реализацию regexp'ов, которая будет обладать более высоким качеством кода. Прямо скажем, они вынудят это сделать на ранних этапах разработки программы, в тот момент когда нам понадобится подключить regexp'ы.
>> минут бездействия, а для приложений прозрачно и выглядит как заурядная директория.
> Если честно, мне такое будет проще настроить средствами пингвина, почти без програмизма
> или с каким-то совсем минимумом оного. И наверняка там продолбов будет
> в 20 раз меньше.Это быстро превратиться в костыль на костыле. Менеджмент всех этих точек монтирования, ключей к ним, inotofy-скриптов, бекапов быстро превратится в груду слабо связанных друг с другом скриптов. Такая штука может быть и будет работать, но через полгода ты забудешь как она работает, а через пять лет при всём желании не сможешь в этом разобраться. Строго и грамотно написанная программа лучше -- она продумана, там есть какая-никакая документация, хотя бы пара комментов в коде, там есть код, написанный с мыслью о том, что его кто-то будет читать.
>> что меня эта библиотечка реально наводит на размышления о том, как можно изменить мир.
> Это да, хорошие размышления. Но половину уже придумали раньше и даже активно
> используют.В программировании об этом переживать не стоит совершенно. Я тебя заверяю: всё уже написано, и всему есть аналоги. Когда опеннет стонет о том, что кругом сплошные велосипеды, то он делает это по глупости и неопытности своей, не понимая что иначе не бывает и быть не может.
Если ты будешь париться об уникальности твоей программы, ты никогда не напишешь ни одной программы. Ну или твои программы будут жертвовать функциональностью, удобством и разумностью в пользу уникальности.
> кто-нибудь этим любителям rust, что в windows шифрование встроено в ntfs
> с 2007 года - и оно по сей день ни у кого вопросов не вызывало,А должно было? Там возможность подпихнуть "recovery certificate" штатно заявлена. И юзеру это не особо заметно. Какие вопросы? Большинство хомяков и половина админов даже не заметит что их NSA отимело.
Приличные банки не сохраняют юзера авторизованным между сессиями. А неприличные не нужны.О сохраняемых паролях же я говорил: эту функциональность браузеров надо везде отключать и никогда её не использовать.
> О сохраняемых паролях же я говорил: эту функциональность браузеров надо везде отключатьмальчик с феноменальной памятью?
>> О сохраняемых паролях же я говорил: эту функциональность браузеров надо везде отключать
> мальчик с феноменальной памятью?Мальчик, знающий о keepassx2 и прочих.
чем эта и прочие помойки надежнее мазиловской хранилки? Тем что представляют особый интерес для товарищей и господ майоров всех сортов? Механизмы передачи пароля между ними и тем, во что этот пароль вводить - отличное место для третьего-лишнего.
Или шанс засветить пароль от банка, авторизуясь в порнохаб, кому что больше нравится.в общем, для параноика мальчик слишком легковерен.
> чем эта и прочие помойки надежнее мазиловской хранилки?Тем что не кривые embedded решения?
> чем эта и прочие помойки надежнее мазиловской хранилки?Тем, что им уже десяток и более лет? Тем, что они умеют в геренацию паролей по параметрам и вообще, банально удобнее, чем хранилки-велосипеды в каждом отдельном приложении? Да-да, удобсвтво пользователя и надежность взаимосвязанны. Тем, что не зависят от кривизны рук отдельной вебмакаки или очередных хипстерских переделок в настройках по умолчанию браузера? Тем, что уводилки паролей нацелены на всевозможные версии ишаков, хромых, мазил и прочих, но вот атаковать хранилку паролей обычно почему-то слабо?
Даже не знаю.> Тем что представляют особый интерес для товарищей и господ майоров всех сортов?
А хранилка в браузере не предстваляет?
> Механизмы передачи пароля между ними и тем, во что этот пароль вводить - отличное
> место для третьего-лишнего.На практике третий лишний будет либо банальной уводилкой паролей, либо хитрым Formgrabber-ом c кейлоггером, поэтому что совой о пень, что пнем о сову.
> Или шанс засветить пароль от банка, авторизуясь в порнохаб, кому что больше нравится.Открою страшный секрет — никто не обязывает хранить в хранилках действительно важные вещи. Внезапно, да? Зато можно хранить всю ту кучу второстепенных паролей, для которых в ином случае применяются те же самые/похожие пароли или пароли типа "пароль".
> в общем, для параноика мальчик слишком легковерен.
Возможно, мальчик реалист, а не форумный теоритик?
Мальчик в безопасности этой вашей самолично работал, так что такие дела.
> Мальчик в безопасности этой вашей самолично работал, так что такие дела.А я лет 7-8 регулярно анализировал малварь, начиная от уводильщиков паролей на VB5 и классики от Codesoft, вплоть до этих ваших зевсов и прочего хлама из массового спэма.
И так же регулярно наблюдал форумы скрипткиддизов и не совсем скрипткиддизов, где торговали малварью и утянутыми паролями. Такие дела, да.
> И так же регулярно наблюдал форумы скрипткиддизов и не совсем скрипткиддизов, где
> торговали малварью и утянутыми паролями. Такие дела, да.На гитхабе и поприкольнее вещицы бывают, например, https://github.com/x0rz/EQGRP - вообще совсем не скрипткидизы. Хоть и ископаемые слегка.
> Мальчик в безопасности этой вашей самолично работал, так что такие дела.Слишком спокойно спишь? Почитай вику кто такой stuxnet и прочая живность рядом.
> Да-да, удобсвтво пользователя и надежность взаимосвязанны.Говоря откровенно, удобство и безопасность в реальной жизни обычно обратно пропорциональны друг другу. Поэтому не следует использовать встроенные хранилки нигде и никогда. Они по самой своей сути являются дырой в безопасности, и вопрос только в ширине этой дыры и настойчивости желающих в неё пролезть. Даже вполне оффлайновый традиционный бумажный блокнот с записанными от руки паролями, но хранящийся отдельно от компьютера, где их используют, в большинстве случаев надёжней в этом смысле, чем софтовые хранилки на той же самой машине.
>> Да-да, удобсвтво пользователя и надежность взаимосвязанны.
> Говоря откровенно, удобство и безопасность в реальной жизни обычно обратно пропорциональны
> друг другу.Говоря откровенно, не только обычному пользователю, но и мне, использовать кнопку-генератор "сделай мне хороший пароль на 12-20 знаков и сохрани для вот этой вот странички" сильно удобнее, чем запускать отдельную программулину или же придумывать шедевры случайности "петя123321".
И в реальной жизни, обычный пользователь при отсутствии этой кнопки (и мотивации в виде пинков сверху или недавнего увода аккаунтов, не будет париться и использует или банальщину или "один пароль на все случаи жизни". Т.е. удобство в этом случае означает безопасность, неудобство означает игнорирование и забивание.> Поэтому не следует использовать встроенные хранилки нигде и никогда.
> Они по самой своей сути являются дырой в безопасности, и вопрос только в ширине этой дыры и настойчивости желающих в неё пролезть.Дык я тут как раз против встроенных хранилок "агитирую". Вы точно читали, на что отвечаете?
> Даже вполне оффлайновый традиционный бумажный блокнот с записанными от руки паролями,
Я вообще пароли от домашних вай-фая или рутера тупо на/под железку приклеиваю и не вижу в этом никакой проблемы.
Я писал не то чтобы вам персонально, но под всей веткой комментов, чтоб не повторяться по пять раз.
> Т.е. удобство в этом случае означает безопасность, неудобство означает игнорирование и
> забивание.Это решается профилактическими мерами: доведением к сведению о личной ответственности имярека за перечень возможных про=бов и нарушения правил эксплуатации вверенной техники, в кои правила входят предписания о доступе по логину и паролю. И проверочки регулярные. И наказывать без какого-либо милосердия и снисхождения. Помогает повышению понимания угроз и общей грамотности.
Не составляет большой проблемы найти практически любого специалиста почти любого уровня (кроме тех, которые и сами всё понимают, но они, как ни странно, таки сами всё понимают без объяснений) и это зачастую несоизмеримо дешевле эпического про=ба, за которым следуют потери денежные, репутационные и прочие, и уже не отделаешься увольнением вон того васи пупкина, потому что увольнением хоть даже и всего личного состава уже делу не поможешь.
>> Т.е. удобство в этом случае означает безопасность, неудобство означает игнорирование и
>> забивание.
> Это решается профилактическими мерами: доведением к сведению о личной ответственности
> имярека за перечень возможных про=бов и нарушения правил эксплуатации вверенной техники,
> в кои правила входят предписания о доступе по логину и паролю.Это имелось в виду под "пинком сверху", однако домашних пользователей пинать некому. И тут как обычно - пока петух жареный в одно место не клюнет ...
Между тем, вполне реально при прогоне очередной слитой 30тыщ-пользовательской базы за час (причем, на питоне и шел-утилитах) взломать треть паролей с помощью словаря на десяток-другой тысяч часто используемых паролей, а потом еще и увести у тройки-четверки тысяч остальные акканты, т.к. там используется один пароль для всего.Можно конечно злорадствовать и писать в комментариях "эти хомячки ССЗБ!", однако на ситуацию это особо не повлияет. Поэтому лучше уж пускай хранят второстепенные пароли в хранилке или даже браузере, чем используют один пароль везде. Стянуть их конечно можно, но при использовании мастер-пароля уже довольно нетривиально. Две трети скрипткиддизов обломятся однозначно. Плюс, защита от потери ноута/планшета, да и при угоне БД упарятся взламывать нормальный 12-15 значный пароль, который потом еще и никуда больше не подойдет.
> Это имелось в виду под "пинком сверху", однако домашних пользователей пинать некому.
> И тут как обычно - пока петух жареный в одно место
> не клюнет ...И это плохо. Благодаря, отчасти, добрым браузеростроителям. А ведь просто не надо делать людям медвежью услугу, полагаясь на прекраснодушные рассуждения о том, что они, мол, разберутся.
Не разберутся. Даже мануал не прочитают, юзеры _никогда_ не читают «руководства пользователя».
> Между тем, вполне реально при прогоне очередной слитой 30тыщ-пользовательской базы за час
> (причем, на питоне и шел-утилитах) взломать треть паролей с помощью словаря
> на десяток-другой тысяч часто используемых паролей, а потом еще и увести
> у тройки-четверки тысяч остальные акканты, т.к. там используется один пароль для
> всего.Не, ну слитые базы это совсем другая проблема. И лечить её тоже надо по-другому, чем домашнего юзера, ставшего элементом ботнета.
> Можно конечно злорадствовать и писать в комментариях "эти хомячки ССЗБ!", однако на
> ситуацию это особо не повлияет. Поэтому лучше уж пускай хранят второстепенные
> пароли в хранилке или даже браузере, чем используют один пароль везде.
> Стянуть их конечно можно, но при использовании мастер-пароля уже довольно нетривиально.
> Две трети скрипткиддизов обломятся однозначно. Плюс, защита от потери ноута/планшета,
> да и при угоне БД упарятся взламывать нормальный 12-15 значный пароль,
> который потом еще и никуда больше не подойдет.Примерно так и рассуждали, видимо, мудрецы, первыми предложившие встроить хранилку паролей в браузер. Что из этого получилось — известно. Но сложных паролей, к слову, юзеры так и не начали придумывать. И всё так же продолжают на работе записывать их на стикер, приклеенный к монитору. И мастер-пароли, в массе, не используют (даже не знают, что это такое). А при авторизации обычно ставят галочку «Запомнить меня». И утерянный ноутбук таки становится потенциальным клондайком для мелкого жулика, включая доступ к банковским данным лузера.
А ведь ларчик открывается просто: удобство и безопасность в данном контексте взаимно несовместимы. Надо выбрать что-то одно.
> и лежит там полеживает прекрасный такой файлик key3.db
> И пользы от него - никакой.Да чичас, лиса хранит параметры форм в другом файлике. И там base64-кодирование всего лишь, или что-то около того, если без мастер-пароля.
> Но да, надо вводить master password.
И многие ли настроили его? Это ты такой хитрый, знаешь что так можно было.
> запоминает ... паролиУ меня не запоминает. Потому что своему примитивному самописному шифровальщику по ГОСТ28147 я доверяю больше, чем мастер-паролю Файрфокса (если что - я читал Куртуа, не впечатлило).
> У меня не запоминает. Потому что своему примитивному самописному шифровальщику по ГОСТ28147
> я доверяю больше, чем мастер-паролю Файрфокса (если что - я читал
> Куртуа, не впечатлило).А если бы ты хоть что-то понимал в криптографии то постеснялся бы хвастаться собственным уровнем ламерства, для начала.
и зачем тут для шифрования одного файла файловая система?
> и зачем тут для шифрования одного файла файловая система?Ты заглядывал хоть раз в ~/.firefox? Сколько там файлов требуется для хранения паролей, истории, кеша, заполненных форм, и прочей информации? Ну, всяко не один, не так ли?
>> и зачем тут для шифрования одного файла файловая система?
> Ты заглядывал хоть раз в ~/.firefox? Сколько там файлов требуется для хранения
> паролей, истории, кеша, заполненных форм, и прочей информации? Ну, всяко не
> один, не так ли?Аппаратное делай
>>> и зачем тут для шифрования одного файла файловая система?
>> Ты заглядывал хоть раз в ~/.firefox? Сколько там файлов требуется для хранения
>> паролей, истории, кеша, заполненных форм, и прочей информации? Ну, всяко не
>> один, не так ли?
> Аппаратное делайТебе надо, ты и делай. Я не занимаюсь ни разработкой, ни производством железа.
> Тебе надо, ты и делай. Я не занимаюсь ни разработкой, ни производством
> железа.так ты и разработкой файрфокса не. Поэтому изменить ничего в нем не сможешь. Тем кто могут - не нужно было бы обмазываться новым, старое вполне работает.
Пользы лично тебе - ноль. Используй encfs - для "чисто на всякий случай" ее еще лет на пять должно хватить.
>> Тебе надо, ты и делай. Я не занимаюсь ни разработкой, ни производством
>> железа.
> так ты и разработкой файрфокса не.Диваны Опеннета ничего не хотят, они хотят бла-бла-бла. Цель вторична.
И что мешает файрфоксу использовать нормальные шифрующие фс при посредничестве ОС?
> И что мешает файрфоксу использовать нормальные шифрующие фс при посредничестве ОС?Как инсталлятор ff на андроиде может добиться такого посредничества ОС?
>> И что мешает файрфоксу использовать нормальные шифрующие фс при посредничестве ОС?
> Как инсталлятор ff на андроиде может добиться такого посредничества ОС?вывести окошко "установите меня на съемный флэш" ?
(не знаю, можно ли затребовать это через api)флэшка в ведроиде неотключаемо шифрована dm-crypt'ом, даже если отказаться от шифрования системной памяти (ведроид такой ведроид). Ненужное - ненужно.
> Купил ты ноут, поставил на него ff и радостно начал лазать по сайтам. FF тебе в этом помогает как может -- запоминает запомненные логины, пароли, заполненные формы, хранит историю, кеширует интернет, бла-бла-бла... И тут ты хоп и потерял ноут. А Вася его нашёл. Вася открыл твой ноут, посмотрел на него, загрузил с флешки обошёл пароли системы, и видит что у тебя в домашней директории лежит ~/.firefox, а там профили со всякой разной информацией. И тут ты выясняешь, что потерял не только ноут, но ещё и деньги с кредиток, и несколько важных для тебя аккаунтов на различных ресурсах.Это всё решается использолванием LUKS, ecryptfs или encfs без этого ещё одного велосипеда. Только для того, чтобы Вася действительно ничего не нашёл, надо включать мозг: шифровать не один лишь хомяк или отдельно взятый профиль браузера, но и своп, а также обнулять содержимое памяти при выключении.
> И тут ты хоп и потерял ноут. А Вася его нашёл.
> ...
> И тут ты выясняешь, что потерял не только ноут
> ...
> А вот если бы ff пользовался чем-то типа Zbox для хранения своих
> файлов, то Вася бы обрёл только ноут, но не сенситивную информацию.
> Это, правда, требовало бы от тебя вводить мастер-пароль в ff каждый
> раз, когда ты его запускаешь, но может быть оно того стоит всё же?У меня LUKS на весь диск, с бутом на внешнем носителе, который висит на связке ключей, с которой я не расстаюсь никогда. Если я потеряю ноут, Вася получит дырку от бублика, и мастер-пароль мне каждый раз вводить не надо. Способ стопудово рабочий. Никакие приложения адаптировать не надо.
Ну так, извините, чего ради городить огород с Zbox?
> У меня LUKS на весь диск, с бутом на внешнем носителе, который
> висит на связке ключей, с которой я не расстаюсь никогда. Если
> я потеряю ноут, Вася получит дырку от бублика, и мастер-пароль мне
> каждый раз вводить не надо. Способ стопудово рабочий. Никакие приложения адаптировать
> не надо.
> Ну так, извините, чего ради городить огород с Zbox?Ради того, что твоё наколенке выпиленное решение с LUKS невозможно включить в программу и использовать для маркетинга этой программы. Ну никак. Если только это не дистрибутив операционной системы. Попробуй написать программу, которая будет брать систему пользователя, и перепиливать её, до состояния защищённости твоей. Когда закончишь, приходи обратно, сравним насколько же было бы проще использовать Zbox.
>> Ну так, извините, чего ради городить огород с Zbox?
> Ради того, что твоё наколенке выпиленное решение с LUKS невозможно включить в
> программу и использовать для маркетинга этой программы. Ну никак. Если только
> это не дистрибутив операционной системы.Ну разве что ради маркетинга, это да.
> Попробуй написать программу, которая будет брать
> систему пользователя, и перепиливать её, до состояния защищённости твоей. Когда закончишь,
> приходи обратно, сравним насколько же было бы проще использовать Zbox.Хехе. То есть ты, Ordu, предлагаешь мне написать программу, которая возьмёт систему пользователя, и слегка реорганизует, переместив всё на люксовый диск с LVM-ом под ним? Что ж. Как на счёт поспорить на 4 ETH, что я справлюсь с этим за новогодние праздники?
Надо немного оговорить условия спора, сроки... Но имхо месяц мне тут -- это с лихвой хватит. )
> Хехе. То есть ты, Ordu, предлагаешь мне написать программу, которая возьмёт систему
> пользователя, и слегка реорганизует, переместив всё на люксовый диск с LVM-ом
> под ним? Что ж. Как на счёт поспорить на 4 ETH,
> что я справлюсь с этим за новогодние праздники?
> Надо немного оговорить условия спора, сроки... Но имхо месяц мне тут --
> это с лихвой хватит. )Ебилды будут? И .deb пакеты тоже? У меня на ноуте убунта, а на десктопе gentoo. Ещё андроид на смартфоне. Твой инсталлятор будет работать со всеми пакетными менагерами? Или это будет блоб типа NVIDIA-бла-бла-бла.run, который надо запускать от рута? Блобов лучше не надо, а дружить с пакетным менагером в процессе установки -- это must-have.
[update] Хотя не, не парься. Я всё равно не рискну воспользоваться подобной штукой, до тех пор пока её не оттестируют на зоопарке различных установок линуксов на реальном железе.
> Ебилды будут? И .deb пакеты тоже? У меня на ноуте убунта, а
> на десктопе gentoo. Ещё андроид на смартфоне. Твой инсталлятор будет работать
> со всеми пакетными менагерами? Или это будет блоб типа NVIDIA-бла-бла-бла.run, который
> надо запускать от рута? Блобов лучше не надо, а дружить с
> пакетным менагером в процессе установки -- это must-have.Всё будет! :)
Напишу скрипт, запуск которого приведёт систему в нужное состояние. Запакую в deb и rpm. Ебилды делать не умею, но слышал, что это вроде как просто. Андроид - однозначно нет.
Инсталлятор будет работать со всеми пакетными менеджерами. Но не потому, что будет с ними дружить, а просто потому, что по сути изменения в initrd будут доставляться через стандартный механизм его обновления, а initramfs-tools вроде везде более-менее одинаковые. Правда, в RHEL вроде внедрили какой-то dracut, но это не особо пугает. Но само собой я протестирую широкий спектр дистров, чтобы точно указать совместимые и проверенные. В первую очередь Debian-based дистры. Во вторую - RPM-based. А остальные сами скорее всего подтянутся.
Блобов не будет вообще, ручаюсь. Я всё это вообще это на shell сварганить думаю. Запускать естественно от рута, это да. И к тому же надо будет иметь дополнительно винчестер, на который будет производиться миграция текущей системы. А ты думал -- это ж весьма ответственная операция, так что исходные данные лучше не трогать. Мало ли что случится, а я не вандал.
> [update] Хотя не, не парься. Я всё равно не рискну воспользоваться подобной
> штукой, до тех пор пока её не оттестируют на зоопарке различных
> установок линуксов на реальном железе.Но ты подумай. Если я не смогу, то ты получишь 4 ETH, то есть 2000$ по текущему курсу. А если не смогу -- ты проспонсируешь разработку открытого проекта. :)
PS: а вообще, идея-то хорошая и не такая уж сложная в реализации... На кикстартер, что ли, с ней пойти? Как думаешь, выстрелит? "Напишу вам скрипт (если хотите, даже с графической обёрткой) ради вашей СВОБОДЫ". И гиганское промо из разряда "почему свобода важна, и на кой дьявол обычному казуалу шифровать свои данные". Тут некоторые наверное посмеются, но ведь действительно важно защищать свои данные.
У меня стабилизированная среда и телефон на android. Хочется некоторые данные на телефоне и рабочей среде защитить но переустановка невозможно или недопустима. Zbox мне кажется хорошим вариантом.
Интересно пощупать, как оно будет поверх WebDAV. Тогда можно будет юзать облачные файлопомойки без необходимости монтировать их и городить прокладку с шифрованием.
> Интересно пощупать, как оно будет поверх WebDAV. Тогда можно будет юзать облачные
> файлопомойки без необходимости монтировать их и городить прокладку с шифрованием.Зато придется писать свой сервак реализующий webdav и работающий с этой НЕХ. Думаешь это будет проще чем прокладку настроить?
Если бы не rust, была бы полезная штука
> Если бы не rust, была бы полезная штукаПорты на go и javascript уже в процессе, так что всё в норме.
Надо perl или haskel, чтоб было труъ.
> Надо perl или haskel, чтоб было труъ.Хипстеры очень просили питон и руби. Ну и что что тормозит, зато они только на этом умеют.
Однояйдерный?
> Однояйдерный?Моногопассесарнай
Чем это лучше просто использования какого-нибудь OpenSSL? Любое приложение и без всяких контейнеров FS может данные шифровать...
> Чем это лучше просто использования какого-нибудь OpenSSL?это - вероятнее всего, всем хуже, а в принципе готовые механизмы шифрования fs или данных лучше тем, что правильно использовать openssl - вовсе не так "просто", и требует приобретения массы ненужных знаний.
желающие могут внимательно прочитать отчет аудитора encfs (не такое уж простое ипользование openssl), а потом повтыкать в код и подумать - осилят ли они за летние каникулы то, что так и ниасилил ее автор, махнув на все рукой и сказав "а, ладно, сойдет для сельской местности, кому надо надежнее, пусть truecrypt использует"
В итоге это никто юзать и не станет.
Было бы на сишечке, может кто нибудь бы и посмотрел/подцепил, а так, растоманов мало...Плюс не понятно что там на самом деле и как работает, так то производители HDD тоже заявляли AES-256 шифрование, а потом оказалось что с помощью AES-256 шифруется только ключ который потом XOR~ится с каждым блоком.
> В итоге это никто юзать и не станет.наоборот.
> Было бы на сишечке, может кто нибудь бы и посмотрел/подцепил, а так,убедился бы что ненужно-ненужно и к тому же плохо написано, и выкинул бы.
А так - того гляди, действительно, потащат в мазилу с воплями что "nss устарел", или еще куда "давайте все пошифруем", и там, где раньше можно было удобно пользоваться sql клиентом или текстовым редактором, а то и банальными cp/rm/ln, чтобы что-то поправить или удалить от чужих глаз, придется придумывать кривые ненадежные скрипты.
см. опять же - страдания тех, кому понадобилось что-то вытащить из mozilla password store.
Зачем это, когда и так уже везде есть dm-crypt? Кто-то до сих пор не шифрует свои диски? Если только виндузоиды
Чушь все это. А если мне надо файл передать из одного приложения в другое. Упс! Дырку в боксе ковырять? И всё их поделье идет в помойку.
>Код Zbox написан на языке RustЛ. Торвальдс одобряет включение в ядро? ;)