GitHub быстро заменила приватный ключ RSA SSH, случайно слитый в паблик

GitHub быстро заменила приватный ключ RSA SSH, случайно слитый в паблик

GitHub быстро заменила приватный ключ RSA SSH, случайно слитый в паблик

Пользователей GitHub.com предупреждают о смене закрытого ключа RSA, который используется для защиты Git-операций, выполняемых через SSH. Причиной замены является его компрометация: секрет кратковременно был доступен в публичном репозитории, куда попал по недосмотру.

Меры предосторожности были приняты сегодня, 24 марта, в 05:00 UTC (в восемь утра по Москве). В противном случае злоумышленники смогли бы сымитировать хостинг-сервис или отслеживать операции юзеров, использующих SSH.

«Данный ключ не предоставляет доступ к инфраструктуре GitHub или клиентским данным, — пояснил глава ИБ-службы хостера Майк Хэнли (Mike Hanley). — Изменения коснутся лишь Git-операций, выполняемых по SSH с использованием RSA».

Входящий веб-трафик GitHub.com и Git-операции через HTTP не затронуты. Те, кто использует ключи ECDSA и Ed25519, изменений не заметят, и никаких действий от них не потребуется.

В тех случаях, когда при подключении к сайту по SSH отображается такое сообщение, следует удалить прежний ключ RSA и добавить новый:

 

Для удаления ключа нужно выполнить команду:

 

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

 

Работы по обновлению всех тегов еще не завершены, поэтому пользователи GitHub Actions, включившие опцию ssh-key, могут столкнуться с отказом actions/checkout. Свидетельств злонамеренного использования попавшего в паблик ключа не обнаружено.

По словам Хэнли, это случайный слив, а не результат компрометации систем GitHub либо клиентской информации, как два месяца назад. Тогда злоумышленникам удалось украсть сертификаты подписи кода для macOS-клиента GitHub и редактора Atom.

Android без лишнего контроля: LineageOS отказалась идти на поводу у Google

Пока Google готовится закрутить гайки для установки приложений на Android, команда LineageOS решила успокоить своих пользователей: на устройства с этой кастомной прошивкой новая система проверки разработчиков не повлияет.

Речь идёт об Android Developer Verification — механизме, который Google начнёт вводить с 30 сентября 2026 года.

Сначала правила заработают в Бразилии, Индонезии, Сингапуре и Таиланде, а в 2027 году распространятся глобально. Суть в следующем: приложения должны быть зарегистрированы на верифицированного разработчика; неважно, скачаны они из Google Play, стороннего магазина или установлены APK-файлом.

Для обычных сертифицированных Android-устройств с Google Mobile Services всё станет сложнее. Приложения от непроверенных разработчиков не заблокируют намертво, но пользователям придётся устанавливать их через новый продвинутый сценарий сторонней загрузки или через ADB.

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

Даже если пользователь сам установит Google-приложения через GApps, команда LineageOS не ожидает, что такие пакеты начнут включать спорную функцию: кому вообще нужен GApps, который добровольно делает установку APK больнее?

Разработчики допускают, что Google однажды может перенести проверку в Play Services. Но и тут позиция LineageOS непоколебима: если такое случится, функцию просто отключат, как уже делают с некоторыми механизмами обновлений на базе Play Services.

При этом LineageOS не спорит с тем, что борьба с вредоносными приложениями нужна. Но проект разделяет опасения F-Droid, EFF и кампании Keep Android Open: под видом безопасности Google может получить ещё больше контроля над распространением приложений на Android. Поэтому LineageOS подписала петицию Keep Android Open вместе с другими опенсорс-организациями.

RSS: Новости на портале Anti-Malware.ru