Где-то между "хотелось-бы увидеть" и "советую написать" статью по использованию PVS с облачными CI-сервисами (Travis-CI, Circle-CI, AppVeyour). Я даже думал сам сделать (и могу помочь), но пока некогда.
P.S. Covery-Scan болеет с начала этого года. Поэтому я попробую перевести свои проекты на PVS. Ну и по-результатам запилить статейку.
Не знаю как сейчас у гугла, но (как правило) хранение хешей паролей (включая механизм восстановления) и шифрование файлов обеспечиваются разными подсистемами.
При этом данные шифруются отдельным ключом (или ключами) которые шифруются паролем и перешифровываются при его смене. Это достаточно тривиальный подход, позволяющий не перешифровывать данные при смене пароля.
У гугла может быть иначе. В том числе потому, что почта и файлы индексируются (как минимум) для показа более релевантной рекламы, но не ради восстановления пароля.
В исходниках похоже есть бага.
Переменная res инициализируется значением true, а (видимо) должно быть false.
Из-за чего последующие присваивания в циклах внутри switch не имеют смысла.
Т.е. добавляются префиксы. Условно здесь первый дополнительный байтик — это номер таблицы, а второй — номер индекса (первичный, вторичный и т.д.). Минус в том, что увеличивается длина всех ключей (это отдельная тема).
В MDBX доступны множественные key-spaces (aka sub-DB) и есть дополнительные "фишечки": ключи фиксированного размера (не хранится длина) и multi-value с хранением значений во вложенных B+Tree. Поэтому в libfpta индексы располагаются в отдельных пространствах key-value.
Нет.
Обычно используется другая схема.
Вашим паролем зашифрован другой "настоящий" ключ (обычно достаточно большой), которым зашифрованы данные. При смене пароля достаточно перешифровать этот рабочий ключ, а не все данные.
Аналогично шифруются содержимое дисков. Точнее говоря оттуда и пошло лет 20-30 назад.
Повторюсь: "правительство Казахстана предложило (предполагаю что в соответствии со своими законами) поставить свой сертификат. Решение сомнительное по многим критериям, но озвучено явно и открыто."
В США, при необходимости послушать и/или получить данные какого-нибудь подозреваемого, есть протокол получения санкции (упрощенно: прокурор запрашивает, судья рассматривает), причем критерии и процедура разные для граждан и не-граждан. Далее это решение обязательно к исполнению всеми американскими компаниями (де-факто не только американскими).
Пока забудем про справедливость и подлинную обоснованность. Суть в том, что в США и для США этот механизм работает хорошо (во многом потому, что почти все "фейсбуки" и "вотсапы" гнездятся в США).
Для РФ этот механизм (видимо) работает с приемлемой эффективностью — подозреваемых в терроризме нам (видимо) сдают, а "павленсиких" и оппозицию никто не трогает (начиная с "Эха Москвы").
А для условного "Казахстана" это не работает на нужном им уровне, поэтому происходят (и будут продолжаться) подобные "закидоны". Рассуждать насколько хорошо/плохо делает их правительство я не хочу (озвучил в самом начале).
…
Но почему аборигены съели Кука?
За что — неясно, — молчит наука.
Мне представляется совсем простая штука:
Хотели кушать — и съели Кука.
…
Кому-то под руку попался каменюка, — Метнул, гадюка, и нету Кука.
А дикари теперь заламывают руки,
Ломают копья, ломают луки,
Сожгли и бросили дубинки из бамбука, — Переживают, что съели Кука.
Вы постоянно передергиваете.
Акты, на которые вы ссылаетесь, не действуют. Один заблокирован судом, второй давно отменен.
Нет.
Перечитайте комментарий и поправьтесь, иначе дискуссия теряет смысл.
Ссылки были даны именно для корректности, а смысл не в том "как сейчас", а в разнице реакции.
Слежка за гражданами США возможна только через суд, иначе это преступление.
Да, но в случаях Сноудена и Ассанжа прямо и явно преступниками названы люди раскрывшие "скандалы", а о судах и приговорах для организаторов я не слышал.
Для меня этих примеров действий (а не слов) достаточно чтобы оценить "качество" суда и "правоприменительной практики" США (это не считаю остальных off-topic-ов: Сербии, Гуантанамо, Ирака, Ливии, пробирки в СБ ООН и т.д.).
Исходя из вашей задачи (хранение email-ов) думаю вам также стоит глянуть на libmdbx, либо подумать о её комбинации с упомянутой libfpta (второе работает поверх первого).
MDBX может без проблем хранить большие объекты (десятки-сотни мегабайт), а ключей в ~1000 байт вам должно хватить. Кроме этого, MDBX используется в схожем проекте, а dartraiden (наверное) выдаст feedback по опыту использования.
Какой движок вам подходит должны решить вы сами. Могу предложить вам (неполный) список не-очевидных вопросов, на которые стоит ответить при оценке вариантов:
Нужен ли вам WAL (думаю что нет, но всё-же)?
pro: Наличие WAL позволяет движку обеспечить меньший Write Amplification Factor, в результате меньшее количество IOPS на транзакцию, в результате меньшую latency и более высокий RPS.
cons: WAL требует обслуживания, в том числе будет отдельный "файл журнала" (или директория с файлами) и некая суета с этими журналами (rollback/redo после аварии, ротация, checkpoints).
Насколько большие объекты вам нужно хранить? Как это делает БД и как она себя поведёт в случае (например) "10000 писем по 10 мегабайт"?
Насколько большие ключи вам требуются? Каковы ограничения БД и как она себя при этом ведет?
Как часто (а самом деле) вам нужно сбрасывать данные на диск с получением гарантии, что последние изменения не будут потеряны при системной аварии (выключении питания)?
Насколько "мохнато" выглядит устройство БД при взгляде снаружи: какие внутренние треды там работают, насколько много своего управления памятью, как выглядит БД в файловой системе?
Что БД предлагает для сопутствующих подзадач: проверка целостности, резервное копирование, dump/restore, управление размером БД?
Насколько большое API (размер h-файла и кол-во функций), как много исходного кода, сможете ли вы в нём ориентироваться, понять что происходит при баг-репорте от пользователя?
Где-то между "хотелось-бы увидеть" и "советую написать" статью по использованию PVS с облачными CI-сервисами (Travis-CI, Circle-CI, AppVeyour). Я даже думал сам сделать (и могу помочь), но пока некогда.
P.S.
Covery-Scan болеет с начала этого года. Поэтому я попробую перевести свои проекты на PVS. Ну и по-результатам запилить статейку.
Не хватает двух вещей: мешка "травы" для комитета и машинки времени для остальных.
Любопытно, что у вас получилось?
У меня (сугубо субъективное) мнение, что они слегка ерундили и видимо решили "взять паузу".
Спасибо что поправили меня, не ожидал что оно там уже появилось.
Решает, но не умеет AEAD для мета-данных (имени и даты файла, etc).
Не знаю как сейчас у гугла, но (как правило) хранение хешей паролей (включая механизм восстановления) и шифрование файлов обеспечиваются разными подсистемами.
При этом данные шифруются отдельным ключом (или ключами) которые шифруются паролем и перешифровываются при его смене. Это достаточно тривиальный подход, позволяющий не перешифровывать данные при смене пароля.
У гугла может быть иначе. В том числе потому, что почта и файлы индексируются (как минимум) для показа более релевантной рекламы, но не ради восстановления пароля.
В исходниках похоже есть бага.
Переменная
resинициализируется значениемtrue, а (видимо) должно бытьfalse.Из-за чего последующие присваивания в циклах внутри
switchне имеют смысла.Все верно и есть несколько способов реализовать "вторичные индексы" поверх key-value.
В вашем примере, когда внутри key-value только одно key-scpace, это выглядит обычно так:
Т.е. добавляются префиксы. Условно здесь первый дополнительный байтик — это номер таблицы, а второй — номер индекса (первичный, вторичный и т.д.). Минус в том, что увеличивается длина всех ключей (это отдельная тема).
В MDBX доступны множественные key-spaces (aka sub-DB) и есть дополнительные "фишечки": ключи фиксированного размера (не хранится длина) и multi-value с хранением значений во вложенных B+Tree. Поэтому в libfpta индексы располагаются в отдельных пространствах key-value.
Нет.
Обычно используется другая схема.
Вашим паролем зашифрован другой "настоящий" ключ (обычно достаточно большой), которым зашифрованы данные. При смене пароля достаточно перешифровать этот рабочий ключ, а не все данные.
Аналогично шифруются содержимое дисков. Точнее говоря оттуда и пошло лет 20-30 назад.
Повторюсь: "правительство Казахстана предложило (предполагаю что в соответствии со своими законами) поставить свой сертификат. Решение сомнительное по многим критериям, но озвучено явно и открыто."
В США, при необходимости послушать и/или получить данные какого-нибудь подозреваемого, есть протокол получения санкции (упрощенно: прокурор запрашивает, судья рассматривает), причем критерии и процедура разные для граждан и не-граждан. Далее это решение обязательно к исполнению всеми американскими компаниями (де-факто не только американскими).
Пока забудем про справедливость и подлинную обоснованность. Суть в том, что в США и для США этот механизм работает хорошо (во многом потому, что почти все "фейсбуки" и "вотсапы" гнездятся в США).
Для РФ этот механизм (видимо) работает с приемлемой эффективностью — подозреваемых в терроризме нам (видимо) сдают, а "павленсиких" и оппозицию никто не трогает (начиная с "Эха Москвы").
А для условного "Казахстана" это не работает на нужном им уровне, поэтому происходят (и будут продолжаться) подобные "закидоны". Рассуждать насколько хорошо/плохо делает их правительство я не хочу (озвучил в самом начале).
…
Но почему аборигены съели Кука?
За что — неясно, — молчит наука.
Мне представляется совсем простая штука:
Хотели кушать — и съели Кука.
…
Кому-то под руку попался каменюка, — Метнул, гадюка, и нету Кука.
А дикари теперь заламывают руки,
Ломают копья, ломают луки,
Сожгли и бросили дубинки из бамбука, — Переживают, что съели Кука.
/ Владимир Высоцкий, 1976
Нет.
Перечитайте комментарий и поправьтесь, иначе дискуссия теряет смысл.
Ссылки были даны именно для корректности, а смысл не в том "как сейчас", а в разнице реакции.
Да, но в случаях Сноудена и Ассанжа прямо и явно преступниками названы люди раскрывшие "скандалы", а о судах и приговорах для организаторов я не слышал.
Для меня этих примеров действий (а не слов) достаточно чтобы оценить "качество" суда и "правоприменительной практики" США (это не считаю остальных off-topic-ов: Сербии, Гуантанамо, Ирака, Ливии, пробирки в СБ ООН и т.д.).
Имею мнение и не мечу в судьи.
Пожалуйста, не пачкайте хабр делирием из подобных источников.
Мне же дискуссия с такими "тезисами" не интересна (я не психиатр).
Пожалуйста, не пачкайте хабр делирием из подобных источников.
Мне же дискуссия с такими "тезисами" не интересна (я не психиатр).
Опять эти Петров с Башировым.
Удивляюсь когда всё успевают, а теперь еще и материалы готовить для BBC ;)
Десятое "сплющенное яблоко" стоит кратно больше $99, при (наверное) в 100000 раз большем тираже и при этом тоже не имеет NVMe ;-)
Исходя из вашей задачи (хранение email-ов) думаю вам также стоит глянуть на libmdbx, либо подумать о её комбинации с упомянутой libfpta (второе работает поверх первого).
MDBX может без проблем хранить большие объекты (десятки-сотни мегабайт), а ключей в ~1000 байт вам должно хватить. Кроме этого, MDBX используется в схожем проекте, а dartraiden (наверное) выдаст feedback по опыту использования.
+Добавлю, что это будет в тренде наблюдаемой миграции с Berkeley DB на LMDB (OpenLDAP, Samba, OrangeFS, Postfix, Exim, Cyrus и т.д.), так как MDBX является развитием LMDB ;)
Какой движок вам подходит должны решить вы сами. Могу предложить вам (неполный) список не-очевидных вопросов, на которые стоит ответить при оценке вариантов:
pro: Наличие WAL позволяет движку обеспечить меньший Write Amplification Factor, в результате меньшее количество IOPS на транзакцию, в результате меньшую latency и более высокий RPS.
cons: WAL требует обслуживания, в том числе будет отдельный "файл журнала" (или директория с файлами) и некая суета с этими журналами (rollback/redo после аварии, ротация, checkpoints).
Тарантул не встраиваемый, но (думаю не в вашем случае) можно встроиться в таратнул, в том числе "размазав" логику приложения между lua и C/C++.
Там key-value, т.е. нет вторичных индексов и "колонок" (не путать с Column Families).