GitHub сообщил об инциденте, в результате которого закрытый RSA-ключ, используемый в качестве хостового ключа при доступе к репозиториям GitHub по SSH, по ошибке оказался опубликован в публично доступном репозитории. Для исключения возможного перехвата сеансов SSH к GitHub в случае попадания RSA-ключа в руки злоумышленников, GitHub инициировал процесс замены ключа...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=58858
Сколько пайплайнов поломало интересно...
actions/checkout обновили сразу: https://github.com/actions/checkout/pull/1237
У них что и серверный код в github actions выполняется на typescript(javascript)? А что например написать там на скажем я хз C++/Python/Go уже никак?
Сейчас модно на ts/js
да они и сами по себе от фазы луны ломаются
имел дело с как минимум битрайсом и аппцентром
И доходило до смешного, когда, в 8 из 10 случаев всё норм, но вот в 2 оставшемся - один и тот же коммит может не компилиться 1-2-3-4 раза, выдавая неведомые ошибки, а после - взять и норм скомпилиться
И получалась неприятная ситуация, когда, вроде бы всё настроено и релиз вечером пятницы автоматический, а по факту - приходилось ждать несколько часов чтобы хреновина гарантировано всё собрала и выдала готовые сборки ведь она в среднем гораздо слабее компа для разработчика, с твердотельником, кучей ОЗУ и мощным ЦП. Ведь CI/CD же. Тамм, скрамы да адгилы опять же
> релиз вечером пятницы автоматическийесли вам дороги жизнь и здравый рассудок, держитесь подальше от ИТ болот.
там водятся такие баги и временные парадоксы, что понедельник может запросто начаться в субботу.
А где это "автоматические релизы" ставят?! Чейнж, релиз-инженер, QA - только так.
All your base are belongs to us.
девляп-ляп-ляп-ляп-ляп.infrastructure as a cocococococode!
все ключи от всего - вот они, кучкой.
Проморгать ключи может любой, а вот обновление колючей на инфраструктуре такого размера в такие сроки — только благодаря автоматизации. Ручным админам такое не снилось даже.
Ручные админы тоже умеют автоматизировать процессы - внезапно.
Вот только любой процесс такой важности ими пристально контролируется, в отличие от девтяпляпляп.
да ну, чего там контролировать. Ключи такого вот сорта у меня будут прибиты к образу гвоздиком.
Они ж во-первых как раз принципиально не должны меняться, иначе все попереломается в ста тыщах мест, во-вторых должны быть в каждом инстансе идентичны, и в третьих в такой системе этих инстансов дофига и они должны новые создаваться вот прямо на лету. Я и вспоминать о них не буду. И ни в какой гитляп и шитхап (и даже в локальный svn с авторизацией и доступами только к части дерева) ключ никогда не попадет, потому что вне его.А если все же зачем-то поменяли и понадобится обновлять везде - то тут не наавтоматизируешься на самом деле. Потому что known_hosts реально бывает в совершенно бредовых локациях и заманаешься все искать.
Опять же дзякую тоби Г-ди шо я не девляпс, и у меня число хостов - счетно, поэтому я могу их просто глобальным перебором найти все.
Но в целом ситуация была бы так себе.Пока вроде никто не прибегал, поэтому я тихо надеюсь что у нас в конторе нет настолько долбанутой continuous desintegration чтоб еще и на гитхап завязаться. Теоретически, ИБ должна за это отводить на -3й этаж и там заполнять бетоном очередную выемку в полу. Практически, как обычно, на них мало надежды.
Я эти сказки от ручных админов слышу регулярно. И про пристальный контроль, и про идеальную документацию, и про то, как всё под строгим контролем и учётом. Правда RTO почему-то у них в неделях измеряется, если не в месяцах. И bus-factor по факту 1, потому что идеальная документация не обновлялась уже год. Но это ж такие мелочи, бизнес подождёт месяц, авось не развалится.
Документация у них по крайней мере есть.
А не так как у девляпсов - сунешься, а там кот вместо инфраструктуры, простите, конь, который не валялся, и CentOS 5 где-нибудь есть. Автоматизированный по самое не хочу, вот только обновлять его с самого инсталла и не думали.
> infrastructure as a cocococococode!А что, они уже уволили вебманок в пользу chatgpt^W копилота?
Ну здрасьте, а у кого он по-твоему учиться должен?
Нахватался умных слов, но ещё не понял, что они значат?
предполагаю сценарий такой:
1) etckeeper
2) git на локалхосте был обучен (как ? кем ? зачем ?) публиковать все создаваемые репозитории
3) опубликовалось не туда.
например потому что кто-то кому-то дал установки не через e-mail в виде пригодном для копипста,
а через мессенджер с эмодзями или вообще голосом через квакающую ip телефонию.
> 3) опубликовалось не туда.туда, туда.
Все ключи от всего должны быть кучкой сложены в одном и том же месте.Таков путь инфраструктуры-ass-эээ....коде. Как вот чисто технически ты будешь один и тот же каталог в /etc из двух разных мест собирать?
Просто модный современный девляпс правил gitignore и забыл про какой-то там немодный и устаревший rsa. Надо будет в следующей версии вообще его запретить, и непременно из кода удалить вообще и из openssl тоже, чтоб луддиты не вернули как было, так и проблема решится.
> Как вот чисто технически ты будешь один и тот же каталог в /etc из двух разных мест собирать?как обычно, методом проб и ошибок. внутрь черных ящиков не полезу,
я не псих и не маньяк анализа кодовой базы.
хорошая попытка пересчитать активных юзверей:)
А до этого они не могли посчитать активных юзверей, они напрямую через libastral репозитории качали.
Странно, что только RSA, ведь они лежат все в /etc/ssh. Видимо как-то по другому хранят. Поэтому очень интересует КАК они утекли?