Когда я ходил в поход на Урал, то брал распечатанные на А4 генштабовские карты по маршруту следования. Вместо ламинирования взял обычные файлы заклеенные скотчем, складывается значительно легче, да и дешевле было. Телефон с GPS доставал изредка для уточнения текущего местоположения, по большей части он был выключен и лежал в гермомешке. Ориентирования по местности на основе бумажных карт в целом хватало и в этом был даже свой интерес.
И где же в использовании get_unchecked жертвование производительностью или возможностями (в оригинале capabilities)? Если бы было про краткость/лаконичность ещё можно было бы согласиться, но в текущем варианте, нет, не оно.
Первое правило (распространяющееся, между прочим, и на Украину) относительно слабое и в большинстве случаев будет приводить только к дополнительной бюрократии и некоторой задержке поставок. Гораздо более серьёзно и, на мой взгляд, релевантно для IT сообщества именно второе правило.
Замечу, что и заголовок то просто сделан для кликов. На самом деле про винду и айфоны — это просто мнение в частном блоге.
Это "мнение" ссылается на конкретные пункты в регуляторном акте, релевантный кусок которого процитирован выше.
Речь идёт о продаже организациям, т.е. условный Эппл Рус не сможет участвовать в гипотетических тендерах на поставку мобильных телефонов в «военные» структуры. Насколько я понимаю, работник полиции как физлицо сможет покупать яблоки как и раньше.
Во-первых, Windows здесь просто наиболее яркий пример, не факт что MS Office не добавлен в тот же список. Во-вторых, а на чём вы копию MS Office собрались запускать? Неужели на маке или виндофоне?
Полноценный переход на Астру затеяли всего-лишь в 18-м году, поэтому, учитывая инерционность армии, не удивлюсь, если Windows для офисных задач в военных частях и военкоматах живее всех живых. Что уж говорить, если у Путина на компьютере, судя по внешнему виду, вообще XP стоит...
Ну и обращаю внимание, что к «военным», судя по новости, они относят и полицию, в которой Windows просто повсеместна. Можете представить сколько времени займёт миграция и сколько головной боли она доставит? Плюс проблема не только в ОС, но и в существующем специализированном Windows-only софте, который не факт что нормально заработает под Wine. И это не говоря уже о тонне документов созданных в MS офисе, которые в Либре (и её производных) будут криво открываться.
Но вообще, новость, на мой взгляд, скорее положительная. Жалко только, что в лучших традициях стали дожидаться грома, а не стали заранее переводить весь госаппарат на инфраструктуру независимую от Microsoft, Oracle и др.
блокчейн <..> вполне достаточен для того, чтобы прикрыть часть системы голосования от махинаций
Ещё раз, какие принципиальные гарантии даёт блокчейн в данном случае по сравнению с простой публикацией подписанных блобов на ресурсе органа проводящего голосование? Попробуйте нормально построить модель угроз и показать конкретно для чего здесь нужен блокчейн. Поймите, здесь это не более чем snake oil, который только делает систему сложнее, в то время как к ней доверие и без того низкое.
В публичный блокчейн ничего пихать не надо, достаточно записи в оперативно обновляемой "цепочке" Меркла подписывать подписью органа отвечающего за проведение голосования (публичный ключ органа фиксируется условным постановлением центризбиркома перед голосованием). Если будет попытка переписать историю, то наблюдателям в качестве доказательства будет достаточно предъявить стёртую ветку.
Вообще говоря, даже и "цепочка" Меркла не особенно и нужна, ибо никаких принципиальных гарантий против игнорирования или подмешивания голосов она не даёт. Вполне достаточно при отсылке голоса (доказательства с нулевым знанием) получать обратно голос подписанный органом. По окончанию голосования публикуется (подписанный) архив подписанных голосов и производится подсчёт результатов. Подписанный голос не включённый в архив будет доказательством мухлежа (игнорирования голоса). От подмешивания же нужно защищаться другими средствами (см. комментарий по первой ссылке). Для дополнительной прозрачности полученные голоса вполне можно публиковать онлайн, но это больше для красоты, нежели для каких-то серьёзных гарантий.
Электронное голосование в текущем виде это фарс и профанация, не далеко ушедшая от тупой голосовалки на сайте с привязкой к ЕСИА.
Уже писал вкратце о системах электронного голосования здесь. Вот этот комментарий тоже в целом хорошо описывает дело (кроме части с блокчейном и пост-квантовой криптографией).
Подобные письма в спортлото никак не помогут, пока у выдающих ТЗ цели отличаются от целей граждан.
Новые разработки в области хранения и верификации личных данных
Что? Это какие такие "новые разработки"? Криптографии с публичным ключом и использованию HSM (частным случаем которых являются ЭЦП-токены) уже сто лет в обед. Если вы о чём-то содержащем слово "блокчейн" в описании, то сразу забудьте, в случае электронного голосования почти гарантированно задача решается значительно проще, ибо у нас неизбежно есть центральная организация ответственная за проведение выборов (обращаю внимание, деревья Меркла != "блокчейн").
Так блокчейн тут и не нужен, достаточно выкладывать доказательства с нулевым знанием сгенерированные голосующими (что бы была возможность наблюдателям проверить, что один голос не использовался дважды) и подписанные органом отвечающим за выборы с таймштампами получения голоса. Зная хеш своего голоса/доказательства вы сможете проверить, что ваш голос был учтён верно. Подмешивать голоса мёртвых душ, что в блокчейн, что в несвязную коллекцию блобов разницы нет никакой.
А насчёт списков, вроде как говорят что выкладывание подобных списков противоречит законам о защите ПД, поэтому легально вы их нигде не найдёте. Более того, я даже не уверен что возможно получить по участкам количество имеющих право голосовать на них до проведения выборов.
Как бы разработчики не старались, но вам придётся доверять тому факту что государство не создаст массу "мёртвых душ". Единственный способ контроля здесь это сравнение числа проголосовавших с общим числом имеющих право голосования. Если вам захочется меньшего масштаба проверки нежели чем 110 миллионов, то придётся отказываться от части анонимности и оставлять информацию о том к какому району вы приписаны (в пределе мы доходим до публичного голосования).
По сути основной задачей электронного голосования является проверка того что ваш голос можете использовать только вы, что его учли как следует и не перезаписали на удобный власти. Этот сразу отметает привязку к ЕСИА, только асимметричная криптография, ключи для которой вы генерируете самостоятельно, государство же выступает только в роли удостоверяющего центра. Кроме того, это предполагает что ЭЦП обладает полноценной юридической силой, дабы люди относились к ней максимально осторожно и не допускали их утечек или продажи. Важность ЭЦП так же будет ограничивать желание государства напечатать "мёртвых душ". Но с другой стороны, к сожалению, это существенно осложняет масштабирование системы на всё население.
Вообще, тот факт что эту систему голосования построили на блокчейне уже говорит многое о разработчиках системы и тех кто формулировал ТЗ, ибо по сути дела оно тут вообще ни к селу, ни к городу...
При прочих равных всегда удобнее работать с моноязыковым проектом, поэтому если вы пишете на Расте, то при возможности имеет смысл использовать идиоматичный код, а не тащить привычные инструменты из другого языка. Если у вас есть плюсовая библиотека использующая буст, то делайте к ней C API, относительно тривиально оборачивайте в крейт и используйте в Расте без каких-либо проблем. Либо наоборот, используйте Растовый крейт обёрнутый в C API в вашем плюсовом коде.
ну или вон ripgrep можно было бы прилинковать
Существенную часть heavy lifting, насколько я понимаю, тут делает regex крейт, для которого уже существует C API, так что, насколько я могу судить, это можно сделать относительно просто уже сейчас.
было бы замечательно, если бы при помощи Cargo можно было бы легко замешивать C/C++ и Раст код
Cargo это в первую очередь билд система для Раста, распыление и без того ограниченных ресурсов и feature creep имхо скорее повредит проекту. Благо специализированные крейты (cc, сmake, cxx) и билд скрипты уже сейчас делают создание обёрток из C/C++ в Раст относительно безболезненным.
Вообще, я не думаю, что "лёгкое замешивание" возможно достичь малой кровью. С++ (справедливости ради, как и Раст) чрезвычайно сложно автоматически замешивать с другими языками не выделяя вручную C API. Не говоря уже о том, что даже при наличии C API нужно код оборачивать в безопасный Раст, что в зависимости от архитектуры сишного или плюсового кода не всегда возможно сделать нормально (например, см. провалившуюся попытку обернуть wlroots). Насколько я слышал, даже D, ставя одной из своих основных задач совместимость с C++ всё ещё имеет ворох проблем, что уж говорить о Расте для которого таких задач не ставилось.
Не совсем. Гарантируется, что функция не вернёт после второго лока:
However, this function will not return on the second call (it might panic or deadlock, for example).
Тут скорее platform specific behaviour, которое для большинства популярных платформ означает deadlock, что не нарушает гарантий Раста (т.е. memory safety и отсутствие data races).
Ведь если ответ не правльный, какая мне разница UB это или не UB.
Потому что UB по сути даёт карт-бланш компилятору изменять ваш код как ему заблагорассудится. И эти трансформации могут быть чрезвычайно неинтуитивными. Если вам повезёт, то вы всего-лишь получите "неправильный" ответ, если нет, то гейзенбаг, который вам придётся отлавливать в 4 часа утра в обнимку с дебагером.
Если нет аналогов (по функциональности и производительности) на чистом Расте и библиотека представляет C API, то народ вполне использует плюсовые библиотеки обёрнутые в крейты. Не говоря уже о куче обёрток вокруг C библиотек. Из плюсовых обёрток лично я использовал shaderc и самописный биндинг к декодеру FLIF. От последнего отказался когда декодер на чистом Расте стал достаточно производителен и получил нужную мне функциональность. Если же библиотека не имеет нормального C API, то к чёрту такое оборачивать… Например, после бесплодных попыток обернуть libpcl (плотно сидящий на темплейтах) я плюнул и написал нужные мне алгоритмы с нуля. Примерно так же народ плюнул на оборачивание OpenCV, большинство обёрток, насколько я знаю, далеки от желаемого.
А Boost можно?
А что конкретно вам из него нужно чего нет в существующих крейтах на чистом Расте?
Ну так я же написал, при желании компания может арендовать эти услуги и учитывая сопутствующие риски (в т.ч. и для безопасности). Проблема в том, что с Zoom из-за проприетарности и закрытости у вас нет выбора кроме как переходить на другие (потенциально менее удобные) средства.
Без использования прокси — никак. Разумеется такой прокси сможет прослушивать данные потоки. Но при открытом протоколе и опенсурсных клиентах, такой прокси может быть поднят самой компанией на собственной инфраструктуре, либо арендован у более надёжных поставщиков держащих сервера в стране, которой вы доверяете, а не где-то в Китае.
Прошу обратить внимание, что мой пост касался в первую очередь вашего утверждения о "невозможности" end-to-end шифрования в данной области и не затрагивал другие поднятые вами вопросы.
Когда речь о трансляции на 10+ человек — сквозное шифрование становится близким к невозможному в полевых условиях.
Всё возможно и достаточно тривиально с криптографической точки зрения. Участники трансляции получают единый эфемерный ключ на всех (например, через инициатора трансляции) и шифруют свои потоки используя его. Поток от каждого пользователя идёт на сервер, который и дублирует его на остальных участников. Да, сервер не может вмешиваться в поток, поэтому он не сможет понижать битрейт для отдельных участников или синтезировать единый поток для всех, но это можно решать на уровне клиента вводя протоколы согласования битрейта от каждого из участников (например, динамически меняя разрешение видео потока, либо убирая его вовсе в зависимости говорит сейчас человек или нет).
Проблема кроется в аутентификации, без которой возможно легко инициировать MitM со стороны сервера. Решения тут тоже есть начиная от тривиального "каждый аккаунт идентифицируется по открытому криптографическому ключу" (и каждый аккаунт верифицируется либо central autority по типу TLS, либо вручную по типу Web of Trust) и заканчивая возможностью посмотреть фингерпринт текущего эфемерного ключа и проверить голосом его совпадение для других участников (так сделано, например, в Jitsi). Последний вариант сохраняет возможность подключаться к трансляциям анонимно и проверять отсутствие MitM со стороны сервера (разумеется, при условии использования опенсурсного не-веб клиента).
Эти настройки будут убраны в следующей версии и уже не работают в найтли. Один из разработчиков утверждает что это позволит убрать большое количество легаси кода. Надеюсь, они хотя бы добавят настройку дабы вернуть старый внешний вид.
Когда я ходил в поход на Урал, то брал распечатанные на А4 генштабовские карты по маршруту следования. Вместо ламинирования взял обычные файлы заклеенные скотчем, складывается значительно легче, да и дешевле было. Телефон с GPS доставал изредка для уточнения текущего местоположения, по большей части он был выключен и лежал в гермомешке. Ориентирования по местности на основе бумажных карт в целом хватало и в этом был даже свой интерес.
И где же в использовании
get_uncheckedжертвование производительностью или возможностями (в оригинале capabilities)? Если бы было про краткость/лаконичность ещё можно было бы согласиться, но в текущем варианте, нет, не оно.Кому интересно, есть пример кода на Расте для снятия данных с этих датчиков построенный на основе
hidapi.Первое правило (распространяющееся, между прочим, и на Украину) относительно слабое и в большинстве случаев будет приводить только к дополнительной бюрократии и некоторой задержке поставок. Гораздо более серьёзно и, на мой взгляд, релевантно для IT сообщества именно второе правило.
Это "мнение" ссылается на конкретные пункты в регуляторном акте, релевантный кусок которого процитирован выше.
Речь идёт о продаже организациям, т.е. условный Эппл Рус не сможет участвовать в гипотетических тендерах на поставку мобильных телефонов в «военные» структуры. Насколько я понимаю, работник полиции как физлицо сможет покупать яблоки как и раньше.
Во-первых, Windows здесь просто наиболее яркий пример, не факт что MS Office не добавлен в тот же список. Во-вторых, а на чём вы копию MS Office собрались запускать? Неужели на маке или виндофоне?
Полноценный переход на Астру затеяли всего-лишь в 18-м году, поэтому, учитывая инерционность армии, не удивлюсь, если Windows для офисных задач в военных частях и военкоматах живее всех живых. Что уж говорить, если у Путина на компьютере, судя по внешнему виду, вообще XP стоит...
Ну и обращаю внимание, что к «военным», судя по новости, они относят и полицию, в которой Windows просто повсеместна. Можете представить сколько времени займёт миграция и сколько головной боли она доставит? Плюс проблема не только в ОС, но и в существующем специализированном Windows-only софте, который не факт что нормально заработает под Wine. И это не говоря уже о тонне документов созданных в MS офисе, которые в Либре (и её производных) будут криво открываться.
Но вообще, новость, на мой взгляд, скорее положительная. Жалко только, что в лучших традициях стали дожидаться грома, а не стали заранее переводить весь госаппарат на инфраструктуру независимую от Microsoft, Oracle и др.
Ещё раз, какие принципиальные гарантии даёт блокчейн в данном случае по сравнению с простой публикацией подписанных блобов на ресурсе органа проводящего голосование? Попробуйте нормально построить модель угроз и показать конкретно для чего здесь нужен блокчейн. Поймите, здесь это не более чем snake oil, который только делает систему сложнее, в то время как к ней доверие и без того низкое.
В публичный блокчейн ничего пихать не надо, достаточно записи в оперативно обновляемой "цепочке" Меркла подписывать подписью органа отвечающего за проведение голосования (публичный ключ органа фиксируется условным постановлением центризбиркома перед голосованием). Если будет попытка переписать историю, то наблюдателям в качестве доказательства будет достаточно предъявить стёртую ветку.
Вообще говоря, даже и "цепочка" Меркла не особенно и нужна, ибо никаких принципиальных гарантий против игнорирования или подмешивания голосов она не даёт. Вполне достаточно при отсылке голоса (доказательства с нулевым знанием) получать обратно голос подписанный органом. По окончанию голосования публикуется (подписанный) архив подписанных голосов и производится подсчёт результатов. Подписанный голос не включённый в архив будет доказательством мухлежа (игнорирования голоса). От подмешивания же нужно защищаться другими средствами (см. комментарий по первой ссылке). Для дополнительной прозрачности полученные голоса вполне можно публиковать онлайн, но это больше для красоты, нежели для каких-то серьёзных гарантий.
Электронное голосование в текущем виде это фарс и профанация, не далеко ушедшая от тупой голосовалки на сайте с привязкой к ЕСИА.
Уже писал вкратце о системах электронного голосования здесь. Вот этот комментарий тоже в целом хорошо описывает дело (кроме части с блокчейном и пост-квантовой криптографией).
Подобные письма в спортлото никак не помогут, пока у выдающих ТЗ цели отличаются от целей граждан.
Что? Это какие такие "новые разработки"? Криптографии с публичным ключом и использованию HSM (частным случаем которых являются ЭЦП-токены) уже сто лет в обед. Если вы о чём-то содержащем слово "блокчейн" в описании, то сразу забудьте, в случае электронного голосования почти гарантированно задача решается значительно проще, ибо у нас неизбежно есть центральная организация ответственная за проведение выборов (обращаю внимание, деревья Меркла != "блокчейн").
Так блокчейн тут и не нужен, достаточно выкладывать доказательства с нулевым знанием сгенерированные голосующими (что бы была возможность наблюдателям проверить, что один голос не использовался дважды) и подписанные органом отвечающим за выборы с таймштампами получения голоса. Зная хеш своего голоса/доказательства вы сможете проверить, что ваш голос был учтён верно. Подмешивать голоса мёртвых душ, что в блокчейн, что в несвязную коллекцию блобов разницы нет никакой.
А насчёт списков, вроде как говорят что выкладывание подобных списков противоречит законам о защите ПД, поэтому легально вы их нигде не найдёте. Более того, я даже не уверен что возможно получить по участкам количество имеющих право голосовать на них до проведения выборов.
Как бы разработчики не старались, но вам придётся доверять тому факту что государство не создаст массу "мёртвых душ". Единственный способ контроля здесь это сравнение числа проголосовавших с общим числом имеющих право голосования. Если вам захочется меньшего масштаба проверки нежели чем 110 миллионов, то придётся отказываться от части анонимности и оставлять информацию о том к какому району вы приписаны (в пределе мы доходим до публичного голосования).
По сути основной задачей электронного голосования является проверка того что ваш голос можете использовать только вы, что его учли как следует и не перезаписали на удобный власти. Этот сразу отметает привязку к ЕСИА, только асимметричная криптография, ключи для которой вы генерируете самостоятельно, государство же выступает только в роли удостоверяющего центра. Кроме того, это предполагает что ЭЦП обладает полноценной юридической силой, дабы люди относились к ней максимально осторожно и не допускали их утечек или продажи. Важность ЭЦП так же будет ограничивать желание государства напечатать "мёртвых душ". Но с другой стороны, к сожалению, это существенно осложняет масштабирование системы на всё население.
Вообще, тот факт что эту систему голосования построили на блокчейне уже говорит многое о разработчиках системы и тех кто формулировал ТЗ, ибо по сути дела оно тут вообще ни к селу, ни к городу...
При прочих равных всегда удобнее работать с моноязыковым проектом, поэтому если вы пишете на Расте, то при возможности имеет смысл использовать идиоматичный код, а не тащить привычные инструменты из другого языка. Если у вас есть плюсовая библиотека использующая буст, то делайте к ней C API, относительно тривиально оборачивайте в крейт и используйте в Расте без каких-либо проблем. Либо наоборот, используйте Растовый крейт обёрнутый в C API в вашем плюсовом коде.
Существенную часть heavy lifting, насколько я понимаю, тут делает
regexкрейт, для которого уже существует C API, так что, насколько я могу судить, это можно сделать относительно просто уже сейчас.Cargo это в первую очередь билд система для Раста, распыление и без того ограниченных ресурсов и feature creep имхо скорее повредит проекту. Благо специализированные крейты (
cc,сmake,cxx) и билд скрипты уже сейчас делают создание обёрток из C/C++ в Раст относительно безболезненным.Вообще, я не думаю, что "лёгкое замешивание" возможно достичь малой кровью. С++ (справедливости ради, как и Раст) чрезвычайно сложно автоматически замешивать с другими языками не выделяя вручную C API. Не говоря уже о том, что даже при наличии C API нужно код оборачивать в безопасный Раст, что в зависимости от архитектуры сишного или плюсового кода не всегда возможно сделать нормально (например, см. провалившуюся попытку обернуть
wlroots). Насколько я слышал, даже D, ставя одной из своих основных задач совместимость с C++ всё ещё имеет ворох проблем, что уж говорить о Расте для которого таких задач не ставилось.Не совсем. Гарантируется, что функция не вернёт после второго лока:
Тут скорее platform specific behaviour, которое для большинства популярных платформ означает deadlock, что не нарушает гарантий Раста (т.е. memory safety и отсутствие data races).
Потому что UB по сути даёт карт-бланш компилятору изменять ваш код как ему заблагорассудится. И эти трансформации могут быть чрезвычайно неинтуитивными. Если вам повезёт, то вы всего-лишь получите "неправильный" ответ, если нет, то гейзенбаг, который вам придётся отлавливать в 4 часа утра в обнимку с дебагером.
Если нет аналогов (по функциональности и производительности) на чистом Расте и библиотека представляет C API, то народ вполне использует плюсовые библиотеки обёрнутые в крейты. Не говоря уже о куче обёрток вокруг C библиотек. Из плюсовых обёрток лично я использовал
shadercи самописный биндинг к декодеру FLIF. От последнего отказался когда декодер на чистом Расте стал достаточно производителен и получил нужную мне функциональность. Если же библиотека не имеет нормального C API, то к чёрту такое оборачивать… Например, после бесплодных попыток обернутьlibpcl(плотно сидящий на темплейтах) я плюнул и написал нужные мне алгоритмы с нуля. Примерно так же народ плюнул на оборачивание OpenCV, большинство обёрток, насколько я знаю, далеки от желаемого.А что конкретно вам из него нужно чего нет в существующих крейтах на чистом Расте?
Ну так я же написал, при желании компания может арендовать эти услуги и учитывая сопутствующие риски (в т.ч. и для безопасности). Проблема в том, что с Zoom из-за проприетарности и закрытости у вас нет выбора кроме как переходить на другие (потенциально менее удобные) средства.
Без использования прокси — никак. Разумеется такой прокси сможет прослушивать данные потоки. Но при открытом протоколе и опенсурсных клиентах, такой прокси может быть поднят самой компанией на собственной инфраструктуре, либо арендован у более надёжных поставщиков держащих сервера в стране, которой вы доверяете, а не где-то в Китае.
Прошу обратить внимание, что мой пост касался в первую очередь вашего утверждения о "невозможности" end-to-end шифрования в данной области и не затрагивал другие поднятые вами вопросы.
Всё возможно и достаточно тривиально с криптографической точки зрения. Участники трансляции получают единый эфемерный ключ на всех (например, через инициатора трансляции) и шифруют свои потоки используя его. Поток от каждого пользователя идёт на сервер, который и дублирует его на остальных участников. Да, сервер не может вмешиваться в поток, поэтому он не сможет понижать битрейт для отдельных участников или синтезировать единый поток для всех, но это можно решать на уровне клиента вводя протоколы согласования битрейта от каждого из участников (например, динамически меняя разрешение видео потока, либо убирая его вовсе в зависимости говорит сейчас человек или нет).
Проблема кроется в аутентификации, без которой возможно легко инициировать MitM со стороны сервера. Решения тут тоже есть начиная от тривиального "каждый аккаунт идентифицируется по открытому криптографическому ключу" (и каждый аккаунт верифицируется либо central autority по типу TLS, либо вручную по типу Web of Trust) и заканчивая возможностью посмотреть фингерпринт текущего эфемерного ключа и проверить голосом его совпадение для других участников (так сделано, например, в Jitsi). Последний вариант сохраняет возможность подключаться к трансляциям анонимно и проверять отсутствие MitM со стороны сервера (разумеется, при условии использования опенсурсного не-веб клиента).
Эти настройки будут убраны в следующей версии и уже не работают в найтли. Один из разработчиков утверждает что это позволит убрать большое количество легаси кода. Надеюсь, они хотя бы добавят настройку дабы вернуть старый внешний вид.