GitHub раскрыл сведения об уязвимости, позволяющей получить доступ к содержимому переменных окружений, выставленных в контейнерах, применяемых в рабочей инфраструктуре. Уязвимость была выявлена участником программы Bug Bounty, претендующим на получение вознаграждения за поиск проблем с безопасностью. Проблема затрагивает как сервис GitHub.com, так и конфигурации GitHub Enterprise Server (GHES), выполняемые на системах пользователей...Подробнее: https://www.opennet.me/opennews/art.shtml?num=60448
Что опять руби виноват?
Все равно что предъявить вину молотка криворукому плотнику. Язык это всего лишь инструмент.
Топор с надпиленным топорищем - тоже, вроде бы, топор
>Начиная с 23 января все новые коммиты, подписанные прошлым ключом, не будут помечены на сайте GitHub как верифицированные.
>Замена внутренних ключей привела к нарушению работы некоторых сервисов с 27 по 29 декабря.Если ключ не скомпромитирован, то нафига его отзывать, нарушая функционирование. Если скомпромитирован, то почему такой поздней датой? Почему вообще подтверждённость выполненности коммита в веб-интерфейсе GitHub определяется подписью на коммите, а не наличием хэша коммита в множестве, хранимом на сервере GitHub и доступном для скачивания?
> Если ключ не скомпромитирован, то нафига его отзывать, нарушая функционирование.На всякий случай перестраховались? Чтобы потом не влияло, если активность позже всё-таки обнаружат (к тому времени, ключ будет отозван). Либо, в анонсе нам дали не всю информации. В целом, спорный момент.
> Почему вообще подтверждённость выполненности коммита в веб-интерфейсе GitHub определяется подписью на коммите, а не наличием хэша коммита в множестве, хранимом на сервере GitHub и доступном для скачивания?
Первичная сущность здесь git, а веб-инструменты только обвязка над ним. «Подтвержденность выполненности коммита» не определяется подписью в коммите (подписи может и не быть). Отдельно какую-то несовместимую с git-ом историю хэшей хранить нет смысла, если весь нужный функционал можно сделать средствами самого git.
> Первичная сущность здесь git, а веб-инструменты только обвязка над ним.Ну это не верно в корне.
Без этой обвязки гит это смешное скопление костылей никому кроме "кернел девелоперс" рассылающих патчи емейлами ненужное.В то-же время, поменяй гитхаб гиб на нечто иное, даже не очень совместимое - ничего не измениться, особо упоротые "громкие голоса" поноют и схавают, а энтерпрайзу вообще пофиг, лишь бы была двухкнопочная миграция.
Чего же все меркуриалом не пользуются он же во всем лучше.
Ну вот bitbucket поменял меркуриал на git - что, все пользователи разбежались? Проделает такой же кунштюк github - так же ничего не изменится. ВоЙены будут воевать, борцуны - бороцца, а индус-триальные погроммизды - погроммиздить.
> Без этой обвязки гит это смешное скопление костылей никому кроме "кернел девелоперс" рассылающих патчи емейлами ненужное.Обвязка дополняет git, и вообще опциональна. Она красивая, удобная и прочее — но быстро потеряет популярность, если убрать git.
Думаю, практически проверять GitHub это не будет.
>Первичная сущность здесь git, а веб-инструменты только обвязка над ним. «Подтвержденность выполненности коммита» не определяется подписью в коммите (подписи может и не быть).Отозванный ключ - это ключ, которым сам GitHub подписывал коммиты, когда они были сделаны в его веб-интерфейсе, как-бы подтверждая, что его сделал тот аккаунт, который написан в авторах коммита. Так можно было проверить историю локально: скачать ключ, и проверить. Но история связана цепочкой хэшей, и хэшируется в том числе подпись. Ключ был скомпрометирован - все подписи стали невалидными. А ведь кто-то мог на эту проверку полагаться в своих workflowах... А теперь полагаться не могут. Даже сам гитхаб не может. Если бы они просто насохраняли хэши тех коммитов, то не было бы проблемы.
Начать с того, что такие ключи, сгенерированные самой платформой — лишь ограниченно полезны. Они не определяют автора коммита, а определяют пользователя сервиса (доверие в рамках одной платформы). Если человек идёт на другую платформу, то там ему генерируют другой ключ — кроссплатформенного доверия здесь нет, и вопросы по критичным воркфлоу и проверкам должны начинаться уже здесь.Хранить хэши коммитов отдельно не нужно: есть дата в коммите и дата отзыва ключа — всё, что позже, по воркфлоу декларируется невалидным. Понятно, что это неудобно и требует телодвижений. Но когда платформа произвольно генерирует ключи — то стоит ожидать, что и отзывает их она по своему усмотрению. Если нужно контролируемый воркфлоу — то ключ создаётся на своей стороне и используется при коммитах, в платформы вгружается публичная часть. Его можно отзывать контролируемо.
>Либо, в анонсе нам дали не всю информации.Ты думаешь что тут есть часть инфлрмации правдивой. Мнда... как все пичально
PGP или GPG?
Пора вводить шестифакторную авторизацию.
Я один подумал, что ущербна сама идея централизованного храниния секретных ключей на GitHub?Ведь именно по этой причине появилась эта уязвимость...
Ущербны любые децентрализованные системы, а централизация и строгая вертикаль - путь к порядку и стабильности.
Следить за людьми тредно да?