И вроде да, всё взламывается, со всем согласен, но как же хочется хотя бы одну ссылочку в статье бы увидеть, где описано реальное применение такого вектора атаки (откуда-то же вы эти факты брали)
Я пару раз что-то подобное в Интернете встречал, типа исследователи считали дангые с hdd по его вибрациям и т.д., но это всё же просто исследователи пока что
Долгое время пользовался, вроде удобный интерфейс, все дела, но по факту тонкая настройка всё равно требует знания docker. Плюс при обновлении версии casaos у меня сбрасывались часть контейнеров, видимо breaking changes в нотациях. Если знаешь docker - проще в docker compose запускать
mailcow - отличный вариант, можно и его, вот только кажется они так и не добавили OIDC/LDAP, хотя, справедливости ради, и в Poste.io их нет. Не включал в список, потому что не разворачивал ни разу, поэтому нечем поделиться
huly.io - тоже, кажется, классная система, надо пробовать. Обычно не использую доски в гит хостингах по причине того, что на досках ещё могут висеть задачи для дизайнеров/продуктов, тогда gitea для них
passbolt - тоже звучит как отличный вариант
C matrix могут быть сложности по взаимодействию, Mattermost всё-таки создан как корпоративный чат с удобным интерфейсом групп/каналов, меншенами и интеграцией, чтобы сделать подобное в Matrix - нужно применить больше усилий, а в качестве звонков лучше вообще стороний сервис без интеграции найти (кстати, тот же Rocket.Chat, кажется, умеет в звонки из коробки)
Супер, VPN точно надо
Nextcloud отлично подходит как файлохранилище, если бесит интерфейс - можно интегрировать его в рабочий компьютер через samba или ftp
Сравнили Willow не с самым мощным компьютером, а со 2 в мире самым мощным компьютером - это прям придирка
Есть компьютеры с 1000 кубитами, а тут всего 105 - вот компьютеры с 1000 кубитами как раз и были маркетингом, потому что часто это было несколько незапутанных друг с другом систем. Есть надежда, что 105 кубитов у Willow - всё же чистая запутанная система, отсюда такие бенчмарки
Для вас (ведь у вас будет опыт и навыки работы в команде, понимание того, как появляются и развиваются IT продуты), для будущего работодателя (ведь у него будет возможность нанять более квалифицированного специалиста), ну и, в конце концов, для мира
protoc генерирует файлы с абсолютным импортом, то есть если он генерирует файл greeter_pb2.py, то в соседнем greeter_pb2_grpc.py будет импорт `import greeter_pb2`. Есть несколько решений, но все они требуют каких-то действий:
Руками изменить импорт на относительный
В модулях нашего приложения добавить путь к директории сgreeter_pb2.py в sys.path для простого импорта.
Помещать сгенерированные файлы в корень проекта
Изначально сгенерированный код не проходит линтеры, варианты:
Править руками
Править автоматически
Не править и добавить в исключения
Лично мне не нравится добавлять в игнорирование Python модуль, который явно добавляется в репозиторий, но это ИМХО.
Если честно, у меня пока нет мыслей других опций, как можно эти две проблемы решать по другому
Со всем согласен, с перечисленными проблемами в gRPC столкнулся ещё на работе, но хочу поспорить с тем, что если gRPC - это про экстремальные нагрузки, то и Python будет узким местом. Мне кажется, что это не всегда справедливо, ведь большая нагрузка на сеть (соответственно требуется экономия трафика и увеличение скорости передачи) не всегда связаны с невозможностью этот трафик обработать. Например, сеть у нас ограниченная, а вот вычислительных ресурсов достаточно.
Очень хотел описать это и в статье, но не смог сформулировать. Если Python - интерпретируемый и относительно медленный, это не значит, что он не может решать задачи эффективно и работать с низкоуровневыми протоколами. Вопрос будет стоять скорее в том, насколько эффективно в определённой задаче Python сможет заниматься обработкой данных, полученных по этому самому протоколу
И насколько уместен gRPC в той или иной задаче - решать каждому отдельному программисту, но мне кажется что связка Python + gRPC имеет право на существование
Да нет, тут скорее в рамках пробы, как я и описывал, не было потребности в Sapphire уменьшать размер трафика (его в принципе пока почти нет), просто хотелось попробовать
Сейчас - никак, вы правы, но сама библиотека генерирует proto файл и на его основе делает gRPC сервер, совсем нет проблем так же в рантайме генерировать proto файл и получать его (или генерировать перед этим), а клиент уже генерировать на основе этого proto файла (или вообще чтобы сервер генерировал полноценный Python клиент).
Здесь я скорее хотел показать другой способ использования gRPC и упросить некоторые шаги. Опять же, если версионирование и обратная совместимость нужны, то конечно вариант с proto-файлом как основным источником - максимально полезный. Но в тех случаях когда это не очень важно, думаю, что такая библиотека была бы удобным инструментом, это позволяет быстро поднять gRPC интерфейс, посмотреть что да как
Да, в статье я как раз описал, что по моему мнению сам протокол абсолютно не сложный, в данном случае мною была попытка как раз убрать рутинные действия, чтобы разработчику в принципе было просто начать. Да и в принципе как разработчик всегда стараюсь убрать рутинные действия
За свою команду могу сказать, что нам проще и быстрее разделить сложную логику на маленькие части. Предполагаю, что так нам будет намного проще писать и даже если где-то будет заведомо плохая архитектура - она не будет распространятся дальше, как это могло бы быть в монолите
А есть примерны применения подобной атаки? Возможно, те самые модифицированные телефоны или другие устройства, которые такое делают?
(удалил)
И вроде да, всё взламывается, со всем согласен, но как же хочется хотя бы одну ссылочку в статье бы увидеть, где описано реальное применение такого вектора атаки (откуда-то же вы эти факты брали)
Я пару раз что-то подобное в Интернете встречал, типа исследователи считали дангые с hdd по его вибрациям и т.д., но это всё же просто исследователи пока что
Долгое время пользовался, вроде удобный интерфейс, все дела, но по факту тонкая настройка всё равно требует знания docker. Плюс при обновлении версии casaos у меня сбрасывались часть контейнеров, видимо breaking changes в нотациях. Если знаешь docker - проще в docker compose запускать
mailcow - отличный вариант, можно и его, вот только кажется они так и не добавили OIDC/LDAP, хотя, справедливости ради, и в Poste.io их нет. Не включал в список, потому что не разворачивал ни разу, поэтому нечем поделиться
huly.io - тоже, кажется, классная система, надо пробовать. Обычно не использую доски в гит хостингах по причине того, что на досках ещё могут висеть задачи для дизайнеров/продуктов, тогда gitea для них
passbolt - тоже звучит как отличный вариант
C matrix могут быть сложности по взаимодействию, Mattermost всё-таки создан как корпоративный чат с удобным интерфейсом групп/каналов, меншенами и интеграцией, чтобы сделать подобное в Matrix - нужно применить больше усилий, а в качестве звонков лучше вообще стороний сервис без интеграции найти (кстати, тот же Rocket.Chat, кажется, умеет в звонки из коробки)
Супер, VPN точно надо
Nextcloud отлично подходит как файлохранилище, если бесит интерфейс - можно интегрировать его в рабочий компьютер через samba или ftp
Делай правильно, а неправильно - не делай
Где мои 450к в месяц?
Не смог пропустить 2 момента:
Сравнили Willow не с самым мощным компьютером, а со 2 в мире самым мощным компьютером - это прям придирка
Есть компьютеры с 1000 кубитами, а тут всего 105 - вот компьютеры с 1000 кубитами как раз и были маркетингом, потому что часто это было несколько незапутанных друг с другом систем. Есть надежда, что 105 кубитов у Willow - всё же чистая запутанная система, отсюда такие бенчмарки
Для вас (ведь у вас будет опыт и навыки работы в команде, понимание того, как появляются и развиваются IT продуты), для будущего работодателя (ведь у него будет возможность нанять более квалифицированного специалиста), ну и, в конце концов, для мира
Это ответ! Как и в любых отношениях, двигаться навстречу должны двое или кто-то один, но как танк)
По поводу лёгкости - мне либо по жизни не везёт, либо я сам ищу работу, в которой прям сложно
Да, важно просить не больше задач, а задачи сложнее. Если их в компании нет, тогда и роста в компании тоже нет(
Думаю, что если это действительно интересно, то расскажем,
Всего оказалось две проблемы:
protoc генерирует файлы с абсолютным импортом, то есть если он генерирует файл greeter_pb2.py, то в соседнем greeter_pb2_grpc.py будет импорт `import greeter_pb2`. Есть несколько решений, но все они требуют каких-то действий:
Руками изменить импорт на относительный
В модулях нашего приложения добавить путь к директории с
greeter_pb2.pyвsys.pathдля простого импорта.Помещать сгенерированные файлы в корень проекта
Изначально сгенерированный код не проходит линтеры, варианты:
Править руками
Править автоматически
Не править и добавить в исключения
Лично мне не нравится добавлять в игнорирование Python модуль, который явно добавляется в репозиторий, но это ИМХО.
Если честно, у меня пока нет мыслей других опций, как можно эти две проблемы решать по другому
Со всем согласен, с перечисленными проблемами в gRPC столкнулся ещё на работе, но хочу поспорить с тем, что если gRPC - это про экстремальные нагрузки, то и Python будет узким местом. Мне кажется, что это не всегда справедливо, ведь большая нагрузка на сеть (соответственно требуется экономия трафика и увеличение скорости передачи) не всегда связаны с невозможностью этот трафик обработать. Например, сеть у нас ограниченная, а вот вычислительных ресурсов достаточно.
Очень хотел описать это и в статье, но не смог сформулировать. Если Python - интерпретируемый и относительно медленный, это не значит, что он не может решать задачи эффективно и работать с низкоуровневыми протоколами. Вопрос будет стоять скорее в том, насколько эффективно в определённой задаче Python сможет заниматься обработкой данных, полученных по этому самому протоколу
И насколько уместен gRPC в той или иной задаче - решать каждому отдельному программисту, но мне кажется что связка Python + gRPC имеет право на существование
Уже сейчас есть возможность включить рефлексию, но возможно было бы лучше, если бы рефлексия была включена по умолчанию, возможно, вы правы
Да нет, тут скорее в рамках пробы, как я и описывал, не было потребности в Sapphire уменьшать размер трафика (его в принципе пока почти нет), просто хотелось попробовать
Сейчас - никак, вы правы, но сама библиотека генерирует proto файл и на его основе делает gRPC сервер, совсем нет проблем так же в рантайме генерировать proto файл и получать его (или генерировать перед этим), а клиент уже генерировать на основе этого proto файла (или вообще чтобы сервер генерировал полноценный Python клиент).
Здесь я скорее хотел показать другой способ использования gRPC и упросить некоторые шаги. Опять же, если версионирование и обратная совместимость нужны, то конечно вариант с proto-файлом как основным источником - максимально полезный. Но в тех случаях когда это не очень важно, думаю, что такая библиотека была бы удобным инструментом, это позволяет быстро поднять gRPC интерфейс, посмотреть что да как
Да, в статье я как раз описал, что по моему мнению сам протокол абсолютно не сложный, в данном случае мною была попытка как раз убрать рутинные действия, чтобы разработчику в принципе было просто начать. Да и в принципе как разработчик всегда стараюсь убрать рутинные действия
Я когда читал курсы давал такую задачку на самостоятельную работу в классе, правда в ней предполагалось использовать регулярные выражения: https://informatics.msk.ru/mod/statements/view.php?id=3163#1
За свою команду могу сказать, что нам проще и быстрее разделить сложную логику на маленькие части. Предполагаю, что так нам будет намного проще писать и даже если где-то будет заведомо плохая архитектура - она не будет распространятся дальше, как это могло бы быть в монолите