| |
| 2.28, Аноним (28), 00:25, 18/01/2024 [^] [^^] [^^^] [ответить]
| +/– |
Все равно что предъявить вину молотка криворукому плотнику. Язык это всего лишь инструмент.
| | |
|
| 1.6, Аноним (6), 14:27, 17/01/2024 [ответить] [﹢﹢﹢] [ · · · ]
| –3 +/– |
>Начиная с 23 января все новые коммиты, подписанные прошлым ключом, не будут помечены на сайте GitHub как верифицированные.
>Замена внутренних ключей привела к нарушению работы некоторых сервисов с 27 по 29 декабря.
Если ключ не скомпромитирован, то нафига его отзывать, нарушая функционирование. Если скомпромитирован, то почему такой поздней датой? Почему вообще подтверждённость выполненности коммита в веб-интерфейсе GitHub определяется подписью на коммите, а не наличием хэша коммита в множестве, хранимом на сервере GitHub и доступном для скачивания?
| | |
| |
| 2.12, Denis Fateyev (ok), 17:55, 17/01/2024 [^] [^^] [^^^] [ответить]
| +/– |
 > Если ключ не скомпромитирован, то нафига его отзывать, нарушая функционирование.
На всякий случай перестраховались? Чтобы потом не влияло, если активность позже всё-таки обнаружат (к тому времени, ключ будет отозван). Либо, в анонсе нам дали не всю информации. В целом, спорный момент.
> Почему вообще подтверждённость выполненности коммита в веб-интерфейсе GitHub определяется подписью на коммите, а не наличием хэша коммита в множестве, хранимом на сервере GitHub и доступном для скачивания?
Первичная сущность здесь git, а веб-инструменты только обвязка над ним. «Подтвержденность выполненности коммита» не определяется подписью в коммите (подписи может и не быть). Отдельно какую-то несовместимую с git-ом историю хэшей хранить нет смысла, если весь нужный функционал можно сделать средствами самого git.
| | |
| |
| 3.14, Аноньимъ (ok), 18:28, 17/01/2024 [^] [^^] [^^^] [ответить]
| –2 +/– |
 > Первичная сущность здесь git, а веб-инструменты только обвязка над ним.
Ну это не верно в корне.
Без этой обвязки гит это смешное скопление костылей никому кроме "кернел девелоперс" рассылающих патчи емейлами ненужное.
В то-же время, поменяй гитхаб гиб на нечто иное, даже не очень совместимое - ничего не измениться, особо упоротые "громкие голоса" поноют и схавают, а энтерпрайзу вообще пофиг, лишь бы была двухкнопочная миграция.
| | |
| |
| |
| 5.20, User (??), 20:43, 17/01/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
Ну вот bitbucket поменял меркуриал на git - что, все пользователи разбежались? Проделает такой же кунштюк github - так же ничего не изменится. ВоЙены будут воевать, борцуны - бороцца, а индус-триальные погроммизды - погроммиздить.
| | |
|
| 4.22, Denis Fateyev (ok), 20:47, 17/01/2024 [^] [^^] [^^^] [ответить]
| +/– | |
> Без этой обвязки гит это смешное скопление костылей никому кроме "кернел девелоперс" рассылающих патчи емейлами ненужное.
Обвязка дополняет git, и вообще опциональна. Она красивая, удобная и прочее — но быстро потеряет популярность, если убрать git.
Думаю, практически проверять GitHub это не будет.
| | |
|
| 3.18, Аноним (18), 19:51, 17/01/2024 [^] [^^] [^^^] [ответить]
| +/– | |
>Первичная сущность здесь git, а веб-инструменты только обвязка над ним. «Подтвержденность выполненности коммита» не определяется подписью в коммите (подписи может и не быть).
Отозванный ключ - это ключ, которым сам GitHub подписывал коммиты, когда они были сделаны в его веб-интерфейсе, как-бы подтверждая, что его сделал тот аккаунт, который написан в авторах коммита. Так можно было проверить историю локально: скачать ключ, и проверить. Но история связана цепочкой хэшей, и хэшируется в том числе подпись. Ключ был скомпрометирован - все подписи стали невалидными. А ведь кто-то мог на эту проверку полагаться в своих workflowах... А теперь полагаться не могут. Даже сам гитхаб не может. Если бы они просто насохраняли хэши тех коммитов, то не было бы проблемы.
| | |
| |
| 4.23, Denis Fateyev (ok), 21:26, 17/01/2024 [^] [^^] [^^^] [ответить]
| +/– | |
Начать с того, что такие ключи, сгенерированные самой платформой — лишь ограниченно полезны. Они не определяют автора коммита, а определяют пользователя сервиса (доверие в рамках одной платформы). Если человек идёт на другую платформу, то там ему генерируют другой ключ — кроссплатформенного доверия здесь нет, и вопросы по критичным воркфлоу и проверкам должны начинаться уже здесь.
Хранить хэши коммитов отдельно не нужно: есть дата в коммите и дата отзыва ключа — всё, что позже, по воркфлоу декларируется невалидным. Понятно, что это неудобно и требует телодвижений. Но когда платформа произвольно генерирует ключи — то стоит ожидать, что и отзывает их она по своему усмотрению. Если нужно контролируемый воркфлоу — то ключ создаётся на своей стороне и используется при коммитах, в платформы вгружается публичная часть. Его можно отзывать контролируемо.
| | |
|
| 3.19, scriptkiddis (?), 20:18, 17/01/2024 [^] [^^] [^^^] [ответить]
| +/– | |
>Либо, в анонсе нам дали не всю информации.
Ты думаешь что тут есть часть инфлрмации правдивой. Мнда... как все пичально
| | |
|
|
| 1.24, Аноним (24), 23:23, 17/01/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Я один подумал, что ущербна сама идея централизованного храниния секретных ключей на GitHub?
Ведь именно по этой причине появилась эта уязвимость...
| | |
| |
| 2.27, Аноним (28), 00:23, 18/01/2024 [^] [^^] [^^^] [ответить]
| +/– |
Ущербны любые децентрализованные системы, а централизация и строгая вертикаль - путь к порядку и стабильности.
| | |
|
|
