Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Сбои в системах сборки из-за изменения контрольных сумм архивов в GitHub"	+/–
Сообщение от opennews (??), 03-Фев-23, 18:03
GitHub изменил метод формирования автоматически генерируемых архивов ".tar.gz" и ".tgz" на страницах с релизами,... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=58595
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

1. Сообщение от Аноним (1), 03-Фев-23, 18:03	+16 +/–
Контрольная сумма должна рассчитываться самостоятельно каждым проектом своим способом по исходным файлам, а не сторонним архивам.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #6, #10, #14, #21, #131

2. Сообщение от Аноньимъ (ok), 03-Фев-23, 18:10	+6 +/–
Хвост виляет собакой.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #5, #35

5. Сообщение от Аноним (5), 03-Фев-23, 18:18	+1 +/–
ну виляет и виляет, что бубнить то
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #8

6. Сообщение от Аноним (-), 03-Фев-23, 18:20	+7 +/–
ну тогда пусть и хранят архивы у себя
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

8. Сообщение от Аноньимъ (ok), 03-Фев-23, 18:26	+7 +/–
> ну виляет и виляет, что бубнить то Главное не бухтеть, всё схвачено у кого нужно, вопрос под контролем, всё решат нужно только подождать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

9. Сообщение от Михаил (??), 03-Фев-23, 18:27	–2 +/–
Пихать в архив файл с контрольными суммами содержимого? Ну, действительно, проверять контрольную сумму архива - это как-то тупо, важна-то целостность содержимого.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #12, #13, #19

10. Сообщение от Аноним (10), 03-Фев-23, 18:31	–1 +/–
Да, пусть кто хочет делает gostsum или sha256.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

12. Сообщение от Шарп (ok), 03-Фев-23, 18:46	+1 +/–
Здесь контрольная сумма не для целостности, а для защиты от подмены.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #60, #111

13. Сообщение от keydon (ok), 03-Фев-23, 18:48	+2 +/–
Это нормально. Гораздо лучше чем иметь по контрольной сумме на каждый файл/директорию. А с пожатым архивом еще лучше - меньше размер, быстрее хэш вычислить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #85

14. Сообщение от Аноним (14), 03-Фев-23, 18:48	+5 +/–
> что привело к изменению их контрольных сумм и массовым сбоям как раз в духе микрософта.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #110

15. Сообщение от Аноним (14), 03-Фев-23, 18:53	+2 +/–
> редставители GitHub вначале ссылались на то, что постоянные контрольные суммы для архивов никогда не гарантировались. 2+2=4, а может 5 или 33.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #17, #68, #127

17. Сообщение от aploskov.dev (ok), 03-Фев-23, 19:05	+/–
gzip будет давать разные контрольные суммы при разных настройках сжатия по умолчнию. Можно оптимизировать на скорость сжатия, а можно - на размер архива. Кроме того, в результате оптимизации алгоритма сжатия может получиться иной файл. Высчитывать контрольную сумму от файла, который получен алгоритмом который может улучшаться и показывать лучшие результаты скорости/коэф. сжатия - это надо быть профнепригодным. Там отнюдь не 2+2, а f(...) = best( size, compression speed, decompression speed ).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #20, #48, #61

18. Сообщение от pashev.ru (?), 03-Фев-23, 19:11	+5 +/–
«Надо обновляться», — говорили они. — «Обновления важны и безопасны».
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #25, #70

19. Сообщение от Атон (?), 03-Фев-23, 19:21	+4 +/–
>> контрольную сумму архива - это защита от сбоев передачи данных по сети и ошибок носителей
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #125

20. Сообщение от Атон (?), 03-Фев-23, 19:22	+3 +/–
> gzip будет давать разные контрольные суммы при разных настройках сжатия а бывает архиватор, который дает одинаковые контрольные суммы при разных настройках сжатия?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #22, #30, #91, #122

21. Сообщение от НяшМяш (ok), 03-Фев-23, 19:24	–3 +/–
Я даже не знаю как они так формируют архивы, что у них контрольные суммы не совпадают. Формируют архив, делают сумму, а потом говорят гитхабу "заархивируй мне вот это но уже сам для себя" что ли? Обычно сначала пакуют, потом прогоняют чексумму и в конце заливают всё готовое. Чем паковать вообще фиолетово - хоть таргз, хоть 7з, хоть винраром.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #31

22. Сообщение от aploskov.dev (ok), 03-Фев-23, 19:24	+/–
>> gzip будет давать разные контрольные суммы при разных настройках сжатия > а бывает архиватор, который дает одинаковые контрольные суммы при разных настройках сжатия? Вряд ли. Разве что собранный на коленке, который игнорирует настройки, рандом, временные отметки, окружение и т.д.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #175

23. Сообщение от Аноним (23), 03-Фев-23, 19:26	+12 +/–
Да сколько раз уже повторять что гит это пятое колесо в телеге.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #54, #207

25. Сообщение от Аноним (25), 03-Фев-23, 19:39	+1 +/–
Для них - да)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18

26. Сообщение от Аноним (-), 03-Фев-23, 19:39	–2 +/–
> Рассматривались такие варианты, как [...] добавление флага "--stable" для сохранения совместимости Непредусмотрительно. Флаг надо называть --fucking-legacy, лет через десять будет очень актуально.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #99

27. Сообщение от fuggy (ok), 03-Фев-23, 19:40	+1 +/–
Они каждый раз для каждого вызова собирали архив? Неудивительно. Тем более что формировать архив каждый раз это долго. Человек загружая tar.gz ожидает что он скачивает только файл, а не сформированный архив на лету. Если бы они сохраняли бы уже созданные архивы, то проблема бы решилась более гладко.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #32, #133, #206

30. Сообщение от Аноним (-), 03-Фев-23, 19:53	–2 +/–
> архиватор, который дает одинаковые контрольные суммы Я подозреваю тебя тут кусают в зад твои вольные формулировки. Архиватор не даёт контрольных сумм, контрольные суммы считаются другими утилитами. Что архиватор может дать этим утилитам -- это совпадение файла бит-в-бит. Но смысла тогда в настройках сжатия, если вне зависимости от них, результат не меняется? Внешние утилиты могут считать контрольные суммы так, чтобы они оставались бы неизменными вне зависимости от архиватора. Можно контрольную сумму считать распаковывая, прогоняя через tar или любой другой сериализатор, чтобы объединить всё в один блоб, и считать sha512 по результату. Но чтобы этот блоб получался одинаковым бит-в-бит, придётся всё распаковать на диск, после чего упаковать приводя к каноническому виду. Это не получится делать потоковым пайплайном, потому что архиватор может в разном порядке файлы упаковывать, и надо сначала распаковать, потом упаковать, упорядочивая файлы (включая всякие тонкости, типа симлинков) канонично. Хотя, если так подумать, можно разработать какую-нибудь хеш-сумму, которая будет хеш-суммой хеш-сумм отдельных файлов, и не зависеть от порядка следования этих файлов. То есть можно что-нибудь потоковое придумать, да. То есть github зря прогнулся. Если бы он не прогнулся, то был бы повод разработать утилиту/библиотеку, которая в каком-то там простом виде принимает потоком неупорядоченную последовательность файлов, а на выходе выдаёт хешсумму, которая не зависит от порядка файлов и всяких сопутствующих факторов, типа хардлинков или что там ещё бывает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #40, #44, #121

31. Сообщение от ms (??), 03-Фев-23, 19:58	+3 +/–
Еще круче: говорят шитхабу - сформируй-ка нам архив _своего_ репо с ~нашим~ (мвахахаха) кодом. И сами мизинчиком так в экранчик тык-потык. А у нас оно вот такое - архив сами даже не знаем зачем (до нас писали) создается каждые пять минут заново, а ВДРУГ в репо сами собой изменились комиты пятилетней давности - обязательно надо переупаковать, нельзя ж просто так ничего не трогать, особенно старые срезы исходников.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #222

32. Сообщение от Аноним (-), 03-Фев-23, 20:00	+/–
> Человек загружая tar.gz ожидает что он скачивает только файл, а не сформированный архив на лету. Ты хотел сказать "_наивный_ человек"? Или может "человек склонный делать ничем не обоснованные выводы"? > формировать архив каждый раз это долго. Ты хотел сказать "дорого"? Ведь не важно, насколько это долго, потому что передавать по сети ещё дольше. Важно то, что это отнимает время процессора, которое ограниченный ресурс, и увеличивает сумму в квитанции за электроэнергию. Но хранить архив на диске занимает пространство на диске. И тут мы получаем tradeoff между стоимостью такого объёма диска и стоимостью сжатия на лету.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #34

34. Сообщение от ms (??), 03-Фев-23, 20:02	+/–
Вы это так говорите, как будто архив (причем вместе с контрольной суммой) сохранялся не на диск а куда-то в облачко... В принципе, он туда и сохранялся, только вот... это мое облачко, и внутри мои диски.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #46

35. Сообщение от ms (??), 03-Фев-23, 20:06	–2 +/–
Собака сама виновата. Какой вообще смысл в контрольных суммах исходников которые каждый день новые - сами не знаем. Это у них пережитки времен sourceforge, где архивы и исходники вообще никак не пересекались, что разработчик (или стыривший его пароли) залил, то и отдавалось. Вместо того чтоб эту глупость просто убрать, они вот, понаделали новых костылей а теперь обижаются, когда самый нижний вдруг выпал. Либо пусть доверяют целиком нашей инфраструктуре, либо не выпендриваются и делают каждый раз clone.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #132

36. Сообщение от Аноним (36), 03-Фев-23, 20:19	+3 +/–
посконный zip и то куда лучше.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #45, #112

40. Сообщение от Аноньимъ (ok), 03-Фев-23, 20:26	+1 +/–
Слишком усложняете...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30

41. Сообщение от ihatenpm (?), 03-Фев-23, 20:41	+2 +/–
гитшваб, нпм, карго-культ - это все только начало прогрессивных модных молодежных ультрасвободных и экстраудобных супертехнолгий.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #113

43. Сообщение от Аноним (54), 03-Фев-23, 20:51	+1 +/–
> В ответ на первые жалобы о возникших сбоях представители GitHub вначале ссылались на то, что постоянные контрольные суммы для архивов никогда не гарантировались. Вполне справедливо. А я-то раньше удивлялся: зачем некоторые люди на странице релизов Гитхаба выкладывают свой отдельный tar.gz архив, если по ссылке ниже есть автоматически сгенерированный Гитхабом. А вон оно что, оказывается! Вообще, классическая картина в разработке ПО: сперва недальновидно завязываемя на недокументированные делтали реализации, потом плачем, что все поломано.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #51, #144

44. Сообщение от Атон (?), 03-Фев-23, 20:57	+/–
> Хотя, если так подумать, с этого нужно начинать. всегда. > github зря прогнулся. Если бы он не прогнулся, то был бы повод разработать утилиту/библиотеку, он не прогнулся, он отложил на время.  тут у тебя не только повод, тут уже дедлайн преодолен. хотя мне другое странно: зачем вообще гитхаб озаботился настройкой оптимизации архиватора для получения архивов меньшего объема. на "диске" место кончается?  звоночек! Введите код, 58692
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30 Ответы: #47, #71

45. Сообщение от Атон (?), 03-Фев-23, 21:00	+1 +/–
> посконный zip и то куда лучше. для бинарников ARJ для текстов HA
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36 Ответы: #55, #74, #77

46. Сообщение от Аноним (-), 03-Фев-23, 21:02	+1 +/–
Ты имеешь в виду "сохранялся при создании на сервере"? Он сохранялся скорее всего в tmpfs, то есть на на диск, а в оперативную память. А контрольная сумма высчитывалась заносилась в субд. Точнее сказать, я не знаю, как там у них было сделано, но я б сделал именно так.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34

47. Сообщение от Аноним (-), 03-Фев-23, 21:03	–2 +/–
> зачем вообще гитхаб озаботился настройкой оптимизации архиватора для получения архивов меньшего объема. Чтобы меньше платить за трафик? А может дело не в размере, а в том сколько процессоры ватт сжигают?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44

48. Сообщение от Аноним (14), 03-Фев-23, 21:04	+4 +/–
> gzip будет давать разные контрольные суммы при разных настройках сжатия Не может быть! А мужики-то думали, что у всех любых архивов сумма одна и та же! Но тут оказалось, что разные файлы имеют... разные суммы! Да как так-то?!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #50

50. Сообщение от aploskov.dev (ok), 03-Фев-23, 21:09	–1 +/–
1. Прочитай новость. Действительно думали. 2. Посмотри, на какой комментарий я ответил. Чел иронизирует по поводу 2+2=4, а может 5 или 33. Ну так вот, операция не 2+2, иронию аноним выразил через жопу.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48 Ответы: #59

51. Сообщение от ms (??), 03-Фев-23, 21:11	+/–
> недальновидно завязываемя на недокументированные делтали реализации, потом плачем, что > все поломано. Разьве не логично предполагать что архив конкретной версии софта - нечто неизменное и постоянное? А, действительно, нелогично. Пришлите нам резюме, вы подходите на позицию pr менеджера.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43 Ответы: #53, #57

53. Сообщение от Аноним (54), 03-Фев-23, 21:25	+/–
> предполагать Как бы в этом вся суть проблемы, не? Ну, предполагайте на здоровье вместо чтения документации - только не плачте потом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51

54. Сообщение от Аноним (54), 03-Фев-23, 21:31	–3 +/–
Все проблемы индустрии в том, что никто не читает опеннетных экпертов...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #58, #62

55. Сообщение от Аноним (-), 03-Фев-23, 21:46	+/–
Надо на zstd переходить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45

57. Сообщение от Аноним (57), 03-Фев-23, 22:23	–1 +/–
кого волнует твой архив. бери исходный файл конкретной версии и наслаждайся неизменной контрольной суммой.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51 Ответы: #105

58. Сообщение от анонна (?), 03-Фев-23, 22:29	–3 +/–
он и прав и не прав. гит должен быть свой. на своем серваке, а не у мелкосранска(мелкософинска?) в х** знает где. люди пошли такие доверчивые. вот раз пришел приказ партии в сша и все все твои проекты конфискуются с передачей прав другим компаниям. а вас назовут потом плагиатором)) сама идея гит хороша, но предполагалось не общественный гит, а каждой конторы свой.))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54 Ответы: #69

59. Сообщение от Аноним (14), 03-Фев-23, 22:37	+/–
Думали-думали, да недодумали... В результате всё навернули, как обычно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50

60. Сообщение от Sw00p aka Jerom (?), 03-Фев-23, 22:43	+/–
>для защиты от подмены для этого контрольную сумму подписывают, а сама сумма - контроль целостности
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #75, #134

61. Сообщение от Sw00p aka Jerom (?), 03-Фев-23, 22:47	+/–
>это надо быть профнепригодным. то есть, снимаем сумму с самих данных, а не с сжатых архивов
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17

62. Сообщение от Sw00p aka Jerom (?), 03-Фев-23, 22:50	–1 +/–
эксперты на опеннете появились за долго до появления всех этих проектов, mc не даст соврать :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54

68. Сообщение от Аноним (68), 03-Фев-23, 23:02	+/–
Ну как бы 2+2 это 22.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

69. Сообщение от Аноним (69), 03-Фев-23, 23:03	+3 +/–
> сама идея гит оверинженеринг
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58 Ответы: #81

70. Сообщение от ms (??), 03-Фев-23, 23:05	–3 +/–
Вам количество CVE в гите напомнить за последние пол-года? Да, нам тоже приходится обновляться. Во-первых из-за них, во-вторых, если мы не будем поддерживать все вчера высосанные из пальца фичи, смузихлебы могут побежать на гитляп, где уже обновили и поддерживают.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #98

71. Сообщение от ms (??), 03-Фев-23, 23:08	+1 +/–
> хотя мне другое странно: зачем вообще гитхаб озаботился настройкой оптимизации архиватора для > получения архивов меньшего объема. Это не мы. Это разработчиков git спросите, сколько битов они сэкономили на своем новом 20терабайтнике. Мы же внутри используем их поделку as-is, а не переписали все с нуля. Мы просто обновились на новую модную версию, чтоб не перестать ненароком быть совместимыми с новыми модными скриптами.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44

72. Сообщение от Аноним (72), 03-Фев-23, 23:08	+2 +/–
Дорога "Всё для ленивых" ведет в ад.
Ответить | Правка | Наверх | Cообщить модератору

73. Сообщение от Kuromi (ok), 03-Фев-23, 23:11	+2 +/–
Мне нравится в этой историито, что ПЕРВОЙ реакции Гитхаба (читай Микрософт) на жалобы было завуалированное "А идите вы лесом, ваши проблемы нас не волнуют". Традиции-с.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #78, #84, #171

74. Сообщение от Аноним (74), 03-Фев-23, 23:15	+/–
Lrzip+zpaq всё ещё непревзойдённая связка, но только распаковывается столько же сколько сжимается. Lrzip+lzma9 как дешёвый вариант.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45

75. Сообщение от ms (??), 03-Фев-23, 23:15	+1 +/–
Нет, у наших друзей из freebsd именно для защиты от подмены. Для этого они ее просто хранят у себя, один раз посчитанную при опакечивании конкретной версии. Без всяких ненужных подписей, закрытые ключи от которых вы так любите нечаянно закомитить в репозиторий. Просто и эффективно. Было. Потому что битый архив скачать еще ладно, а вот вместо распаковки, как у вас всех принято, ненароком исполнить какой-нибудь интересный код - так себе идея. Но это все имело смысл во времена, когда архивы были архивами, для хранения навечно. А не просто сжатыми исходниками для упрощения скачивания. Если нас поломают - вам никакие контрольные суммы не помогут. Так что передайте им чтоб кончали устаревшей ерундой заниматься.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60 Ответы: #104

77. Сообщение от Аноним (77), 04-Фев-23, 00:42	+/–
Смех смехом, но на сайте росстата статистику отдают в arj...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45 Ответы: #86, #118

78. Сообщение от Аноним (77), 04-Фев-23, 00:43	+/–
Не то что в опенсорсе - сначала совещание, потом конференция, а потом мы посмотрим на ваши пул-реквесты... Может быть...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #73

79. Сообщение от edo (ok), 04-Фев-23, 00:50	+2 +/–
Я правильно понял, проблема в том, что все эти релизные tgz у github нигде не хранятся и формируются по запросу?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #80, #83

80. Сообщение от Аноним (81), 04-Фев-23, 01:04	–1 +/–
исходя из чего ты это "понял"?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #79

81. Сообщение от Аноним (81), 04-Фев-23, 01:21	+/–
шёл бы ты свои докеры в снапы деплоить
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #69

82. Сообщение от Аноним (82), 04-Фев-23, 01:36	+2 +/–
> Разработчики Git пока не пришли к какому-то решению и лишь обсуждают возможные действия. Здрастия, мы - большая злая корпорация, и нам очень важна гарантия безопасности, поэтому мы хотим везде сделать 2FA и отключить логин в гит через пароль. А контрольные суммы не нужно, потому что для маргиналов.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #164

83. Сообщение от mikhailnov (ok), 04-Фев-23, 01:37	+/–
Да, именно так, у пострадавших. В Росе (abf.io/import), например, в очень многих пакетах используются тарболлы с гитхаба, но загружаются в своё хранилище (file-store.rosalinux.ru), а пострадавшие такового не имеют.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #79 Ответы: #93

84. Сообщение от mikhailnov (ok), 04-Фев-23, 01:39	+/–
Ну а какой гений решил надеяться на постоянность контрольной суммы создаваемого на лету архива?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #73 Ответы: #109

85. Сообщение от YetAnotherOnanym (ok), 04-Фев-23, 02:14	+2 +/–
Ненене, на каждый файл - контрольную сумму. Обязательно в xml, так энтерпрайзнее. А потом уже всё затарить и зазиповать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #128

86. Сообщение от YetAnotherOnanym (ok), 04-Фев-23, 02:19	+5 +/–
Потому что работает - и не трогай.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77

90. Сообщение от Аноним (90), 04-Фев-23, 04:34	+2 +/–
Можно считать контрольную сумму для tar файла до его архивации (.gz,.zst,.xz). Тогда сумма не будет зависеть от архиватора. Но это нарушит обратную совместимость (зато избавит от зависимости от архиватора).
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #107, #126

91. Сообщение от Аноним (91), 04-Фев-23, 05:19	+/–
>а бывает архиватор, который дает одинаковые контрольные суммы при разных настройках сжатия? Чтобы были одинаковые суммы, файлы должны быть одинаковыми. Ты хочешь одинаковые результаты при разных настройках сжатия?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #117

93. Сообщение от Аноним (93), 04-Фев-23, 05:24	+1 +/–
во freebsd есть distfiles, насколько я помню
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #83

98. Сообщение от Аноним (98), 04-Фев-23, 05:43	+1 +/–
Лучше напомни количество пострадавших из-за каждой CVE.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #70

99. Сообщение от Аноним (98), 04-Фев-23, 05:46	+3 +/–
Более актуально --no-hipsters.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26

104. Сообщение от Sw00p aka Jerom (?), 04-Фев-23, 07:02	+/–
>А не просто сжатыми исходниками для упрощения скачивания. ну а кто виноват? бсдешник гит не придумывали, который на лету формирует архив от любого коммита. А как иначе понять, что я скачал необходимый срез состояния проекта, если заранее не сохраню его контрольную сумму? Тупо по циферкам в имени файла ориентироваться?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #75 Ответы: #129

105. Сообщение от Sw00p aka Jerom (?), 04-Фев-23, 07:06	+1 +/–
он предлагает верить циферкам в названии файла. пс:куда ушли времена, Новая Папка1, Новая Папка1_Copy, Новая Папка1 НЕ УДАЛЯТЬ :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57

107. Сообщение от Sw00p aka Jerom (?), 04-Фев-23, 07:53	+/–
>Можно считать все можно, ток этим дуракам надо сказать, семь раз отмерь, потом ломай
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #90

108. Сообщение от КО (?), 04-Фев-23, 08:08	+1 +/–
Напомните майкам для чего нужны контрольные суммы.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #114

109. Сообщение от Бывалый смузихлёб (?), 04-Фев-23, 08:24	–2 +/–
Ну а какой гений зачем-то додумается впилить свою версию архиватора, дающую другие контрольные суммы ? Ведь проблема началась с этого. И тем «гением» оказался микрософт
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #84 Ответы: #137

110. Сообщение от 4324234 (?), 04-Фев-23, 08:39	+2 +/–
за линуксоидов MS и Git уже пишет. сами то хоть что нибудь делаете
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14

111. Сообщение от Аноним (111), 04-Фев-23, 09:13	–1 +/–
> Проблему вызвало то, что сжатые архивы, генерируемые встроенной реализацией gzip на базе zlib, бинарно отличаются от архивов, созданных утилитой gzip Вот это и вопрос - что за код массово добавляется в исходники неизвестно кем, в результате чего контрольные суммы не совпадают. Несовпадение контрольных сумм означает только одно - подмену исходников. Всё. Другие пояснения не требуются
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #120

112. Сообщение от Аноним (111), 04-Фев-23, 09:14	–1 +/–
Последнее время часто rar наблюдаю. Напомнить, что означает жаргонное словечко "винрарный"?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36

113. Сообщение от Аноним (111), 04-Фев-23, 09:15	–1 +/–
Там нет технологий. Только сайты за много денег.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41

114. Сообщение от Аноним (111), 04-Фев-23, 09:18	+1 +/–
Когда они купили Нокию, самое худшее, что они могли сделать в области нанесения вреда СПО - прикрыть Qt. Я ошибался в их изобретательности.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #108 Ответы: #179

117. Сообщение от Атон (?), 04-Фев-23, 09:46	+/–
>>а бывает архиватор, который дает одинаковые контрольные суммы при разных настройках сжатия? > Чтобы были одинаковые суммы, файлы должны быть одинаковыми. Ты хочешь одинаковые результаты > при разных настройках сжатия? мимо. этот вопрос следует задать aploskov.dev который не только хочет, но, видимо, и получает одинаковые суммы при разных настройках сжатия. Введите код 42124
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #91

118. Сообщение от Атон (?), 04-Фев-23, 09:48	+1 +/–
> Смех смехом, но на сайте росстата статистику отдают в arj... А кто-то шутил?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77

120. Сообщение от www2 (??), 04-Фев-23, 10:26	+1 +/–
Несовпадение контрольных сумм архивов может означать банальное изменение степени сжатия. Захочет, допустим, github снизить нагрузку на ппоцессоры своих серверов и настроит их так, чтобы они не старались сильно сжимать - понизят степень сжатия. А подмену исходников нужно проверять не по контрольной сумме архива, а по контрольной сумме каждого файла, входящего в состав архива. Вы целостность исходников проверяете или увеличив степень сжатия вам можно напихать в архив другие исходники и ещё один фиктивный файл для того, чтобы контрольная сумма и размер совпали с прежними?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #111 Ответы: #124, #130

121. Сообщение от www2 (??), 04-Фев-23, 10:33	+2 +/–
Кстати да, можно же проверять контрольную сумму tar-архива, а не сжатого варианта, который модет быть хоть gz, хоть bz2, хоть lz или ещё каким угодно с разными настройками степени сжатия. Разжал - проверил контрольную сумму tar. А в tar можно добавить опцию для получения детерминированного результата, чтобы всегда, например, сортировал список сжимаемых файлов по алфавиту и не выравнивал их по каким-нибудь 512-байтным границам, не добавлял внутрь отметку о времени создания архива и т.п.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30 Ответы: #165

122. Сообщение от www2 (??), 04-Фев-23, 10:37	+1 +/–
Кстати, в unix архиввтор и компрессор - это два разных класса программ. Архиватор - это tar или cpio, для них можно детерминированный результат получить. А для компрессора это не имеет смысла, т.к. не даст возможности менять степень сжатия и улучшать алгоритмы сжатия.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

123. Сообщение от Омномним (?), 04-Фев-23, 10:46	+/–
> для подтверждения целостности осуществляют сверку загружаемых с GitHub архивов с ранее сохранёнными контрольными суммами Мда, лютые любители стрелять себе по ногам опять пострадали, что ж ты будешь делать-то.
Ответить | Правка | Наверх | Cообщить модератору

124. Сообщение от Омномним (?), 04-Фев-23, 10:48	+/–
Вот, хоть у кого-то мозги ещё на месте...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #120

125. Сообщение от Омномним (?), 04-Фев-23, 10:49	+/–
Тут маленькая проблемка: это должна быть чексумма неизменного архива. А если архив каждый раз переупаковывается, да ещё третьей стороной - получается идиотизм, а не защита от сбоев.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #149

126. Сообщение от Омномним (?), 04-Фев-23, 10:51	+2 +/–
Будет. Только уже не от gzip/xz/whatever, а от tar.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #90

127. Сообщение от YetAnotherOnanym (ok), 04-Фев-23, 11:39	+/–
> 2+2=4, а может 5 или 33. Все мало-мальски знающие люди в курсе, что 2+2=104 - 50 мне, 50 тебе и 4 в кассу.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

128. Сообщение от пох. (?), 04-Фев-23, 12:05	+2 +/–
В json жеж, xml - прошлый век! Формат сделать плавающим, описание формата положить в тот же json. У нас, модного поколения зуммерков, так нынче принято, а ты, хипстота бородатая, иди на свалку истории - сколько ты ни закрашиваешь седину, все равно ее видно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #85 Ответы: #136, #139

129. Сообщение от пох. (?), 04-Фев-23, 12:13	+/–
> ну а кто виноват? Обама, наверное? Он еще помнится в подъезде у меня нассал. bsdшники гит не придумывали и за него не то что не отвечают - уследить за всеми улучшизмами некому, в том и беда. Они втянули в существующую свою инфраструктуру, предназначенную и уместную для работы во времена sourceforge и ftp.gnu.org. А оно - вот. > А как иначе понять, что я скачал необходимый срез состояния проекта, если заранее не сохраню > его контрольную сумму? да никак. Не, ну можно веровать в святой git, и проверять идиотский id последнего комита. Утверждается что там все сесюрно и подделать его сохранив хотя бы возможность скомпилировать то от чего посчитан - невозможно. Но зачем? Если мы уже кому-то там веруем - то не проще ли плюнуть и растереть, переложив окончательно ответственность на microsoft? > Тупо по циферкам в имени файла ориентироваться? ну а почему нет? Все равно в конечном итоге ты доверяешь его содержимому. Тем более проект freebsd, у которого давным-давно бяда с ресурсами. Как будто они на самом деле проверяют содержимое, а не бессмысленные суммы... Впрочем, судя по отсутствию в списке пострадавших гентушных кр@сн0гл@зиков, у тех с ресурсами все еще хужей и они еще даже не заметили. (потому что они тоже использовали эту же горе-технологию... впрочем, у них вообще большая часть идей взята именно из bsd)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #104 Ответы: #174, #177

130. Сообщение от пох. (?), 04-Фев-23, 12:19	+/–
> Несовпадение контрольных сумм архивов может означать банальное изменение степени сжатия. > Захочет, допустим, github снизить нагрузку на ппоцессоры своих серверов во времена когда писали pkg, идиотизм "снизить нагрузку", перепаковывая архивы которые двадцать лет должны были оставаться неизменными, в головы еще не приходил. И их внезапное изменение действительно стоило считать сигналом сразу всех трех страусов. > А подмену исходников нужно проверять не по контрольной сумме архива, а по контрольной сумме > каждого файла, входящего в состав архива. для этого его надо хотя бы распаковать рисковать. Что в современном мирке куда более чревато, а раньше было еще и дорого. > вам можно напихать в архив другие исходники и ещё один фиктивный файл для того, чтобы > контрольная сумма и размер совпали с прежними? криптографические хэши (которые на самом деле используются вместо "контрольных сумм" уже двадцать лет как) как бе гарантируют, что это физически невозможно. Если ты даже этого не знаешь - можешь повесить на жопку медаль "эксперт опеннета". Носи с гордостью, заслужил. (я разумеется хотел другое слово вместо опеннет, но владелец нежная обиженка и теперь удаляет такие сообщения)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #120 Ответы: #135, #141

131. Сообщение от Аноним (-), 04-Фев-23, 12:20	+/–
> Контрольная сумма должна рассчитываться самостоятельно каждым проектом > своим способом по исходным файлам, а не сторонним архивам. Для этого придется репу гита клонить. Скачать gzip c релизом все ж быстрей. Я кстати не понимаю - а какого черта трогать уже сгенеренные файлы? Ну ок, для новых оно поменяется - и чрет бы с ними. Индусам никогда не приходила в голову идея что старые файлы можно просто оставить в покое а не генерить постоянно?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #140, #167

132. Сообщение от Аноним (-), 04-Фев-23, 12:23	+1 +/–
Что значит какой смысл? Там обычно качают конкретный тарбол и чекают его хэш, захардкожено в чей-то сборочный или деплойский скрипт. Чтобы проверить что это и правда оно а не левый троян от васяна. И как видим - это отлично работает, "васян" удумавший тихой сапой менять что-то там в сорцах был запален.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35 Ответы: #163

133. Сообщение от www2 (??), 04-Фев-23, 12:24	+1 +/–
На github можно любой коммит в виде архива скачать. Ты представляешь, сколько места всё это богатство будет занимать, если его на диске хранить? Подозреваю, что они действительно генерируют каждыц архив по запросу и хранят потом его некоторое время в кэше, а удаляют из кэша потом только то, что не было востребовано в течение некотрого времени.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #148

134. Сообщение от Аноним (-), 04-Фев-23, 12:28	+/–
> для этого контрольную сумму подписывают, Захардкодить sha256 тарбола какой в сборочный скрипт достигает ту же цель но быстрее, эффективнее и меньше утилит надо. Ах да, чтобы майк вообще смог подписать что-то - ему приватный ключ надо давать. И тогда они смогут грузить левак. Вот уж фиг им. А с хэшом все просто: если я знаю что хочу тарбол с хэшом 1234....CDEF - я либо получаю его, либо нет, промежуточных вариантов нет. И нет никакого шанса это подменить если я знаю что мне надо именно 1234....CDEF - а не что-то еще. Тут правда вознимает вопрос где я скрипт с вколоченой константой равной 1234....CDEF для хэша взял и почему я им доверяю но это другой вопрос. Зачем майкам потребовалось ворошить уже существующие тарболы - вопрос интересный. Заодно они узнали что опенсорсеры оказывается еще и проверяют что им отгружают, экие злыдни.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60 Ответы: #176

135. Сообщение от Аноним (-), 04-Фев-23, 12:30	+/–
Вообще-то очень странная идея менять gzip'ы уже сгенереных релизов. Какой-то индусский способ "оптимизации" нагрузки. Они что, каждому юзеру тарбол релиза индивидуально чтоли генерили?!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #130 Ответы: #142

136. Сообщение от Аноним (-), 04-Фев-23, 12:31	+/–
Бывает и хуже, некоторые вообще лысеют. И там закрашивай, не закрашивай, разве что маркером что-нибудь неприличное написать останется.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #128

137. Сообщение от www2 (??), 04-Фев-23, 12:32	+1 +/–
Проблемы начались у того, кто не думал головой. Улучшение в алгоритме сжатия или простое изменение степени сжатия архива неизбежно приведёт к изменению контрольной суммы. Что теперь, оставлять неэффективную реализацию алгоритма или покупать новые процессоры или диски из-за того, что кто-то опирается на свои выдуманнные предположения, а не на очевидные гарантии?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #109

138. Сообщение от Аноним (138), 04-Фев-23, 12:35	+1 +/–
Ни хрена не понятно. Если архив для релиза/тега уже был создан, то нафига его пересоздавать в будущем? или это результат работы альтернативно одаренных розовых пони которые генерят их "on-demand"? Я всегда создаю релиз локально и затем заливаю вручную. Конечно, можно создать github actions но и тогда результат будет в виде файлов к релизу которые в будущем не трогаются даже гитхабом.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #143, #156, #160

139. Сообщение от YetAnotherOnanym (ok), 04-Фев-23, 12:40	+1 +/–
Угу. а в json - блоб с xml-документом в base64.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #128

140. Сообщение от www2 (??), 04-Фев-23, 12:45	+1 +/–
Ну есть какой-нибудь потребитель какого-то архива, сделанного из какого-то конкретного коммита. И этот потребитель приходит скачивать свой архив раз в 5 лет. И представь, что таких потребителей миллионы, а каждый архив весит сотни мегабайт. Ты предложил отличное решение проблемы, только вот кому нужны такие архивы, да ещё и с неизменными контрольными суммами, пусть хранят их у себя и для себя. И вообще, github - это коммерческая компания, она не на налоги с граждан существует. Только её клиенты, заключившие с ней коммерческий договор и платящие ей деньги, могут что-то требовать с неё. Да и то не больше, чем гарантируется договором. Остальных они имеют полное моральное право слать нахер. Нужно что-то - или заелючай договор или иди нахер и настраивай для себя свой сервис, тем более что альтернативы для самостоятельной настройки существуют во множестве: gitlab, gitea, gogs, cgit, gitweb, gitosis, gitolite. Если не ограничиваться одним git, то выбор ещё больше.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #131 Ответы: #145

141. Сообщение от www2 (??), 04-Фев-23, 12:59	+/–
Хэш, будь он хоть трижды криптографическим, это всего лишь функция настоящего содержимого. У криптографических хэшей, представьте, тоже могут быть коллизии. При наличии достаточного пространства для манёвра можно поменять содержимое так, что хэш будет совпадать. А пространство для манёвров легко заполучить, сжав изменённые файлы сильнее. Сколько байт по сравнению с исходным архивом сэкономил - столько и можешь менять, чтобы подобрать нужный тебе хэш. Гарантии от подделки может дать только побайтовое сравнение с эталоном. Но оно бессмысленно по понятным причинам. Можно ещё хэши вычислять с блоков такого размера, который заведомо не может привести к коллизии хэша. Но что-то мне подсказывает, что хэши в таком случае будут занимать больше места, чем информация, которую они зашищают. Даже цифровые подписи архивов их авторами не дают гарантий по той же причине - цифровой подписью заверяется криптографический хэш, для которого существуют коллизии и вероятность сгенерировать другой документ с таким же хэшем.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #130 Ответы: #157, #169, #196

142. Сообщение от пох. (?), 04-Фев-23, 13:17	+/–
> Они что, каждому юзеру тарбол релиза индивидуально чтоли генерили?! ну вот похоже, что да, они настолько... ну может не каждому, кэшировали наверняка какое-то время. С другой стороны, представь себе их нагрузки - там 99% - какой-нибудь шлак никому никогда не требовавшийся, включая самого автора (у него локальный клон) и каждые пол-часа новый "релиз", потому что автору это ничего не стоит. А в него забандлен какой-нибудь, к примеру, локальный клон всей QT. Ну или те же линкус-ведра с чьими-то локальными патчами поверх всей двадцатилетней истории в клоне. Их же ж мильены. И тоже что ни день то "релиз", что владельцу васян-репо, тега жалко поставить? Хотя смысл удалять однажды созданное и уже минимум раз скачанное тоже совершенно неочевиден. Ну, видимо, так руби-кодерам было проще и понятнее.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #135 Ответы: #146

143. Сообщение от Аноним (143), 04-Фев-23, 13:18	+/–
Видимо на GitHub было что-то вроде кэша с удалением давно не запрашиваемых архивов и генерацией новых через "git archive".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #138 Ответы: #147, #152

144. Сообщение от user (??), 04-Фев-23, 13:37	+/–
В своих нет всяких .git и сделаны первые шаги autocrap.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43

145. Сообщение от Аноним (-), 04-Фев-23, 13:45	+/–
> Ну есть какой-нибудь потребитель какого-то архива, сделанного из какого-то конкретного > коммита. И этот потребитель приходит скачивать свой архив раз в 5 > лет. И представь, что таких потребителей миллионы, Откуда их миллионы и что они делают? Это боты ботнета? Зобанить гадов. > а каждый архив весит сотни мегабайт. Жесткие диски нынче емкие, им похрену. Выгрузить на медленные но емкие сторажи, пусть качают неспешно. > платящие ей деньги, могут что-то требовать с неё. Да я уже понял что MS перехватив это нечто решил картинно самоубиться о стену, то 2FA, то теперь это, скоро эта штука станет как codeplex и народ о нем забудет. Broken links чинить народ задолбается конечно, что поделать. Поэтому всякие штуки типа notabug'а стали в разы популярнее.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #140 Ответы: #159

146. Сообщение от Аноним (-), 04-Фев-23, 13:49	+/–
> С другой стороны, представь себе их нагрузки - там 99% - какой-нибудь > шлак никому никогда не требовавшийся, Выгрузить на вон ту пачку 10терабайтных винчей и пусть там качают по 100 кило в секунду на всю ораву. > включая самого автора (у него локальный клон) и каждые пол-часа новый "релиз", Бизнес идея! Вам мало 2 релизов в месяц? Всего $9.99 на новом тарифном плане - и можете выкатыать целые 20. А если мало - любой каприз за ваши деньги. > не стоит. А в него забандлен какой-нибудь, к примеру, локальный клон всей QT. И чего? Биткоин с ним весит ну мегов 20-25 в гзипе. Кошмар да и только. > Ну или те же линкус-ведра с чьими-то локальными патчами поверх всей двадцатилетней > истории в клоне. Их же ж мильены. Они что, каждый комит билдят? Ядро релизится раз в несколко месяцев. > Хотя смысл удалять однажды созданное и уже минимум раз скачанное тоже совершенно > неочевиден. Ну, видимо, так руби-кодерам было проще и понятнее. Генерить gzip с сорцами как динамику это сильно конечно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #142 Ответы: #158

147. Сообщение от fuggy (ok), 04-Фев-23, 13:49	+1 +/–
То-то замечаю архив на 100Кб качается минуты 2-3.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #143

148. Сообщение от fuggy (ok), 04-Фев-23, 13:53	+/–
Они и так хранят релизы и много чего ещё. Во-вторых диски дешевле процессоров.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #133

149. Сообщение от Атон (?), 04-Фев-23, 13:57	–2 +/–
> Тут маленькая проблемка: это должна быть чексумма неизменного архива. > А если архив каждый раз переупаковывается, да ещё третьей стороной - получается > идиотизм, а не защита от сбоев. Какая "третья сторона" у тебя перепаковывает архив между HDD и CPU, и между сервером в интернете и твоим компом? Введите код 49794
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #125 Ответы: #192

152. Сообщение от Аноним (152), 04-Фев-23, 14:04	+1 +/–
Они реально считают что архивы в среднем от 100кб до скажем 5 мб реально делают погоды когда там всякие Дениски Поповы заливают очередную сборку убунты или арча по 4гб каждый месяц?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #143 Ответы: #153

153. Сообщение от Аноним (152), 04-Фев-23, 14:06	+/–
Более того я могу сам скачать архив из тега релиза tar.gz/zip и залить их обратно вручную, вот они точно никогда "не пересоздадутся" автоматически.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #152

154. Сообщение от Аноним (154), 04-Фев-23, 14:21	–1 +/–
А проверяли бы подписи и не было бы проблем.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #178, #201

156. Сообщение от Аноним (14), 04-Фев-23, 14:48	–1 +/–
> Если архив для релиза/тега уже был создан, то нафига его пересоздавать в будущем? Это же микрософт.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #138

157. Сообщение от пох. (?), 04-Фев-23, 15:04	–1 +/–
ну эксперт как он есть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #141

158. Сообщение от пох. (?), 04-Фев-23, 15:09	+/–
> Выгрузить на вон ту пачку 10терабайтных винчей и пусть там качают по 100 кило в секунду на всю ораву. херак, выпуск новой версии какого-нибудь npm, ее качает миллиард васянов, все дружно кроют х-ями гитхап и уходят на другие хостинги. > А если мало - любой каприз за ваши деньги. вонь про EEE, корпорацию зла, мыжеваспредупреждали и массовый исход хомячья. Нет, так это, увы, не работает. > Генерить gzip с сорцами как динамику это сильно конечно. Нет, само по себе - не худшая идея если предположить что 99% гитшлака неинтересно никому вообще, включая создавшего клон васяна (он мог и релизы скопипастить даже самому ему нахрен ненужные) Но они, похоже, вообще не хранят кэши сколько-нибудь долго. Атовдруг. Хз чего вдруг.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #146 Ответы: #195

159. Сообщение от user (??), 04-Фев-23, 15:10	+/–
А чем заменить pages?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #145 Ответы: #162, #185

160. Сообщение от Аноним (54), 04-Фев-23, 16:34	+/–
> или это результат работы альтернативно одаренных розовых пони Гитхаб может выдавать архив для любого коммита. Педставь, сколько нужно дискового пространства, чтобы все это хранить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #138 Ответы: #161, #193

161. Сообщение от Аноним (152), 04-Фев-23, 17:29	–1 +/–
Архивы каждого коммита не попадают на страницу Release. Не тормозим, включаем мозг. Коммитов может быть 10 тысяч, релизов может быть всего штук 5.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #160 Ответы: #166

162. Сообщение от нейм (?), 04-Фев-23, 18:00	+/–
сходу jekyll если поискать, то таких статических можно нарыть и больше
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #159 Ответы: #172

163. Сообщение от ms (??), 04-Фев-23, 18:12	–1 +/–
> И как видим - это отлично работает, "Например, нарушилась сборка около 5800 портов" - отлично работает. Напоминаем - вы "нарушились" только потому что мы рутинно обновили git (авторами которого не являемся и отслеживать все подобные улучшизмы не подписывались). Но вы продолжайте, продолжайте.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #132 Ответы: #187

164. Сообщение от ms (??), 04-Фев-23, 18:19	+/–
>> Разработчики Git пока не пришли к какому-то решению и лишь обсуждают возможные действия. > Здрастия, мы - большая злая корпорация, и нам очень важна гарантия безопасности, > поэтому мы хотим везде сделать 2FA и отключить логин в гит > через пароль. А контрольные суммы не нужно, потому что для маргиналов. Простите, вы опять все перепутали. МЫ корпорация зла! А контрольные суммы - это разработчики git, оне белые и пушистые. И уже устроили два совещания и одну конференцию по этому поводу. (но патчей разумеется нет и не ждите)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #82

165. Сообщение от YetAnotherOnanym (ok), 04-Фев-23, 19:03	+/–
> чтобы всегда, например, сортировал список сжимаемых файлов по алфавиту А потом выйдет новая версия glibc с другим порядком collation, и снова произойдёт такой же пц. Если и сортировать на основе имени, то не по самому имени, а по его хэшу - всё-таки есть надежда, что порядок 0<1<2<3<4<5<6<7<8<9<A<B<C<D<E<F в обозримом будущем никто менять не будет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #121 Ответы: #170

166. Сообщение от Аноним (54), 04-Фев-23, 19:06	+/–
> Коммитов может быть 10 тысяч, релизов может быть всего штук 5. И что? Очевидно, что у Гитхаба для этого унифицированный механизм. Ничто не мешает особо одаренным привязаться к контрольной сумме архива произвольного коммита? > Не тормозим, включаем мозг. Ты свои ценные советы лучше давай не мне, а всем тем тем, кто завязался на Гитхаб и у кого вся инфраструктура отвалилась от одного коммита.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #161 Ответы: #182

167. Сообщение от Аноним (167), 04-Фев-23, 19:17	–1 +/–
>Для этого придется репу гита клонить Так клоньте, б****. Необучаемые. Если у каких-то отсталых архивы - прибитый гвоздями формат, то ффтопку такие системы сборки пакетов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #131 Ответы: #186

169. Сообщение от Аноним (169), 04-Фев-23, 19:28	+/–
Ты вот развёл теорию, но не довёл до конца. Тгебую от вас довести до конца - взять наиболее удобный для вас архив tar с наиболее удобным для вас содержимым, и сгенерировать коллизию любой современной хеш-функции по вашему выбору, играя на изменении настроек компрессора. Когда сгенеришь - тогда и пиши снова.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #141 Ответы: #215, #225

170. Сообщение от Аноним (170), 04-Фев-23, 19:32	+/–
Зачем, если можно сортировать просто по бинарнику имени (не декодируя строку в соответствии с правилами кодировки, а просто сравнивая байтики).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #165 Ответы: #183

171. Сообщение от Аноним (171), 04-Фев-23, 19:36	+/–
Именно такой она и должна была быть. Проблемы долбоящеров не должны волновать корпорацию. Сами они такую херню учинили - а как исправлять свои ошибки - "айайай, какие плохие разрабы git и microsoft, не хотят подстраиваться под наши ошибки".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #73

172. Сообщение от user (??), 04-Фев-23, 19:59	+/–
Так это не хостинг.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #162

174. Сообщение от Sw00p aka Jerom (?), 04-Фев-23, 20:41	+/–
>А оно - вот. вот оно что у шитхаба места для архивов нет >переложив окончательно ответственность на microsoft? кек, тут я считаю майки как хотят так и вертят, проблема в тех кто их услугами пользуются. >Все равно в конечном итоге ты доверяешь его содержимому. после проверки
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #129 Ответы: #180

175. Сообщение от Sw00p aka Jerom (?), 04-Фев-23, 20:49	+/–
>Вряд ли есть ведь, по телику показывали, весь ынтернет на флешке сохранял :) пс:99191
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

176. Сообщение от Sw00p aka Jerom (?), 04-Фев-23, 22:04	+/–
> Ах да, чтобы майк вообще смог подписать что-то - ему приватный ключ надо давать. эммммм, зачем? подписывает владелец (автор, мейнтейнер и т.д.) > для хэша взял и почему я им доверяю но это другой вопрос. доверяй, но проверяй :) а хеш получать из рук в руки (шутка) > Зачем майкам потребовалось ворошить уже существующие тарболы - вопрос интересный. у них не то, чтобы места нет для хранения тарболов, но и выходит временного места нет при сжатии на лету, вот и заменили алгоритм на с большим кэфом сжатия.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #134 Ответы: #181, #194

177. Сообщение от Michael Shigorin (ok), 04-Фев-23, 22:19	+1 +/–
Не, Грета.  Что не объяснила до сих пор за неприемлемость нагрева её детства сжиманием одних и тех же архивов в промышленных масштабах -- и заодно за SSL по поводу и без оного.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #129

178. Сообщение от Michael Shigorin (ok), 04-Фев-23, 22:54	+4 +/–
Подписи _чего_?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #154

179. Сообщение от Аноним (14), 05-Фев-23, 00:27	+/–
Они пошли выше и удалили то, что использовало это кутэ и жабу, погрузив сие инструменты в пучину стагнации.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #114

180. Сообщение от пох. (?), 05-Фев-23, 01:27	+/–
>>А оно - вот. > вот оно что у шитхаба места для архивов нет Ну тебе ж объяснили - там механизм наверняка общий в том числе для вообще одноразовых архивов конкретного комита, а не только того что помечено release Конечно нет. Любой васянский прожект имеет стотыщсорок никому ненужных форков. И каждый норовит что-то порелизить или скопипастить релиз из оригинала. Так никакого мелкософта не хватит. >>переложив окончательно ответственность на microsoft? > кек, тут я считаю майки как хотят так и вертят, проблема в в данном случае именно майки сделали то что нужно - осознав масштаб проблемы, откатились на старый гит. Шва6одкиные разработчики гита - собрали совещание, и, посовещавшись, решили ничего с проблемой не делать. Но корпорация зла, конечно, ms, смотри не перепутай! >>Все равно в конечном итоге ты доверяешь его содержимому. > после проверки э... ты вот это сейчас чего за чушь сказанул-то? Вот эти все 5600 никому ненужных портов из там какого-нибудь /ports/astro - кто-то ПРОВЕРЯЛ?! "собирается", вот и вся проверка.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #174 Ответы: #199

181. Сообщение от пох. (?), 05-Фев-23, 01:29	+1 +/–
>> Ах да, чтобы майк вообще смог подписать что-то - ему приватный ключ надо давать. > эммммм, зачем? подписывает владелец (автор, мейнтейнер и т.д.) владелец уже выложил все исходники на шитхаб и уже нажал кнопочку "релиз". Как теперь он что-то подпишет не давая ключей владельцу шитхаба? > у них не то, чтобы места нет для хранения тарболов, но и > выходит временного места нет при сжатии на лету, вот и заменили > алгоритм на с большим кэфом сжатия. б-ть, эксперт, ты новость-то вообще читать пробовал а не бредить?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #176 Ответы: #197

182. Сообщение от пох. (?), 05-Фев-23, 01:34	+/–
> Ты свои ценные советы лучше давай не мне, а всем тем тем, кто завязался на Гитхаб а у них что - выбор был? > и у кого вся инфраструктура отвалилась потому что те чья инфраструктура - берут исходники там куда их соизволили выложить авторы. А те кроме шитхаба давным-давно уже ничего не умеют. Или это ты так тонко ms обоc@л, что завязали свою инфраструктуру на чужой совершенно ушлепский продукт? Ну да, ну да, могли бы свой git написать, у них есть разработчики получше неудачников принесших нам go[a]t. Но, увы, не хотят. В конце-концов это малодоходный или даже убыточный проект.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #166 Ответы: #184

183. Сообщение от YetAnotherOnanym (ok), 05-Фев-23, 01:36	+/–
Латинские A, a, B, b и $ - однобайтовые, их декодировать не нужно, но порядок сортировки всё равно может поменяться: https://postgresql.verite.pro/blog/2018/08/27/glibc-upgrade....
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #170

184. Сообщение от Аноним (54), 05-Фев-23, 02:07	+/–
> потому что те чья инфраструктура - берут исходники там куда их соизволили выложить авторы. Так авторы исходники по факту не выкладывали :) А остальные почему-то решили, что сгенерированный на лету архив от Гитхаба - это аналог официального тарбола. Причем если в репе есть субмодули, то git archive их не подтягивает, т.е. архивы от Гитхаба в этом случае вообще неюзабельны.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #182 Ответы: #198

185. Сообщение от Аноним (-), 05-Фев-23, 03:00	–1 +/–
> А чем заменить pages? Двухбаксовой впской. Намного круче будет и без зависимости от п-сов которые могут все перефигачить в любой момент.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #159 Ответы: #205

186. Сообщение от Аноним (-), 05-Фев-23, 03:02	+/–
> Так клоньте, б****. Это заметно дольше. И врядли слабей грузит серваки сабжа. > Если у каких-то отсталых архивы - прибитый гвоздями формат, Таких систем на все вкусы, от опенврт, внезапно, до всяких хипстеров.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #167

187. Сообщение от Аноним (-), 05-Фев-23, 03:04	+1 +/–
> "Например, нарушилась сборка около 5800 портов" - отлично работает. Было бы сильно хуже если бы микросакс отгрузил измененное файло 5800 сборочницам без того чтобы они это еще и заметили. > Напоминаем - вы "нарушились" только потому что мы рутинно обновили git (авторами > которого не являемся и отслеживать все подобные улучшизмы не подписывались). Я не понимаю какого черта они уже релизнутые файлы трогают, прямо повтор сорсфоржных грабель, осталось еще рекламу в виндовый инсталлер врезать наверное.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #163 Ответы: #211

192. Сообщение от Омномним (?), 05-Фев-23, 11:37	+/–
Ну вот какая любителям стрелять себе в ногу переупаковала? :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #149

193. Сообщение от Омномним (?), 05-Фев-23, 11:39	+/–
Именно. Поэтому привязываться к чексумме конкретного архива, тем более, что он на лету формируется - это клиника.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #160

194. Сообщение от Аноним (-), 05-Фев-23, 11:44	+/–
> эммммм, зачем? подписывает владелец (автор, мейнтейнер и т.д.) Вообще-то конкретный хэш пишут для предсказуемости процесса сборки, а тут вон тот господин сможет черти что отгрузать. Если у меня компонент A билдился с комионентом B версии X это еще ничего не говорит что с версией X+5 он тоже нормально сбилдится, мало ли кто там какие апи поменять решил. А с точки зрения верификации origin - примерно 1 фиг, что я хэш ключа которым подписано где-то узнаю, что хэш тарбола, разницы никакой только канители больше. > доверяй, но проверяй :) а хеш получать из рук в руки (шутка) Fingerprint ключа аналогичен в этом аспекте.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #176 Ответы: #200

195. Сообщение от Аноним (-), 05-Фев-23, 11:47	+/–
> херак, выпуск новой версии какого-нибудь npm, ее качает миллиард васянов, Майки не могут нанять пару челов которые им кэш на ssd настроят? > и уходят на другие хостинги. Правильно уходят, раз у майков так все печально. > мыжеваспредупреждали Они ж уже с copilot'ом. Одним топиком больше, одним меньше, никто и не заметит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #158

196. Сообщение от Аноним (-), 05-Фев-23, 11:50	+/–
Чисто теоретически вы можете угадать мой 4096-битный ключ случайно сгенерив такой же. Практически... это даже было однажды в дебиане и убунте :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #141 Ответы: #226

197. Сообщение от Sw00p aka Jerom (?), 05-Фев-23, 12:14	+/–
> владелец уже выложил все исходники на шитхаб и уже нажал кнопочку "релиз". > Как теперь он что-то подпишет не давая ключей владельцу шитхаба? а причем тут вообще шитхаб? подписывает владелец и выкладывает владелец > б-ть, эксперт, ты новость-то вообще читать пробовал а не бредить? такс, зачем генерить архив на лету?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #181

198. Сообщение от пох. (?), 05-Фев-23, 12:21	+1 +/–
Ну авторы вообще-то кнопку нажаль, подтвердив что да, это именно оно. Релиз с артефактами сам из любого тега не образуется, этот факт отдельно гитхапу обозначать надо. > А остальные почему-то решили, что сгенерированный на лету архив от Гитхаба - это аналог > официального тарбола. других, еще более официальных, у меня для вас - нет. Собственно, если оно помечено как релиз - чем это неофициальный тарбол? А что оказывается он каждый день новый - ну так про это нигде даже самым мелким шрифтиком не было. (У фри есть некоторые порты не на релизах, которых либо вообще нет, "жрите свежайшее вот прям из под mcedit", либо они неработоспособны и приходится брать промежуточную версию, но их ни разу не пятьтыщ, и они-то как раз не сломались, там не архив берется.)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #184

199. Сообщение от Sw00p aka Jerom (?), 05-Фев-23, 12:23	+/–
> Конечно нет. Любой васянский прожект имеет стотыщсорок никому ненужных форков. И каждый > норовит что-то порелизить или скопипастить релиз из оригинала. > Так никакого мелкософта не хватит. и о чем это говорит? шитхаб не место для хранения продуктовых сборок проектов, точка! > в данном случае именно майки сделали то что нужно - осознав масштаб > проблемы, откатились на старый гит. на свой страх и риск говорят они, и проблема для тех кто юзает шитхаб в продуктовых целях. > Но корпорация зла, конечно, ms, смотри не перепутай! кек, с коих пор? никто и звать их никак :) > э... ты вот это сейчас чего за чушь сказанул-то? в смысле? > Вот эти все 5600 никому ненужных портов из там какого-нибудь /ports/astro - > кто-то ПРОВЕРЯЛ?! "собирается", вот и вся проверка. ну а чеж сломалась сборка?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #180 Ответы: #214

200. Сообщение от Sw00p aka Jerom (?), 05-Фев-23, 12:37	+/–
> Вообще-то конкретный хэш пишут для предсказуемости процесса сборки речь идет о хешах тарболов > что я хэш ключа которым подписано где-то узнаю, что хэш тарбола, разницы никакой > только канители больше. у вас лежит тарбол, контрольная сумма и подпись, рядом ключа для верификации лежать не должно, это совсем другая тема, как безопасно его получить, конечно когда он там же будет лежать - толку не будет. > Fingerprint ключа аналогичен в этом аспекте. фингерпринты выкладывать нет смысла, другой механизм должен быть, и это не тема сего обсуждения. мы же не будем обсуждать как хранится приватный ключ у мейнтейнера, ясно же - секрет должен храниться - в секрете :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #194

201. Сообщение от Аноним (201), 05-Фев-23, 12:39	+/–
Подписи тут не помогут особо. Ведь чтобы подписать новый архив нужен ключ. А если этот ключ дать гитхабу то он может подписывать что угодно и когда угодно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #154 Ответы: #202

202. Сообщение от пох. (?), 05-Фев-23, 15:17	+3 +/–
Как будто если его не давать шитхабу это что-то изменит? В лучшую, я имею в виду, сторону. Напомнить вам про историю горе-девелоперов пехепе, которым напихали х-ев в пана...прямо в репо - от имени и по поручению, и подписанных вполне себе? (Как раз шитхабу-то я больше верю, там какая-никакая security team и пока они _сами_ ни одной учетки и ни одного ключа не прогадили. В отличие от их дорогих и обожаемых клиентов - альтернативно-одаренных разработчиков, делающих это регулярно и с явным удовольствием.) Контрольный хэш архива _гарантирует_ что это _тот_самый_ архив, ВНЕ зависимости от того, прогадил ли его гени[т]альный разработчик все свои подписи, пароли и явки. Но местным адептам карго-культа это (судя вон по переписке выше) не то что непонятно, а и понимать они ничего не хотят, омм, мани-мани-мани-мани, подпис-подпис-подпис! К сожалению, только после перехода они узнают что испортили себе этой мантрой карму на пару эонов раскаленного кола в ср-ку.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #201 Ответы: #204

204. Сообщение от Аноньимъ (ok), 05-Фев-23, 20:00	+/–
Аминь!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #202

205. Сообщение от Аноним (205), 05-Фев-23, 20:00	+/–
Бесплатный pages, который пользователю не нужно обслуживать и в который можно публиковать пушем в репу сразу же, без промежуточных действий заменить двухбаксовой впской на хостинге, который мало того, что точно так же может всё перефигачить в любой момент, так ещё и не будет за тебя админить ничего. Ох уж эта нердота. Хлебом не корми, дай в консольке попечатать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #185

206. Сообщение от Аноним (205), 05-Фев-23, 20:12	+/–
Не для каждого, а по факту релиза. Архив клали в кэш, и если обращений к кэшу не было какое-то время — удаляли, место на дисках не бесконечное и хранить релиз my-hello-world-0.0.1-beta.tar.gz двести лет никто не подписывался. После апдейта кэши, видимо, инвалидировали, что и привело к каскаду ошибок у потребителей. Напоминает как Линус в своё время сломал сборочные скрипты разным локалхостным васянам, выпустив ядро с неожиданной версией. И ехидно так заметил, что, мол, у плохих программистов поломается, да так им и надо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27

207. Сообщение от Аноним (207), 05-Фев-23, 20:22	+/–
Системы контроля версий это пятое колесо у телеги
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23

208. Сообщение от Аноним (207), 05-Фев-23, 20:46	–1 +/–
GitHub виноват что стал менять настройки сжатия для уже сгенерированных архивов-релизов. Даже если файлы не хранятся вообще, а генерируются на каждый запрос на скачивание, можно было менять алгоритм сжатия только для новых релизов, а старым оставить старый алгоритм и старые настройки сжатия
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #209, #210

209. Сообщение от Аноним (207), 05-Фев-23, 20:57	+/–
В прочем в нашей днищешаражке та же самая проблема, для старых актов сверки и счетов меняются адреса, фамилии и т.д. Но у нас руки из ж..мы и мы даже документацию языков программирования, библиотек и фреймворков не читаем. Потому что если оно скомпилировалось и запустились то можно не тратить время на её чтение.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #208

210. Сообщение от пох. (?), 06-Фев-23, 09:48	+/–
> GitHub виноват что стал менять настройки сжатия для уже сгенерированных архивов-релизов. опять обама виноват? Или неумение опеннетовских экспертов читать написанное? github использует git. Никаких настроек в том - нет. > Даже если файлы не хранятся вообще, а генерируются на каждый запрос > на скачивание, можно было менять алгоритм сжатия только для новых релизов, расскажи это разработчикам гита.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #208 Ответы: #216

211. Сообщение от Stellarwind (?), 06-Фев-23, 10:51	+/–
Очевидно же, что они хранят релизнутые файлы, если они залиты вручную. А если вы запрашиваете архив конкретного тега\коммита, он формируется автоматом и может подчищаться для экономии. С ними и возникла проблема.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #187

212. Сообщение от Серб (ok), 06-Фев-23, 13:54	+/–
Если не знаешь как правильно сделать - вынеси в настройки. Э... это сложно?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #219

213. Сообщение от Серб (ok), 06-Фев-23, 13:57	+/–
И, таки да. Если вынести в настройки тип архивации сложно, дай два типа архива параллельно. Один вариант - простая архивация. Второй вариант - архивация с воспроизводимой контрольной суммой.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #221

214. Сообщение от пох. (?), 06-Фев-23, 17:30	+/–
> и о чем это говорит? шитхаб не место для хранения продуктовых сборок > проектов, точка! Так других-то нет. > на свой страх и риск говорят они, и проблема для тех кто ну не переписывать же им самим git? Тем более вони опять будет... >> Вот эти все 5600 никому ненужных портов из там какого-нибудь /ports/astro - >> кто-то ПРОВЕРЯЛ?! "собирается", вот и вся проверка. > ну а чеж сломалась сборка? так для make checksum ничего _проверять_ не надо. Если б вот make package не сработал - такой не удалось бы закомитить. А если он сработал - альтернативно-одаренный гендерно-небинарный бсд-порт-комитер переходит к следующему.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #199

215. Сообщение от пох. (?), 06-Фев-23, 17:37	+/–
> довести до конца - взять наиболее удобный для вас архив tar > с наиболее удобным для вас содержимым, и сгенерировать коллизию любой современной > хеш-функции по вашему выбору, играя на изменении настроек компрессора. Когда сгенеришь > - тогда и пиши снова. ну, если бы такое было даже в теории невозможно - мы бы изобрели работающий архиватор del - ну или близкий к нему. В теории это вполне возможно, мир нельзя упаковать в набор хэшей одинаковой короткой длины. _криптографические_ хэши гарантируют нам что во-первых, подобрать коллизию будет занятием для ооооочень терпеливых, во-вторых кодовое расстояние будет очень большим (т.е. это вообще ни разу не будет похоже на оригинал)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #169

216. Сообщение от Аноним (207), 07-Фев-23, 09:34	+/–
Чё прямо так и используют git.exe без модификации? Ужас то какой... 😱 И их прямо заставляют обновлять этот git.exe при выходе новой версии... И скопировать предыдущую версию git.exe и делать архивы старых релизов, старым гитом они тоже не могут? Раз не могут, тогда ради одного хостинга придется приделывать костыли вида архивации разными методами в зависимости от даты комита к самому гиту
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #210 Ответы: #217, #218

217. Сообщение от Аноним (207), 07-Фев-23, 09:41	–1 +/–
GitHub скорее всего даже git.exe --stable запустить тоже не сможет, по этому только разные методы сжатия по дате коммита прямо в git, только хардкор А чтобы гарантировать что на серверах GitHub (хостинга) время и временные зоны не перепуганы, в git (систему контроля версий) нужно добавить ещё и синхронизацию времени по NTP
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #216

218. Сообщение от ms (??), 07-Фев-23, 12:01	+/–
Ты-то конечно не такой, ты его весь сам переписал? А, нет... опять админ локалхоста, не умеющий кодить, откуда тут другие... Да, заставляют: * git: gitattributes parsing integer overflow (CVE-2022-23521) * git: Heap overflow in `git archive`, `git log --format` leading to RCE (CVE-2022-41903) Админы локалхоста конечно не в курсе, ты ведь обновления всегда выключаешь, потому что ЦРУ за тобой следит. (отдельно вот прекрасно - что именно в git archive - RCE)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #216

219. Сообщение от ms (??), 07-Фев-23, 12:03	+/–
Ну ты новость читать не пробовал? "Разработчики Git пока лишь обсуждают возможные действия." Они еще пару комиссий назначат и двести митингов проведут.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #212 Ответы: #220

220. Сообщение от Серб (ok), 07-Фев-23, 12:08	+/–
> Ну ты новость читать не пробовал? > "Разработчики Git пока лишь обсуждают возможные действия." > Они еще пару комиссий назначат и двести митингов проведут. Так то я вовсе не git имел ввиду. И, признаться, не могу понять, каким он тут боком причастен. А вот разработчики гитхаба - да. Их логику понять сложно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #219

221. Сообщение от Аноним (54), 07-Фев-23, 16:45	+/–
В Гите можно менять тип архивации. Напимер, через git config tar.tar.gz.command ... задать свою комманду.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #213 Ответы: #224

222. Сообщение от Аноним (222), 07-Фев-23, 17:38	+/–
Я так понимаю, что иначе пришлось бы хранить вечно архивы для каждого коммита, да даже если для релизов это весьма и весьма дофига
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31

224. Сообщение от Серб (ok), 08-Фев-23, 09:55	+/–
> В Гите можно менять тип архивации. Напимер, через > git config tar.tar.gz.command ... > задать свою комманду. Речь о гитхабе.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #221

225. Сообщение от www2 (??), 08-Фев-23, 17:02	+/–
> Ты вот развёл теорию, но не довёл до конца. Тгебую от вас > довести до конца - взять наиболее удобный для вас архив tar > с наиболее удобным для вас содержимым, и сгенерировать коллизию любой современной > хеш-функции по вашему выбору, играя на изменении настроек компрессора. Когда сгенеришь > - тогда и пиши снова. Держи, эксперт: https://www.opennet.ru/opennews/art.shtml?num=46102
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #169

226. Сообщение от www2 (??), 08-Фев-23, 17:04	+/–
> Чисто теоретически вы можете угадать мой 4096-битный ключ случайно сгенерив такой же. > Практически... это даже было однажды в дебиане и убунте :) Зачем угадывать, если знаешь? Хэш-суммы архивов известны. Надо только изменить содержимое и подобрать "соль", вместе с которой получится такой же хэш. Просвешайтесь: https://www.opennet.ru/opennews/art.shtml?num=46102
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #196

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема