Мне просто стало интересно, сколько будут занимать такие данные, жпт говорит, что это. примерно ~10⁷⁰ гигабайт.
Разумеется, это огромное число, и это позволяет считать размер этих массивов на практике бесконечным.
коллизии могут возникнуть в использовании keccak256, но не mapping, потому что mapping использует хеш(key, slot)
Так хеш и есть keccak256. Он именно так вычисляется, берется побайтное представление пары (key, slot) и для этого представления вычисляется keccak256.
на сколько симуляция на урезанном адресном пространстве валидна?
Не только на урезанном пространстве, но и на соответственно урезанном keccak. Я рассуждал так: если keccak256 доказанно приводит к максимальной энтропии на своем пространстве значений (то есть иначе говоря, он является в этом смысле хорошей хеш-функцией), то и любая выборка бит из его значения будет также приводить к максимальной энтропии на соответствующем урезанном пространстве значений.
Кстати, использование урезанной выборки бит значения keccak256 является распространенной практикой и в самой EVM. Например, адреса контрактов и индивидуальных счетов тоже являются результатом сходной операции. Вот что мне сообщил MS Copilot:
Адреса индивидуальных счетов (EOA - Externally Owned Accounts) создаются на основе приватного ключа, который затем хешируется с помощью keccak256 для получения публичного ключа. Далее, публичный ключ проходит через keccak256, и берутся его последние 20 байт для формирования адреса. Адреса контрактов генерируются по другому принципу: address = keccak256(RLP_encoding([sender_address, sender_nonce]))[12:]
Таким образом, любой адрес в Ethereum - это результат выборки последних 20 байт из результата применения keccak256 к какой-то последовательности байт.
Разумеется. Однако напомню, что мы имеем дело не только с "точной" коллизией, когда разные исходные данные приводят к вычислению одного и того же ключа, но и "приблизительной", когда вычисленные ключи оказываются достаточно близко (с точки зрения разницы между значениями) друг от друга, чтобы оказать воздействие на сохраненные со смещением данные (в большом массиве или структуре).
Во-первых, наличие коллизий у keccak256 как и любой другой хеш-функции, когда хешируемое значение длиннее, чем ключ - факт, который легко доказывается математически, исходя из количества возможных состояний хешируемого значения. Если вы хешируете скажем, 512 бит, то количество возможных значений будет 2^512, а количество значений хеша - только 2^256. Таким образом, будет истинным следующее высказывание: существует такое значение хеша X, для которого найдется не менее 2^256 коллизий в указанных условиях. И во-вторых, нет, обнаружение коллизий в этом случае никак не влияет на криптографическую стойкость, и "взломом" ключа это не является, а является проблемой, которую я описал, не больше, но и не меньше.
Было довольно мучительно оставлять отзыв, поскольку regulation блокирует адреса извне, но доступен через бесплатный росс-vpn, а вот esia наоборот - доступен с внешних адресов, но зато блочит публичные росс-vpn. Однако пробился, вовремя включая и выключая!
Статью я уже писал, см. по ссылке, с тех пор мало что изменилось.
Хабр обещал отделять новости от статей, ну я и написал новость, и пометил как новость. Какой еще контент нужен в новости? Есть событие - расширена совместимость пакета. Вот вам новость об этом. Яхз, что тут еще можно написать-то.
вместо options в settings у нас модель importhelper. позволяет не морочиться с правкой settings и перестартом сервера. Рекомендую.
Хм. Ну, скажем так, что касается настройки списка доступных к импорту моделей и хранилища файлов, так это вряд ли поменяется в рантайме, тем более что хранилище поменять в рантайме вообще будет весьма затруднительно.
А вот флаг синхронного/асинхронного запуска импорта можно было бы включить в задание, но я подумал, что такая кастомизация только вредна, поскольку влияет на нагрузку узлов в большом распределенном проекте. По сути, синхронный запуск - это затычка для локально запущенного сервера, а продакшн должен конечно, запускаться с асинхронным запуском всегда.
def has_add_permission(request, *av, **kw):
Ох вот ведь, поймал :) Давай PR, замержу. Ну или как будет момент, сам поправлю.
подробнее разобраться с ContentType
Да, недавно об этом же подумал. Удаление моделей - дело редкое и кажется, я встречался с тем, что это мешало сложным миграциям. Но возможность такая есть, да. Я помню был проект где это реально произошло и там из за этого были неприятности, связанные то ли с джанговскими правами, то ли с сохраненными фикстурами ...
UPD вспомнил. В частности, в списке раздаваемых прав в джанговской админке пользователей и групп выводились как раз права на отсутствующие модели, отличающиеся странными вывертами в отображении. Ну и фикстуры с отсутствующими моделями не импортируются конечно ...
Поправил описание в README. Детальные примеры можно посмотреть в коде пакета, в каталоге examples. Там все давно переделано так, как надо. Если есть идеи или поправки, приглашаю в контрибуторы.
Согласен, примеры подустарели, поправлю, особенно насчет полей. В оправдание скажу, что система не занимается управлением доступом на уровне полей (что является одним из возможных направлений развития). В отличие от исходного кода, в README приведен упрощенный пример. Тем не менее, управление доступом полями в нем нужно видимо вовсе исключить, чтобы не вводить в заблуждение читателей.
Что касается вычисления прав "на лету", то этим страдает как раз таки родная джанговская система управления правами, когда на полном серьезе предлагает вычислять их как user.has_perm(..., obj) на инстансе модели (в то время как данный пакет сохраняет использование has_perm() только для обратной совместимости с проектами третьих сторон). Поэтому никакой инициализации 100 объектов для пользователя не произойдет. Объекты будут отобраны на этапе чтения из БД, и на выходе запрос выдаст только один инициализированный из базы объект.
Описываемая система вычисляет права на основе фильтрации объектов в базе данных через QuerySet, еще до того, как они стали инстансами модели. Это позволяет выбрать из базы только и исключительно те объекты, которые доступны данному пользователю, что как раз решает Вашу (как и мою, когда мне пришлось это делать для нашего проекта) проблему.
Вам в любом случае надо выбирать из базы только те объекты, к которым имеет доступ пользователь. Система позволяет встроить этот механизм, как универсальный, в ваш код.
Процессоры «Байкал» нужны нам для того, чтобы гарантированно получить компьютеры без закладок предполагаемого противника. И вообще без закладок.
Процессоры «Байкал» нужны нам для того, чтобы гарантированно получить компьютеры с закладками наших доблестных спецслужб. И вообще с т-щем майором в комплекте.
главный вопрос моего комментария — готовы ли вы к применению против себя тех мер, которые вы ... собираетесь применять...
Хм. Мне пока никто не сообщил, что своим софтом я причинил кому-то такой вред, за который мне было бы стыдно. Если такое случится, я всерьез задумаюсь о способе нейтрализации этого вреда, по крайней мере мне на данный момент, такое поведение кажется вполне логичным. Мой манифест именно об этом, и если я призываю других к такому поведению, то да, конечно, я и сам готов покаяться таким вот образом - разрабатывая средства противодействия тому вреду, который необдуманно нанес, разработав опасный в применении софт.
...вообще ничего сделать не можете...
мне кажется, или я слышу отголоски ликования в этом утолщенном шрифте? не радуйтесь так, можем и делаем. Но эта "гонка вооружений" не дает ничего, кроме бессмысленной траты ресурсов, человеческих и вычислительных, и повышение опасности нарушения целостности общей полезной инфраструктуры, используемой и вами в том числе.
Так что если уж переходить на личности, вот вы например, судя по краткому анонсу, работаете над Machine Learning, при этом мне хорошо известно, что немалое количество народу работает над машинным распознаванием типа шифрованного трафика. Так что мне нисколько не удивительно, что вы так взъелись на мой "манифест" - ведь вероятно, именно вы, или ваши коллеги, будете ответственны за то, что огромное количество вычислительных ресурсов, на которые столь охоч машинный интеллект, будет потрачено практически впустую, в попытках выделить, ограничить и оттрассировать шифрованный трафик, в котором правительства разных стран или крупные корпорации усмотрели какую-то опасность для себя.
И хорошо, если впустую, но пока мы сможем наложить столь качественный шум на этот трафик, что распознавать его станет полностью бесполезно, вполне вероятно, что какое-то количество невиновных людей в Китае, Иране, России, Белоруссии, Турции, Афганистане и еще где-то будет схвачено и посажено в тюрьму, а то и казнено в конечном итоге, именно стараниями вышеупомянутых разработчиков. И я могу только надеяться, что это не коснется вас и ваших близких. Хотя больше переживать я конечно, буду отнюдь не за вас, а за тех, уж точно непричастных пользователей, кто вашими стараниями получит сетевые тормоза и повышение тарифов.
И да, я не говорю о вреде другого софта, потому что этот пост именно про тот софт, который служит для наведения цензуры. Я не хочу пытаться объять необъятное и вы конечно правы, что я пишу о том, что меня волнует прямо сейчас, поскольку я действительно пишу из России.
Возвращаясь же к тем, кто (видимо вместе с вами) участвует в разработке обсуждаемой категории софта, то как я уже писал раньше, мое отношение к каждому из этой категории разработчиков действительно будет сильно детерминировано его отношением к тому, что он успел сделать. В том числе и при приеме его на работу, если и когда я буду в этом участвовать.
Участь же "смириться с неизбежным" я оставлю вам, вам это понадобится.
Перечитайте пожалуйста ваш комментарий, и приведите его в порядок. На настоящий момент, он выглядит бессистемным. Наверно, вы писали его в сильном эмоциональном возбуждении. Я ничего не понял.
Какую именно "ситуацию" я по вашему мнению, "примерил на себя" и "экстраполировал"?
Где именно вы нашли "утверждения об очевидности"?
Где именно я утверждал, что описываемое ПО "плохое"?
Вы уверены, что поняли, каким именно способом я предлагаю "покаяться" за создание опасного в применении ПО?
Вы уверены, что я "осуждаю" людей именно за "убеждения"?
Ваш пассаж про комплекс бога с заглавной буквы я оставляю на скобками, как манипулятивный и риторический.
Еще раз, последний, призываю вас читать внимательно текст, на который вы пишете возражение.
Вы вероятно, считаете, что если вы назвали что-то "protection", этого достаточно, чтобы говорить о том, что оно не приносит никому вреда. Но это не так.
Я не хочу, чтобы мои данные из банков, госорганов, страховых и т.д. широкой рекой разливались по интернетам и попадали ко всяким проходимцам.
Уверяю вас, 90% информации из банков и госорганов, попавшие в руки проходимцам, попали туда вовсе не из за недостаточной "protection" со стороны какого бы то ни было софта. Проблема многочисленных "protection" была и остается в том, что они фигурально выражаясь, пытаются ставить сейфовую дверь в недостроенный забор. Об эту дверь с матюками спотыкаются добросовестные пользователи, в то время как "проходимцы" спокойно проходят через дыры в заборе. И забор - это далеко не только и не столько софт. Основной источник утечек был и остается - нелояльность и некомпетентность ответственных лиц. Пока этот источник в наличии - бороться с ним с помощью одного софта - бессмысленно и вредно, а тот, кто изъявляет горячее желание это делать - вольно или невольно является обманщиком.
Используйте https, системы распределения доступа, антивирусы, лояльных и компетентных сотрудников - и у вас в 99% случаев не будет никаких утечек.
Про электропочту вы как будто и вовсе не прочитали... мда.
Про админов и прочих - вы правильно отметили. Предлагайте способы. Например, техпис может описать недокументированные фичи.
Насчет юристов и адвокатов - поищите кого-нибудь, кто расскажет вам, какие именно юридические последствия наступают у нас от использования VPN (спойлер - никаких).
Вы прямым текстом требуете от разработчиков
Да ничего я не требую, кроме одного - будьте от меня подальше. Хотите разрабатывать DLP, поддерживать инфраструктуру цензуры и прочее - да пожалуйста. Не мучает совесть, не страшно за себя и близких - ну прекрасно же, оставайтесь в своем мире розовых слоников. Только я с вами такими - работать совместно не хочу. Я считаю вас опасными, вы с моей точки зрения, неадекватны - до тех пор, пока не осознаете то, что вы делаете, пока не станете делать что-то в противовес. Мне страшно за любую компанию, в которую вы поступите работать, с такими взглядами вы можете нанести ей непоправимый вред.
Читайте, спрашивайте https://habr.com/ru/articles/933582/
рад помочь
Продолжнаем эксперименты, теперь с самим storage https://habr.com/ru/posts/911224/
Разумеется, это огромное число, и это позволяет считать размер этих массивов на практике бесконечным.
Так хеш и есть keccak256. Он именно так вычисляется, берется побайтное представление пары (key, slot) и для этого представления вычисляется keccak256.
Не только на урезанном пространстве, но и на соответственно урезанном keccak. Я рассуждал так: если keccak256 доказанно приводит к максимальной энтропии на своем пространстве значений (то есть иначе говоря, он является в этом смысле хорошей хеш-функцией), то и любая выборка бит из его значения будет также приводить к максимальной энтропии на соответствующем урезанном пространстве значений.
Кстати, использование урезанной выборки бит значения keccak256 является распространенной практикой и в самой EVM. Например, адреса контрактов и индивидуальных счетов тоже являются результатом сходной операции. Вот что мне сообщил MS Copilot:
Таким образом, любой адрес в Ethereum - это результат выборки последних 20 байт из результата применения keccak256 к какой-то последовательности байт.
Написал продолжение
Разумеется. Однако напомню, что мы имеем дело не только с "точной" коллизией, когда разные исходные данные приводят к вычислению одного и того же ключа, но и "приблизительной", когда вычисленные ключи оказываются достаточно близко (с точки зрения разницы между значениями) друг от друга, чтобы оказать воздействие на сохраненные со смещением данные (в большом массиве или структуре).
Во-первых, наличие коллизий у keccak256 как и любой другой хеш-функции, когда хешируемое значение длиннее, чем ключ - факт, который легко доказывается математически, исходя из количества возможных состояний хешируемого значения. Если вы хешируете скажем, 512 бит, то количество возможных значений будет 2^512, а количество значений хеша - только 2^256. Таким образом, будет истинным следующее высказывание: существует такое значение хеша X, для которого найдется не менее 2^256 коллизий в указанных условиях.
И во-вторых, нет, обнаружение коллизий в этом случае никак не влияет на криптографическую стойкость, и "взломом" ключа это не является, а является проблемой, которую я описал, не больше, но и не меньше.
Было довольно мучительно оставлять отзыв, поскольку regulation блокирует адреса извне, но доступен через бесплатный росс-vpn, а вот esia наоборот - доступен с внешних адресов, но зато блочит публичные росс-vpn. Однако пробился, вовремя включая и выключая!
Так-то бред канешн.
Разумеется, всегда сразу все выкладываю
https://pypi.org/project/django-import/
Статью я уже писал, см. по ссылке, с тех пор мало что изменилось.
Хабр обещал отделять новости от статей, ну я и написал новость, и пометил как новость. Какой еще контент нужен в новости? Есть событие - расширена совместимость пакета. Вот вам новость об этом. Яхз, что тут еще можно написать-то.
Хм. Ну, скажем так, что касается настройки списка доступных к импорту моделей и хранилища файлов, так это вряд ли поменяется в рантайме, тем более что хранилище поменять в рантайме вообще будет весьма затруднительно.
А вот флаг синхронного/асинхронного запуска импорта можно было бы включить в задание, но я подумал, что такая кастомизация только вредна, поскольку влияет на нагрузку узлов в большом распределенном проекте. По сути, синхронный запуск - это затычка для локально запущенного сервера, а продакшн должен конечно, запускаться с асинхронным запуском всегда.
Ох вот ведь, поймал :) Давай PR, замержу. Ну или как будет момент, сам поправлю.
Да, недавно об этом же подумал. Удаление моделей - дело редкое и кажется, я встречался с тем, что это мешало сложным миграциям. Но возможность такая есть, да. Я помню был проект где это реально произошло и там из за этого были неприятности, связанные то ли с джанговскими правами, то ли с сохраненными фикстурами ...
UPD вспомнил. В частности, в списке раздаваемых прав в джанговской админке пользователей и групп выводились как раз права на отсутствующие модели, отличающиеся странными вывертами в отображении. Ну и фикстуры с отсутствующими моделями не импортируются конечно ...
Поправил описание в README. Детальные примеры можно посмотреть в коде пакета, в каталоге
examples. Там все давно переделано так, как надо. Если есть идеи или поправки, приглашаю в контрибуторы.Согласен, примеры подустарели, поправлю, особенно насчет полей. В оправдание скажу, что система не занимается управлением доступом на уровне полей (что является одним из возможных направлений развития). В отличие от исходного кода, в README приведен упрощенный пример. Тем не менее, управление доступом полями в нем нужно видимо вовсе исключить, чтобы не вводить в заблуждение читателей.
Что касается вычисления прав "на лету", то этим страдает как раз таки родная джанговская система управления правами, когда на полном серьезе предлагает вычислять их как
user.has_perm(..., obj)на инстансе модели (в то время как данный пакет сохраняет использованиеhas_perm()только для обратной совместимости с проектами третьих сторон). Поэтому никакой инициализации 100 объектов для пользователя не произойдет. Объекты будут отобраны на этапе чтения из БД, и на выходе запрос выдаст только один инициализированный из базы объект.Описываемая система вычисляет права на основе фильтрации объектов в базе данных через
QuerySet, еще до того, как они стали инстансами модели. Это позволяет выбрать из базы только и исключительно те объекты, которые доступны данному пользователю, что как раз решает Вашу (как и мою, когда мне пришлось это делать для нашего проекта) проблему.Вам в любом случае надо выбирать из базы только те объекты, к которым имеет доступ пользователь. Система позволяет встроить этот механизм, как универсальный, в ваш код.
Процессоры «Байкал» нужны нам для того, чтобы гарантированно получить компьютеры с закладками наших доблестных спецслужб. И вообще с т-щем майором в комплекте.
Да, я кажется слышал про эту планету, Плюк, если не ошибаюсь? Там еще цветовая дифференциация штанов ...
Хм. Мне пока никто не сообщил, что своим софтом я причинил кому-то такой вред, за который мне было бы стыдно. Если такое случится, я всерьез задумаюсь о способе нейтрализации этого вреда, по крайней мере мне на данный момент, такое поведение кажется вполне логичным. Мой манифест именно об этом, и если я призываю других к такому поведению, то да, конечно, я и сам готов покаяться таким вот образом - разрабатывая средства противодействия тому вреду, который необдуманно нанес, разработав опасный в применении софт.
мне кажется, или я слышу отголоски ликования в этом утолщенном шрифте? не радуйтесь так, можем и делаем. Но эта "гонка вооружений" не дает ничего, кроме бессмысленной траты ресурсов, человеческих и вычислительных, и повышение опасности нарушения целостности общей полезной инфраструктуры, используемой и вами в том числе.
Так что если уж переходить на личности, вот вы например, судя по краткому анонсу, работаете над Machine Learning, при этом мне хорошо известно, что немалое количество народу работает над машинным распознаванием типа шифрованного трафика. Так что мне нисколько не удивительно, что вы так взъелись на мой "манифест" - ведь вероятно, именно вы, или ваши коллеги, будете ответственны за то, что огромное количество вычислительных ресурсов, на которые столь охоч машинный интеллект, будет потрачено практически впустую, в попытках выделить, ограничить и оттрассировать шифрованный трафик, в котором правительства разных стран или крупные корпорации усмотрели какую-то опасность для себя.
И хорошо, если впустую, но пока мы сможем наложить столь качественный шум на этот трафик, что распознавать его станет полностью бесполезно, вполне вероятно, что какое-то количество невиновных людей в Китае, Иране, России, Белоруссии, Турции, Афганистане и еще где-то будет схвачено и посажено в тюрьму, а то и казнено в конечном итоге, именно стараниями вышеупомянутых разработчиков. И я могу только надеяться, что это не коснется вас и ваших близких. Хотя больше переживать я конечно, буду отнюдь не за вас, а за тех, уж точно непричастных пользователей, кто вашими стараниями получит сетевые тормоза и повышение тарифов.
И да, я не говорю о вреде другого софта, потому что этот пост именно про тот софт, который служит для наведения цензуры. Я не хочу пытаться объять необъятное и вы конечно правы, что я пишу о том, что меня волнует прямо сейчас, поскольку я действительно пишу из России.
Возвращаясь же к тем, кто (видимо вместе с вами) участвует в разработке обсуждаемой категории софта, то как я уже писал раньше, мое отношение к каждому из этой категории разработчиков действительно будет сильно детерминировано его отношением к тому, что он успел сделать. В том числе и при приеме его на работу, если и когда я буду в этом участвовать.
Участь же "смириться с неизбежным" я оставлю вам, вам это понадобится.
Перечитайте пожалуйста ваш комментарий, и приведите его в порядок. На настоящий момент, он выглядит бессистемным. Наверно, вы писали его в сильном эмоциональном возбуждении. Я ничего не понял.
Какую именно "ситуацию" я по вашему мнению, "примерил на себя" и "экстраполировал"?
Где именно вы нашли "утверждения об очевидности"?
Где именно я утверждал, что описываемое ПО "плохое"?
Вы уверены, что поняли, каким именно способом я предлагаю "покаяться" за создание опасного в применении ПО?
Вы уверены, что я "осуждаю" людей именно за "убеждения"?
Ваш пассаж про комплекс бога с заглавной буквы я оставляю на скобками, как манипулятивный и риторический.
LGPL или совместимая, не принципиально, я отвечал выше
Про остальное опущу
Уж мемом стало. Отдавая свободу за безопасность, вы в конечном итоге, лишаетесь и свободы, и безопасности
https://ru.citaty.net/tsitaty/635014-tomas-dzhefferson-tot-kto-otdaiot-svoiu-svobodu-za-bezopasnost-ne-p/
Еще раз, последний, призываю вас читать внимательно текст, на который вы пишете возражение.
Вы вероятно, считаете, что если вы назвали что-то "protection", этого достаточно, чтобы говорить о том, что оно не приносит никому вреда. Но это не так.
Уверяю вас, 90% информации из банков и госорганов, попавшие в руки проходимцам, попали туда вовсе не из за недостаточной "protection" со стороны какого бы то ни было софта. Проблема многочисленных "protection" была и остается в том, что они фигурально выражаясь, пытаются ставить сейфовую дверь в недостроенный забор. Об эту дверь с матюками спотыкаются добросовестные пользователи, в то время как "проходимцы" спокойно проходят через дыры в заборе. И забор - это далеко не только и не столько софт. Основной источник утечек был и остается - нелояльность и некомпетентность ответственных лиц. Пока этот источник в наличии - бороться с ним с помощью одного софта - бессмысленно и вредно, а тот, кто изъявляет горячее желание это делать - вольно или невольно является обманщиком.
Используйте https, системы распределения доступа, антивирусы, лояльных и компетентных сотрудников - и у вас в 99% случаев не будет никаких утечек.
Про электропочту вы как будто и вовсе не прочитали... мда.
Про админов и прочих - вы правильно отметили. Предлагайте способы. Например, техпис может описать недокументированные фичи.
Насчет юристов и адвокатов - поищите кого-нибудь, кто расскажет вам, какие именно юридические последствия наступают у нас от использования VPN (спойлер - никаких).
Да ничего я не требую, кроме одного - будьте от меня подальше. Хотите разрабатывать DLP, поддерживать инфраструктуру цензуры и прочее - да пожалуйста. Не мучает совесть, не страшно за себя и близких - ну прекрасно же, оставайтесь в своем мире розовых слоников. Только я с вами такими - работать совместно не хочу. Я считаю вас опасными, вы с моей точки зрения, неадекватны - до тех пор, пока не осознаете то, что вы делаете, пока не станете делать что-то в противовес. Мне страшно за любую компанию, в которую вы поступите работать, с такими взглядами вы можете нанести ей непоправимый вред.