GitHub изменил метод формирования автоматически генерируемых архивов ".tar.gz" и ".tgz" на страницах с релизами,...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=58595
Контрольная сумма должна рассчитываться самостоятельно каждым проектом своим способом по исходным файлам, а не сторонним архивам.
ну тогда пусть и хранят архивы у себя
Да, пусть кто хочет делает gostsum или sha256.
> что привело к изменению их контрольных сумм и массовым сбоямкак раз в духе микрософта.
за линуксоидов MS и Git уже пишет. сами то хоть что нибудь делаете
Я даже не знаю как они так формируют архивы, что у них контрольные суммы не совпадают. Формируют архив, делают сумму, а потом говорят гитхабу "заархивируй мне вот это но уже сам для себя" что ли? Обычно сначала пакуют, потом прогоняют чексумму и в конце заливают всё готовое. Чем паковать вообще фиолетово - хоть таргз, хоть 7з, хоть винраром.
Еще круче: говорят шитхабу - сформируй-ка нам архив _своего_ репо с ~нашим~ (мвахахаха) кодом.И сами мизинчиком так в экранчик тык-потык.
А у нас оно вот такое - архив сами даже не знаем зачем (до нас писали) создается каждые пять минут заново, а ВДРУГ в репо сами собой изменились комиты пятилетней давности - обязательно надо переупаковать, нельзя ж просто так ничего не трогать, особенно старые срезы исходников.
Я так понимаю, что иначе пришлось бы хранить вечно архивы для каждого коммита, да даже если для релизов это весьма и весьма дофига
> Контрольная сумма должна рассчитываться самостоятельно каждым проектом
> своим способом по исходным файлам, а не сторонним архивам.Для этого придется репу гита клонить. Скачать gzip c релизом все ж быстрей. Я кстати не понимаю - а какого черта трогать уже сгенеренные файлы? Ну ок, для новых оно поменяется - и чрет бы с ними. Индусам никогда не приходила в голову идея что старые файлы можно просто оставить в покое а не генерить постоянно?
Ну есть какой-нибудь потребитель какого-то архива, сделанного из какого-то конкретного коммита. И этот потребитель приходит скачивать свой архив раз в 5 лет. И представь, что таких потребителей миллионы, а каждый архив весит сотни мегабайт. Ты предложил отличное решение проблемы, только вот кому нужны такие архивы, да ещё и с неизменными контрольными суммами, пусть хранят их у себя и для себя.И вообще, github - это коммерческая компания, она не на налоги с граждан существует. Только её клиенты, заключившие с ней коммерческий договор и платящие ей деньги, могут что-то требовать с неё. Да и то не больше, чем гарантируется договором. Остальных они имеют полное моральное право слать нахер. Нужно что-то - или заелючай договор или иди нахер и настраивай для себя свой сервис, тем более что альтернативы для самостоятельной настройки существуют во множестве: gitlab, gitea, gogs, cgit, gitweb, gitosis, gitolite. Если не ограничиваться одним git, то выбор ещё больше.
> Ну есть какой-нибудь потребитель какого-то архива, сделанного из какого-то конкретного
> коммита. И этот потребитель приходит скачивать свой архив раз в 5
> лет. И представь, что таких потребителей миллионы,Откуда их миллионы и что они делают? Это боты ботнета? Зобанить гадов.
> а каждый архив весит сотни мегабайт.
Жесткие диски нынче емкие, им похрену. Выгрузить на медленные но емкие сторажи, пусть качают неспешно.
> платящие ей деньги, могут что-то требовать с неё.
Да я уже понял что MS перехватив это нечто решил картинно самоубиться о стену, то 2FA, то теперь это, скоро эта штука станет как codeplex и народ о нем забудет. Broken links чинить народ задолбается конечно, что поделать. Поэтому всякие штуки типа notabug'а стали в разы популярнее.
А чем заменить pages?
сходу jekyll
если поискать, то таких статических можно нарыть и больше
Так это не хостинг.
> А чем заменить pages?Двухбаксовой впской. Намного круче будет и без зависимости от п-сов которые могут все перефигачить в любой момент.
Бесплатный pages, который пользователю не нужно обслуживать и в который можно публиковать пушем в репу сразу же, без промежуточных действий заменить двухбаксовой впской на хостинге, который мало того, что точно так же может всё перефигачить в любой момент, так ещё и не будет за тебя админить ничего. Ох уж эта нердота. Хлебом не корми, дай в консольке попечатать.
>Для этого придется репу гита клонитьТак клоньте, б****. Необучаемые. Если у каких-то отсталых архивы - прибитый гвоздями формат, то ффтопку такие системы сборки пакетов.
> Так клоньте, б****.Это заметно дольше. И врядли слабей грузит серваки сабжа.
> Если у каких-то отсталых архивы - прибитый гвоздями формат,
Таких систем на все вкусы, от опенврт, внезапно, до всяких хипстеров.
Хвост виляет собакой.
ну виляет и виляет, что бубнить то
> ну виляет и виляет, что бубнить тоГлавное не бухтеть, всё схвачено у кого нужно, вопрос под контролем, всё решат нужно только подождать.
Собака сама виновата. Какой вообще смысл в контрольных суммах исходников которые каждый день новые - сами не знаем. Это у них пережитки времен sourceforge, где архивы и исходники вообще никак не пересекались, что разработчик (или стыривший его пароли) залил, то и отдавалось.Вместо того чтоб эту глупость просто убрать, они вот, понаделали новых костылей а теперь обижаются, когда самый нижний вдруг выпал.
Либо пусть доверяют целиком нашей инфраструктуре, либо не выпендриваются и делают каждый раз clone.
Что значит какой смысл? Там обычно качают конкретный тарбол и чекают его хэш, захардкожено в чей-то сборочный или деплойский скрипт. Чтобы проверить что это и правда оно а не левый троян от васяна.И как видим - это отлично работает, "васян" удумавший тихой сапой менять что-то там в сорцах был запален.
> И как видим - это отлично работает,"Например, нарушилась сборка около 5800 портов"
- отлично работает.Напоминаем - вы "нарушились" только потому что мы рутинно обновили git (авторами которого не являемся и отслеживать все подобные улучшизмы не подписывались).
Но вы продолжайте, продолжайте.
> "Например, нарушилась сборка около 5800 портов" - отлично работает.Было бы сильно хуже если бы микросакс отгрузил измененное файло 5800 сборочницам без того чтобы они это еще и заметили.
> Напоминаем - вы "нарушились" только потому что мы рутинно обновили git (авторами
> которого не являемся и отслеживать все подобные улучшизмы не подписывались).Я не понимаю какого черта они уже релизнутые файлы трогают, прямо повтор сорсфоржных грабель, осталось еще рекламу в виндовый инсталлер врезать наверное.
Очевидно же, что они хранят релизнутые файлы, если они залиты вручную.А если вы запрашиваете архив конкретного тега\коммита, он формируется автоматом и может подчищаться для экономии. С ними и возникла проблема.
Пихать в архив файл с контрольными суммами содержимого? Ну, действительно, проверять контрольную сумму архива - это как-то тупо, важна-то целостность содержимого.
Здесь контрольная сумма не для целостности, а для защиты от подмены.
>для защиты от подменыдля этого контрольную сумму подписывают, а сама сумма - контроль целостности
Нет, у наших друзей из freebsd именно для защиты от подмены. Для этого они ее просто хранят у себя, один раз посчитанную при опакечивании конкретной версии. Без всяких ненужных подписей, закрытые ключи от которых вы так любите нечаянно закомитить в репозиторий. Просто и эффективно. Было.Потому что битый архив скачать еще ладно, а вот вместо распаковки, как у вас всех принято, ненароком исполнить какой-нибудь интересный код - так себе идея.
Но это все имело смысл во времена, когда архивы были архивами, для хранения навечно. А не просто сжатыми исходниками для упрощения скачивания. Если нас поломают - вам никакие контрольные суммы не помогут. Так что передайте им чтоб кончали устаревшей ерундой заниматься.
>А не просто сжатыми исходниками для упрощения скачивания.ну а кто виноват? бсдешник гит не придумывали, который на лету формирует архив от любого коммита. А как иначе понять, что я скачал необходимый срез состояния проекта, если заранее не сохраню его контрольную сумму? Тупо по циферкам в имени файла ориентироваться?
> ну а кто виноват?Обама, наверное? Он еще помнится в подъезде у меня нассал.
bsdшники гит не придумывали и за него не то что не отвечают - уследить за всеми улучшизмами некому, в том и беда. Они втянули в существующую свою инфраструктуру, предназначенную и уместную для работы во времена sourceforge и ftp.gnu.org. А оно - вот.
> А как иначе понять, что я скачал необходимый срез состояния проекта, если заранее не сохраню
> его контрольную сумму?да никак. Не, ну можно веровать в святой git, и проверять идиотский id последнего комита. Утверждается что там все сесюрно и подделать его сохранив хотя бы возможность скомпилировать то от чего посчитан - невозможно. Но зачем?
Если мы уже кому-то там веруем - то не проще ли плюнуть и растереть, переложив окончательно ответственность на microsoft?
> Тупо по циферкам в имени файла ориентироваться?
ну а почему нет? Все равно в конечном итоге ты доверяешь его содержимому. Тем более проект freebsd, у которого давным-давно бяда с ресурсами. Как будто они на самом деле проверяют содержимое, а не бессмысленные суммы...
Впрочем, судя по отсутствию в списке пострадавших гентушных кр@сн0гл@зиков, у тех с ресурсами все еще хужей и они еще даже не заметили. (потому что они тоже использовали эту же горе-технологию... впрочем, у них вообще большая часть идей взята именно из bsd)
>А оно - вот.вот оно что у шитхаба места для архивов нет
>переложив окончательно ответственность на microsoft?
кек, тут я считаю майки как хотят так и вертят, проблема в тех кто их услугами пользуются.
>Все равно в конечном итоге ты доверяешь его содержимому.
после проверки
>>А оно - вот.
> вот оно что у шитхаба места для архивов нетНу тебе ж объяснили - там механизм наверняка общий в том числе для вообще одноразовых архивов конкретного комита, а не только того что помечено release
Конечно нет. Любой васянский прожект имеет стотыщсорок никому ненужных форков. И каждый норовит что-то порелизить или скопипастить релиз из оригинала.
Так никакого мелкософта не хватит.>>переложив окончательно ответственность на microsoft?
> кек, тут я считаю майки как хотят так и вертят, проблема вв данном случае именно майки сделали то что нужно - осознав масштаб проблемы, откатились на старый гит. Шва6одкиные разработчики гита - собрали совещание, и, посовещавшись, решили ничего с проблемой не делать.
Но корпорация зла, конечно, ms, смотри не перепутай!
>>Все равно в конечном итоге ты доверяешь его содержимому.
> после проверкиэ... ты вот это сейчас чего за чушь сказанул-то?
Вот эти все 5600 никому ненужных портов из там какого-нибудь /ports/astro - кто-то ПРОВЕРЯЛ?! "собирается", вот и вся проверка.
> Конечно нет. Любой васянский прожект имеет стотыщсорок никому ненужных форков. И каждый
> норовит что-то порелизить или скопипастить релиз из оригинала.
> Так никакого мелкософта не хватит.и о чем это говорит? шитхаб не место для хранения продуктовых сборок проектов, точка!
> в данном случае именно майки сделали то что нужно - осознав масштаб
> проблемы, откатились на старый гит.на свой страх и риск говорят они, и проблема для тех кто юзает шитхаб в продуктовых целях.
> Но корпорация зла, конечно, ms, смотри не перепутай!
кек, с коих пор? никто и звать их никак :)
> э... ты вот это сейчас чего за чушь сказанул-то?
в смысле?
> Вот эти все 5600 никому ненужных портов из там какого-нибудь /ports/astro -
> кто-то ПРОВЕРЯЛ?! "собирается", вот и вся проверка.ну а чеж сломалась сборка?
> и о чем это говорит? шитхаб не место для хранения продуктовых сборок
> проектов, точка!Так других-то нет.
> на свой страх и риск говорят они, и проблема для тех кто
ну не переписывать же им самим git? Тем более вони опять будет...
>> Вот эти все 5600 никому ненужных портов из там какого-нибудь /ports/astro -
>> кто-то ПРОВЕРЯЛ?! "собирается", вот и вся проверка.
> ну а чеж сломалась сборка?так для make checksum ничего _проверять_ не надо. Если б вот make package не сработал - такой не удалось бы закомитить. А если он сработал - альтернативно-одаренный гендерно-небинарный бсд-порт-комитер переходит к следующему.
Не, Грета. Что не объяснила до сих пор за неприемлемость нагрева её детства сжиманием одних и тех же архивов в промышленных масштабах -- и заодно за SSL по поводу и без оного.
> для этого контрольную сумму подписывают,Захардкодить sha256 тарбола какой в сборочный скрипт достигает ту же цель но быстрее, эффективнее и меньше утилит надо. Ах да, чтобы майк вообще смог подписать что-то - ему приватный ключ надо давать. И тогда они смогут грузить левак. Вот уж фиг им.
А с хэшом все просто: если я знаю что хочу тарбол с хэшом 1234....CDEF - я либо получаю его, либо нет, промежуточных вариантов нет. И нет никакого шанса это подменить если я знаю что мне надо именно 1234....CDEF - а не что-то еще. Тут правда вознимает вопрос где я скрипт с вколоченой константой равной 1234....CDEF для хэша взял и почему я им доверяю но это другой вопрос.
Зачем майкам потребовалось ворошить уже существующие тарболы - вопрос интересный. Заодно они узнали что опенсорсеры оказывается еще и проверяют что им отгружают, экие злыдни.
> Ах да, чтобы майк вообще смог подписать что-то - ему приватный ключ надо давать.эммммм, зачем? подписывает владелец (автор, мейнтейнер и т.д.)
> для хэша взял и почему я им доверяю но это другой вопрос.
доверяй, но проверяй :) а хеш получать из рук в руки (шутка)
> Зачем майкам потребовалось ворошить уже существующие тарболы - вопрос интересный.
у них не то, чтобы места нет для хранения тарболов, но и выходит временного места нет при сжатии на лету, вот и заменили алгоритм на с большим кэфом сжатия.
>> Ах да, чтобы майк вообще смог подписать что-то - ему приватный ключ надо давать.
> эммммм, зачем? подписывает владелец (автор, мейнтейнер и т.д.)владелец уже выложил все исходники на шитхаб и уже нажал кнопочку "релиз". Как теперь он что-то подпишет не давая ключей владельцу шитхаба?
> у них не то, чтобы места нет для хранения тарболов, но и
> выходит временного места нет при сжатии на лету, вот и заменили
> алгоритм на с большим кэфом сжатия.б-ть, эксперт, ты новость-то вообще читать пробовал а не бредить?
> владелец уже выложил все исходники на шитхаб и уже нажал кнопочку "релиз".
> Как теперь он что-то подпишет не давая ключей владельцу шитхаба?а причем тут вообще шитхаб? подписывает владелец и выкладывает владелец
> б-ть, эксперт, ты новость-то вообще читать пробовал а не бредить?
такс, зачем генерить архив на лету?
> эммммм, зачем? подписывает владелец (автор, мейнтейнер и т.д.)Вообще-то конкретный хэш пишут для предсказуемости процесса сборки, а тут вон тот господин сможет черти что отгрузать. Если у меня компонент A билдился с комионентом B версии X это еще ничего не говорит что с версией X+5 он тоже нормально сбилдится, мало ли кто там какие апи поменять решил.
А с точки зрения верификации origin - примерно 1 фиг, что я хэш ключа которым подписано где-то узнаю, что хэш тарбола, разницы никакой только канители больше.
> доверяй, но проверяй :) а хеш получать из рук в руки (шутка)
Fingerprint ключа аналогичен в этом аспекте.
> Вообще-то конкретный хэш пишут для предсказуемости процесса сборкиречь идет о хешах тарболов
> что я хэш ключа которым подписано где-то узнаю, что хэш тарбола, разницы никакой
> только канители больше.у вас лежит тарбол, контрольная сумма и подпись, рядом ключа для верификации лежать не должно, это совсем другая тема, как безопасно его получить, конечно когда он там же будет лежать - толку не будет.
> Fingerprint ключа аналогичен в этом аспекте.
фингерпринты выкладывать нет смысла, другой механизм должен быть, и это не тема сего обсуждения.
мы же не будем обсуждать как хранится приватный ключ у мейнтейнера, ясно же - секрет должен храниться - в секрете :)
> Проблему вызвало то, что сжатые архивы, генерируемые встроенной реализацией gzip на базе zlib, бинарно отличаются от архивов, созданных утилитой gzipВот это и вопрос - что за код массово добавляется в исходники неизвестно кем, в результате чего контрольные суммы не совпадают. Несовпадение контрольных сумм означает только одно - подмену исходников. Всё. Другие пояснения не требуются
Несовпадение контрольных сумм архивов может означать банальное изменение степени сжатия. Захочет, допустим, github снизить нагрузку на ппоцессоры своих серверов и настроит их так, чтобы они не старались сильно сжимать - понизят степень сжатия.А подмену исходников нужно проверять не по контрольной сумме архива, а по контрольной сумме каждого файла, входящего в состав архива. Вы целостность исходников проверяете или увеличив степень сжатия вам можно напихать в архив другие исходники и ещё один фиктивный файл для того, чтобы контрольная сумма и размер совпали с прежними?
Вот, хоть у кого-то мозги ещё на месте...
> Несовпадение контрольных сумм архивов может означать банальное изменение степени сжатия.
> Захочет, допустим, github снизить нагрузку на ппоцессоры своих серверовво времена когда писали pkg, идиотизм "снизить нагрузку", перепаковывая архивы которые двадцать лет должны были оставаться неизменными, в головы еще не приходил. И их внезапное изменение действительно стоило считать сигналом сразу всех трех страусов.
> А подмену исходников нужно проверять не по контрольной сумме архива, а по контрольной сумме
> каждого файла, входящего в состав архива.для этого его надо хотя бы распаковать рисковать. Что в современном мирке куда более чревато, а раньше было еще и дорого.
> вам можно напихать в архив другие исходники и ещё один фиктивный файл для того, чтобы
> контрольная сумма и размер совпали с прежними?криптографические хэши (которые на самом деле используются вместо "контрольных сумм" уже двадцать лет как) как бе гарантируют, что это физически невозможно.
Если ты даже этого не знаешь - можешь повесить на жопку медаль "эксперт опеннета". Носи с гордостью, заслужил.(я разумеется хотел другое слово вместо опеннет, но владелец нежная обиженка и теперь удаляет такие сообщения)
Вообще-то очень странная идея менять gzip'ы уже сгенереных релизов. Какой-то индусский способ "оптимизации" нагрузки. Они что, каждому юзеру тарбол релиза индивидуально чтоли генерили?!
> Они что, каждому юзеру тарбол релиза индивидуально чтоли генерили?!ну вот похоже, что да, они настолько... ну может не каждому, кэшировали наверняка какое-то время.
С другой стороны, представь себе их нагрузки - там 99% - какой-нибудь шлак никому никогда не требовавшийся, включая самого автора (у него локальный клон) и каждые пол-часа новый "релиз", потому что автору это ничего не стоит. А в него забандлен какой-нибудь, к примеру, локальный клон всей QT.
Ну или те же линкус-ведра с чьими-то локальными патчами поверх всей двадцатилетней истории в клоне. Их же ж мильены. И тоже что ни день то "релиз", что владельцу васян-репо, тега жалко поставить?
Хотя смысл удалять однажды созданное и уже минимум раз скачанное тоже совершенно неочевиден. Ну, видимо, так руби-кодерам было проще и понятнее.
> С другой стороны, представь себе их нагрузки - там 99% - какой-нибудь
> шлак никому никогда не требовавшийся,Выгрузить на вон ту пачку 10терабайтных винчей и пусть там качают по 100 кило в секунду на всю ораву.
> включая самого автора (у него локальный клон) и каждые пол-часа новый "релиз",
Бизнес идея! Вам мало 2 релизов в месяц? Всего $9.99 на новом тарифном плане - и можете выкатыать целые 20. А если мало - любой каприз за ваши деньги.
> не стоит. А в него забандлен какой-нибудь, к примеру, локальный клон всей QT.
И чего? Биткоин с ним весит ну мегов 20-25 в гзипе. Кошмар да и только.
> Ну или те же линкус-ведра с чьими-то локальными патчами поверх всей двадцатилетней
> истории в клоне. Их же ж мильены.Они что, каждый комит билдят? Ядро релизится раз в несколко месяцев.
> Хотя смысл удалять однажды созданное и уже минимум раз скачанное тоже совершенно
> неочевиден. Ну, видимо, так руби-кодерам было проще и понятнее.Генерить gzip с сорцами как динамику это сильно конечно.
> Выгрузить на вон ту пачку 10терабайтных винчей и пусть там качают по 100 кило в секунду на всю ораву.херак, выпуск новой версии какого-нибудь npm, ее качает миллиард васянов, все дружно кроют х-ями гитхап и уходят на другие хостинги.
> А если мало - любой каприз за ваши деньги.
вонь про EEE, корпорацию зла, мыжеваспредупреждали и массовый исход хомячья.
Нет, так это, увы, не работает.
> Генерить gzip с сорцами как динамику это сильно конечно.
Нет, само по себе - не худшая идея если предположить что 99% гитшлака неинтересно никому вообще, включая создавшего клон васяна (он мог и релизы скопипастить даже самому ему нахрен ненужные)
Но они, похоже, вообще не хранят кэши сколько-нибудь долго. Атовдруг. Хз чего вдруг.
> херак, выпуск новой версии какого-нибудь npm, ее качает миллиард васянов,Майки не могут нанять пару челов которые им кэш на ssd настроят?
> и уходят на другие хостинги.
Правильно уходят, раз у майков так все печально.
> мыжеваспредупреждали
Они ж уже с copilot'ом. Одним топиком больше, одним меньше, никто и не заметит.
Хэш, будь он хоть трижды криптографическим, это всего лишь функция настоящего содержимого. У криптографических хэшей, представьте, тоже могут быть коллизии. При наличии достаточного пространства для манёвра можно поменять содержимое так, что хэш будет совпадать. А пространство для манёвров легко заполучить, сжав изменённые файлы сильнее. Сколько байт по сравнению с исходным архивом сэкономил - столько и можешь менять, чтобы подобрать нужный тебе хэш.Гарантии от подделки может дать только побайтовое сравнение с эталоном. Но оно бессмысленно по понятным причинам. Можно ещё хэши вычислять с блоков такого размера, который заведомо не может привести к коллизии хэша. Но что-то мне подсказывает, что хэши в таком случае будут занимать больше места, чем информация, которую они зашищают.
Даже цифровые подписи архивов их авторами не дают гарантий по той же причине - цифровой подписью заверяется криптографический хэш, для которого существуют коллизии и вероятность сгенерировать другой документ с таким же хэшем.
ну эксперт как он есть.
Ты вот развёл теорию, но не довёл до конца. Тгебую от вас довести до конца - взять наиболее удобный для вас архив tar с наиболее удобным для вас содержимым, и сгенерировать коллизию любой современной хеш-функции по вашему выбору, играя на изменении настроек компрессора. Когда сгенеришь - тогда и пиши снова.
> довести до конца - взять наиболее удобный для вас архив tar
> с наиболее удобным для вас содержимым, и сгенерировать коллизию любой современной
> хеш-функции по вашему выбору, играя на изменении настроек компрессора. Когда сгенеришь
> - тогда и пиши снова.ну, если бы такое было даже в теории невозможно - мы бы изобрели работающий архиватор del - ну или близкий к нему.
В теории это вполне возможно, мир нельзя упаковать в набор хэшей одинаковой короткой длины. _криптографические_ хэши гарантируют нам что во-первых, подобрать коллизию будет занятием для ооооочень терпеливых, во-вторых кодовое расстояние будет очень большим (т.е. это вообще ни разу не будет похоже на оригинал)
> Ты вот развёл теорию, но не довёл до конца. Тгебую от вас
> довести до конца - взять наиболее удобный для вас архив tar
> с наиболее удобным для вас содержимым, и сгенерировать коллизию любой современной
> хеш-функции по вашему выбору, играя на изменении настроек компрессора. Когда сгенеришь
> - тогда и пиши снова.Держи, эксперт: https://www.opennet.ru/opennews/art.shtml?num=46102
Чисто теоретически вы можете угадать мой 4096-битный ключ случайно сгенерив такой же. Практически... это даже было однажды в дебиане и убунте :)
> Чисто теоретически вы можете угадать мой 4096-битный ключ случайно сгенерив такой же.
> Практически... это даже было однажды в дебиане и убунте :)Зачем угадывать, если знаешь? Хэш-суммы архивов известны. Надо только изменить содержимое и подобрать "соль", вместе с которой получится такой же хэш.
Просвешайтесь: https://www.opennet.ru/opennews/art.shtml?num=46102
Это нормально. Гораздо лучше чем иметь по контрольной сумме на каждый файл/директорию.
А с пожатым архивом еще лучше - меньше размер, быстрее хэш вычислить.
Ненене, на каждый файл - контрольную сумму. Обязательно в xml, так энтерпрайзнее. А потом уже всё затарить и зазиповать.
В json жеж, xml - прошлый век!
Формат сделать плавающим, описание формата положить в тот же json.У нас, модного поколения зуммерков, так нынче принято, а ты, хипстота бородатая, иди на свалку истории - сколько ты ни закрашиваешь седину, все равно ее видно.
Бывает и хуже, некоторые вообще лысеют. И там закрашивай, не закрашивай, разве что маркером что-нибудь неприличное написать останется.
Угу. а в json - блоб с xml-документом в base64.
>> контрольную сумму архива - этозащита от сбоев передачи данных по сети и ошибок носителей
Тут маленькая проблемка: это должна быть чексумма неизменного архива.
А если архив каждый раз переупаковывается, да ещё третьей стороной - получается идиотизм, а не защита от сбоев.
> Тут маленькая проблемка: это должна быть чексумма неизменного архива.
> А если архив каждый раз переупаковывается, да ещё третьей стороной - получается
> идиотизм, а не защита от сбоев.Какая "третья сторона" у тебя перепаковывает архив между HDD и CPU, и между сервером в интернете и твоим компом?
Введите код 49794
Ну вот какая любителям стрелять себе в ногу переупаковала? :)
> редставители GitHub вначале ссылались на то, что постоянные контрольные суммы для архивов никогда не гарантировались.2+2=4, а может 5 или 33.
gzip будет давать разные контрольные суммы при разных настройках сжатия по умолчнию. Можно оптимизировать на скорость сжатия, а можно - на размер архива. Кроме того, в результате оптимизации алгоритма сжатия может получиться иной файл.Высчитывать контрольную сумму от файла, который получен алгоритмом который может улучшаться и показывать лучшие результаты скорости/коэф. сжатия - это надо быть профнепригодным.
Там отнюдь не 2+2, а f(...) = best( size, compression speed, decompression speed ).
> gzip будет давать разные контрольные суммы при разных настройках сжатияа бывает архиватор, который дает одинаковые контрольные суммы при разных настройках сжатия?
>> gzip будет давать разные контрольные суммы при разных настройках сжатия
> а бывает архиватор, который дает одинаковые контрольные суммы при разных настройках сжатия?Вряд ли. Разве что собранный на коленке, который игнорирует настройки, рандом, временные отметки, окружение и т.д.
>Вряд лиесть ведь, по телику показывали, весь ынтернет на флешке сохранял :)
пс:99191
> архиватор, который дает одинаковые контрольные суммыЯ подозреваю тебя тут кусают в зад твои вольные формулировки. Архиватор не даёт контрольных сумм, контрольные суммы считаются другими утилитами. Что архиватор может дать этим утилитам -- это совпадение файла бит-в-бит. Но смысла тогда в настройках сжатия, если вне зависимости от них, результат не меняется?
Внешние утилиты могут считать контрольные суммы так, чтобы они оставались бы неизменными вне зависимости от архиватора. Можно контрольную сумму считать распаковывая, прогоняя через tar или любой другой сериализатор, чтобы объединить всё в один блоб, и считать sha512 по результату. Но чтобы этот блоб получался одинаковым бит-в-бит, придётся всё распаковать на диск, после чего упаковать приводя к каноническому виду. Это не получится делать потоковым пайплайном, потому что архиватор может в разном порядке файлы упаковывать, и надо сначала распаковать, потом упаковать, упорядочивая файлы (включая всякие тонкости, типа симлинков) канонично.
Хотя, если так подумать, можно разработать какую-нибудь хеш-сумму, которая будет хеш-суммой хеш-сумм отдельных файлов, и не зависеть от порядка следования этих файлов. То есть можно что-нибудь потоковое придумать, да. То есть github зря прогнулся. Если бы он не прогнулся, то был бы повод разработать утилиту/библиотеку, которая в каком-то там простом виде принимает потоком неупорядоченную последовательность файлов, а на выходе выдаёт хешсумму, которая не зависит от порядка файлов и всяких сопутствующих факторов, типа хардлинков или что там ещё бывает.
Слишком усложняете...
> Хотя, если так подумать,с этого нужно начинать. всегда.
> github зря прогнулся. Если бы он не прогнулся, то был бы повод разработать утилиту/библиотеку,
он не прогнулся, он отложил на время. тут у тебя не только повод, тут уже дедлайн преодолен.
хотя мне другое странно: зачем вообще гитхаб озаботился настройкой оптимизации архиватора для получения архивов меньшего объема.на "диске" место кончается? звоночек!
Введите код, 58692
> зачем вообще гитхаб озаботился настройкой оптимизации архиватора для получения архивов меньшего объема.Чтобы меньше платить за трафик? А может дело не в размере, а в том сколько процессоры ватт сжигают?
> хотя мне другое странно: зачем вообще гитхаб озаботился настройкой оптимизации архиватора для
> получения архивов меньшего объема.Это не мы. Это разработчиков git спросите, сколько битов они сэкономили на своем новом 20терабайтнике. Мы же внутри используем их поделку as-is, а не переписали все с нуля.
Мы просто обновились на новую модную версию, чтоб не перестать ненароком быть совместимыми с новыми модными скриптами.
Кстати да, можно же проверять контрольную сумму tar-архива, а не сжатого варианта, который модет быть хоть gz, хоть bz2, хоть lz или ещё каким угодно с разными настройками степени сжатия. Разжал - проверил контрольную сумму tar. А в tar можно добавить опцию для получения детерминированного результата, чтобы всегда, например, сортировал список сжимаемых файлов по алфавиту и не выравнивал их по каким-нибудь 512-байтным границам, не добавлял внутрь отметку о времени создания архива и т.п.
> чтобы всегда, например, сортировал список сжимаемых файлов по алфавитуА потом выйдет новая версия glibc с другим порядком collation, и снова произойдёт такой же пц. Если и сортировать на основе имени, то не по самому имени, а по его хэшу - всё-таки есть надежда, что порядок 0<1<2<3<4<5<6<7<8<9<A<B<C<D<E<F в обозримом будущем никто менять не будет.
Зачем, если можно сортировать просто по бинарнику имени (не декодируя строку в соответствии с правилами кодировки, а просто сравнивая байтики).
Латинские A, a, B, b и $ - однобайтовые, их декодировать не нужно, но порядок сортировки всё равно может поменяться: https://postgresql.verite.pro/blog/2018/08/27/glibc-upgrade....
>а бывает архиватор, который дает одинаковые контрольные суммы при разных настройках сжатия?Чтобы были одинаковые суммы, файлы должны быть одинаковыми. Ты хочешь одинаковые результаты при разных настройках сжатия?
>>а бывает архиватор, который дает одинаковые контрольные суммы при разных настройках сжатия?
> Чтобы были одинаковые суммы, файлы должны быть одинаковыми. Ты хочешь одинаковые результаты
> при разных настройках сжатия?мимо.
этот вопрос следует задать aploskov.dev который не только хочет, но, видимо, и получает одинаковые суммы при разных настройках сжатия.
Введите код 42124
Кстати, в unix архиввтор и компрессор - это два разных класса программ. Архиватор - это tar или cpio, для них можно детерминированный результат получить. А для компрессора это не имеет смысла, т.к. не даст возможности менять степень сжатия и улучшать алгоритмы сжатия.
> gzip будет давать разные контрольные суммы при разных настройках сжатияНе может быть! А мужики-то думали, что у всех любых архивов сумма одна и та же! Но тут оказалось, что разные файлы имеют... разные суммы! Да как так-то?!
1. Прочитай новость. Действительно думали.2. Посмотри, на какой комментарий я ответил. Чел иронизирует по поводу 2+2=4, а может 5 или 33. Ну так вот, операция не 2+2, иронию аноним выразил через жопу.
Думали-думали, да недодумали... В результате всё навернули, как обычно.
>это надо быть профнепригодным.то есть, снимаем сумму с самих данных, а не с сжатых архивов
Ну как бы 2+2 это 22.
> 2+2=4, а может 5 или 33.Все мало-мальски знающие люди в курсе, что 2+2=104 - 50 мне, 50 тебе и 4 в кассу.
«Надо обновляться», — говорили они. — «Обновления важны и безопасны».
Для них - да)
Вам количество CVE в гите напомнить за последние пол-года?
Да, нам тоже приходится обновляться. Во-первых из-за них, во-вторых, если мы не будем поддерживать все вчера высосанные из пальца фичи, смузихлебы могут побежать на гитляп, где уже обновили и поддерживают.
Лучше напомни количество пострадавших из-за каждой CVE.
Да сколько раз уже повторять что гит это пятое колесо в телеге.
Все проблемы индустрии в том, что никто не читает опеннетных экпертов...
он и прав и не прав. гит должен быть свой. на своем серваке, а не у мелкосранска(мелкософинска?) в х** знает где. люди пошли такие доверчивые. вот раз пришел приказ партии в сша и все все твои проекты конфискуются с передачей прав другим компаниям. а вас назовут потом плагиатором)) сама идея гит хороша, но предполагалось не общественный гит, а каждой конторы свой.))
> сама идея гитоверинженеринг
шёл бы ты свои докеры в снапы деплоить
эксперты на опеннете появились за долго до появления всех этих проектов, mc не даст соврать :)
Системы контроля версий это пятое колесо у телеги
> Рассматривались такие варианты, как [...] добавление флага "--stable" для сохранения совместимостиНепредусмотрительно. Флаг надо называть --fucking-legacy, лет через десять будет очень актуально.
Более актуально --no-hipsters.
Они каждый раз для каждого вызова собирали архив? Неудивительно. Тем более что формировать архив каждый раз это долго. Человек загружая tar.gz ожидает что он скачивает только файл, а не сформированный архив на лету.Если бы они сохраняли бы уже созданные архивы, то проблема бы решилась более гладко.
> Человек загружая tar.gz ожидает что он скачивает только файл, а не сформированный архив на лету.Ты хотел сказать "_наивный_ человек"? Или может "человек склонный делать ничем не обоснованные выводы"?
> формировать архив каждый раз это долго.
Ты хотел сказать "дорого"? Ведь не важно, насколько это долго, потому что передавать по сети ещё дольше. Важно то, что это отнимает время процессора, которое ограниченный ресурс, и увеличивает сумму в квитанции за электроэнергию. Но хранить архив на диске занимает пространство на диске. И тут мы получаем tradeoff между стоимостью такого объёма диска и стоимостью сжатия на лету.
Вы это так говорите, как будто архив (причем вместе с контрольной суммой) сохранялся не на диск а куда-то в облачко... В принципе, он туда и сохранялся, только вот... это мое облачко, и внутри мои диски.
Ты имеешь в виду "сохранялся при создании на сервере"? Он сохранялся скорее всего в tmpfs, то есть на на диск, а в оперативную память. А контрольная сумма высчитывалась заносилась в субд. Точнее сказать, я не знаю, как там у них было сделано, но я б сделал именно так.
На github можно любой коммит в виде архива скачать. Ты представляешь, сколько места всё это богатство будет занимать, если его на диске хранить? Подозреваю, что они действительно генерируют каждыц архив по запросу и хранят потом его некоторое время в кэше, а удаляют из кэша потом только то, что не было востребовано в течение некотрого времени.
Они и так хранят релизы и много чего ещё. Во-вторых диски дешевле процессоров.
Не для каждого, а по факту релиза. Архив клали в кэш, и если обращений к кэшу не было какое-то время — удаляли, место на дисках не бесконечное и хранить релиз my-hello-world-0.0.1-beta.tar.gz двести лет никто не подписывался. После апдейта кэши, видимо, инвалидировали, что и привело к каскаду ошибок у потребителей. Напоминает как Линус в своё время сломал сборочные скрипты разным локалхостным васянам, выпустив ядро с неожиданной версией. И ехидно так заметил, что, мол, у плохих программистов поломается, да так им и надо.
посконный zip и то куда лучше.
> посконный zip и то куда лучше.для бинарников ARJ
для текстов HA
Надо на zstd переходить.
Lrzip+zpaq всё ещё непревзойдённая связка, но только распаковывается столько же сколько сжимается. Lrzip+lzma9 как дешёвый вариант.
Смех смехом, но на сайте росстата статистику отдают в arj...
Потому что работает - и не трогай.
> Смех смехом, но на сайте росстата статистику отдают в arj...А кто-то шутил?
Последнее время часто rar наблюдаю. Напомнить, что означает жаргонное словечко "винрарный"?
гитшваб, нпм, карго-культ - это все только начало прогрессивных модных молодежных ультрасвободных и экстраудобных супертехнолгий.
Там нет технологий. Только сайты за много денег.
> В ответ на первые жалобы о возникших сбоях представители GitHub вначале ссылались на то, что постоянные контрольные суммы для архивов никогда не гарантировались.Вполне справедливо. А я-то раньше удивлялся: зачем некоторые люди на странице релизов Гитхаба выкладывают свой отдельный tar.gz архив, если по ссылке ниже есть автоматически сгенерированный Гитхабом. А вон оно что, оказывается!
Вообще, классическая картина в разработке ПО: сперва
недальновидно завязываемя на недокументированные делтали реализации, потом плачем, что все поломано.
> недальновидно завязываемя на недокументированные делтали реализации, потом плачем, что
> все поломано.Разьве не логично предполагать что архив конкретной версии софта - нечто неизменное и постоянное? А, действительно, нелогично. Пришлите нам резюме, вы подходите на позицию pr менеджера.
> предполагатьКак бы в этом вся суть проблемы, не?
Ну, предполагайте на здоровье вместо чтения документации - только не плачте потом.
кого волнует твой архив. бери исходный файл конкретной версии и наслаждайся неизменной контрольной суммой.
он предлагает верить циферкам в названии файла.пс:куда ушли времена, Новая Папка1, Новая Папка1_Copy, Новая Папка1 НЕ УДАЛЯТЬ :)
В своих нет всяких .git и сделаны первые шаги autocrap.
Дорога "Всё для ленивых" ведет в ад.
Мне нравится в этой историито, что ПЕРВОЙ реакции Гитхаба (читай Микрософт) на жалобы было завуалированное "А идите вы лесом, ваши проблемы нас не волнуют".
Традиции-с.
Не то что в опенсорсе - сначала совещание, потом конференция, а потом мы посмотрим на ваши пул-реквесты... Может быть...
Ну а какой гений решил надеяться на постоянность контрольной суммы создаваемого на лету архива?
Ну а какой гений зачем-то додумается впилить свою версию архиватора, дающую другие контрольные суммы ?Ведь проблема началась с этого. И тем «гением» оказался микрософт
Проблемы начались у того, кто не думал головой. Улучшение в алгоритме сжатия или простое изменение степени сжатия архива неизбежно приведёт к изменению контрольной суммы. Что теперь, оставлять неэффективную реализацию алгоритма или покупать новые процессоры или диски из-за того, что кто-то опирается на свои выдуманнные предположения, а не на очевидные гарантии?
Именно такой она и должна была быть. Проблемы долбоящеров не должны волновать корпорацию. Сами они такую херню учинили - а как исправлять свои ошибки - "айайай, какие плохие разрабы git и microsoft, не хотят подстраиваться под наши ошибки".
Я правильно понял, проблема в том, что все эти релизные tgz у github нигде не хранятся и формируются по запросу?
исходя из чего ты это "понял"?
Да, именно так, у пострадавших.
В Росе (abf.io/import), например, в очень многих пакетах используются тарболлы с гитхаба, но загружаются в своё хранилище (file-store.rosalinux.ru), а пострадавшие такового не имеют.
во freebsd есть distfiles, насколько я помню
> Разработчики Git пока не пришли к какому-то решению и лишь обсуждают возможные действия.Здрастия, мы - большая злая корпорация, и нам очень важна гарантия безопасности, поэтому мы хотим везде сделать 2FA и отключить логин в гит через пароль. А контрольные суммы не нужно, потому что для маргиналов.
>> Разработчики Git пока не пришли к какому-то решению и лишь обсуждают возможные действия.
> Здрастия, мы - большая злая корпорация, и нам очень важна гарантия безопасности,
> поэтому мы хотим везде сделать 2FA и отключить логин в гит
> через пароль. А контрольные суммы не нужно, потому что для маргиналов.Простите, вы опять все перепутали. МЫ корпорация зла!
А контрольные суммы - это разработчики git, оне белые и пушистые. И уже устроили два совещания и одну конференцию по этому поводу. (но патчей разумеется нет и не ждите)
Можно считать контрольную сумму для tar файла до его архивации (.gz,.zst,.xz). Тогда сумма не будет зависеть от архиватора.Но это нарушит обратную совместимость (зато избавит от зависимости от архиватора).
>Можно считатьвсе можно, ток этим дуракам надо сказать, семь раз отмерь, потом ломай
Будет. Только уже не от gzip/xz/whatever, а от tar.
Напомните майкам для чего нужны контрольные суммы.
Когда они купили Нокию, самое худшее, что они могли сделать в области нанесения вреда СПО - прикрыть Qt. Я ошибался в их изобретательности.
Они пошли выше и удалили то, что использовало это кутэ и жабу, погрузив сие инструменты в пучину стагнации.
> для подтверждения целостности осуществляют сверку загружаемых с GitHub архивов с ранее сохранёнными контрольными суммамиМда, лютые любители стрелять себе по ногам опять пострадали, что ж ты будешь делать-то.
Ни хрена не понятно. Если архив для релиза/тега уже был создан, то нафига его пересоздавать в будущем? или это результат работы альтернативно одаренных розовых пони которые генерят их "on-demand"?Я всегда создаю релиз локально и затем заливаю вручную.
Конечно, можно создать github actions но и тогда результат будет в виде файлов к релизу которые в будущем не трогаются даже гитхабом.
Видимо на GitHub было что-то вроде кэша с удалением давно не запрашиваемых архивов и генерацией новых через "git archive".
То-то замечаю архив на 100Кб качается минуты 2-3.
Они реально считают что архивы в среднем от 100кб до скажем 5 мб реально делают погоды когда там всякие Дениски Поповы заливают очередную сборку убунты или арча по 4гб каждый месяц?
Более того я могу сам скачать архив из тега релиза tar.gz/zip и залить их обратно вручную, вот они точно никогда "не пересоздадутся" автоматически.
> Если архив для релиза/тега уже был создан, то нафига его пересоздавать в будущем?Это же микрософт.
> или это результат работы альтернативно одаренных розовых пониГитхаб может выдавать архив для любого коммита. Педставь, сколько нужно дискового пространства, чтобы все это хранить.
Архивы каждого коммита не попадают на страницу Release. Не тормозим, включаем мозг. Коммитов может быть 10 тысяч, релизов может быть всего штук 5.
> Коммитов может быть 10 тысяч, релизов может быть всего штук 5.И что? Очевидно, что у Гитхаба для этого унифицированный механизм. Ничто не мешает особо одаренным привязаться к контрольной сумме архива произвольного коммита?
> Не тормозим, включаем мозг.
Ты свои ценные советы лучше давай не мне, а всем тем тем, кто завязался на Гитхаб и у кого вся инфраструктура отвалилась от одного коммита.
> Ты свои ценные советы лучше давай не мне, а всем тем тем, кто завязался на Гитхаба у них что - выбор был?
> и у кого вся инфраструктура отвалилась
потому что те чья инфраструктура - берут исходники там куда их соизволили выложить авторы. А те кроме шитхаба давным-давно уже ничего не умеют.
Или это ты так тонко ms обоc@л, что завязали свою инфраструктуру на чужой совершенно ушлепский продукт? Ну да, ну да, могли бы свой git написать, у них есть разработчики получше неудачников принесших нам go[a]t. Но, увы, не хотят. В конце-концов это малодоходный или даже убыточный проект.
> потому что те чья инфраструктура - берут исходники там куда их соизволили выложить авторы.Так авторы исходники по факту не выкладывали :) А остальные почему-то решили, что сгенерированный на лету архив от Гитхаба - это аналог официального тарбола. Причем если в репе есть субмодули, то git archive их не подтягивает, т.е. архивы от Гитхаба в этом случае вообще неюзабельны.
Ну авторы вообще-то кнопку нажаль, подтвердив что да, это именно оно. Релиз с артефактами сам из любого тега не образуется, этот факт отдельно гитхапу обозначать надо.> А остальные почему-то решили, что сгенерированный на лету архив от Гитхаба - это аналог
> официального тарбола.других, еще более официальных, у меня для вас - нет.
Собственно, если оно помечено как релиз - чем это неофициальный тарбол? А что оказывается он каждый день новый - ну так про это нигде даже самым мелким шрифтиком не было.(У фри есть некоторые порты не на релизах, которых либо вообще нет, "жрите свежайшее вот прям из под mcedit", либо они неработоспособны и приходится брать промежуточную версию, но их ни разу не пятьтыщ, и они-то как раз не сломались, там не архив берется.)
Именно. Поэтому привязываться к чексумме конкретного архива, тем более, что он на лету формируется - это клиника.
А проверяли бы подписи и не было бы проблем.
Подписи _чего_?
Подписи тут не помогут особо. Ведь чтобы подписать новый архив нужен ключ. А если этот ключ дать гитхабу то он может подписывать что угодно и когда угодно.
Как будто если его не давать шитхабу это что-то изменит? В лучшую, я имею в виду, сторону.Напомнить вам про историю горе-девелоперов пехепе, которым напихали х-ев в пана...прямо в репо - от имени и по поручению, и подписанных вполне себе? (Как раз шитхабу-то я больше верю, там какая-никакая security team и пока они _сами_ ни одной учетки и ни одного ключа не прогадили. В отличие от их дорогих и обожаемых клиентов - альтернативно-одаренных разработчиков, делающих это регулярно и с явным удовольствием.)
Контрольный хэш архива _гарантирует_ что это _тот_самый_ архив, ВНЕ зависимости от того, прогадил ли его гени[т]альный разработчик все свои подписи, пароли и явки.
Но местным адептам карго-культа это (судя вон по переписке выше) не то что непонятно, а и понимать они ничего не хотят, омм, мани-мани-мани-мани, подпис-подпис-подпис!
К сожалению, только после перехода они узнают что испортили себе этой мантрой карму на пару эонов раскаленного кола в ср-ку.
Аминь!
GitHub виноват что стал менять настройки сжатия для уже сгенерированных архивов-релизов. Даже если файлы не хранятся вообще, а генерируются на каждый запрос на скачивание, можно было менять алгоритм сжатия только для новых релизов, а старым оставить старый алгоритм и старые настройки сжатия
В прочем в нашей днищешаражке та же самая проблема, для старых актов сверки и счетов меняются адреса, фамилии и т.д.
Но у нас руки из ж..мы и мы даже документацию языков программирования, библиотек и фреймворков не читаем. Потому что если оно скомпилировалось и запустились то можно не тратить время на её чтение.
> GitHub виноват что стал менять настройки сжатия для уже сгенерированных архивов-релизов.опять обама виноват? Или неумение опеннетовских экспертов читать написанное?
github использует git.
Никаких настроек в том - нет.> Даже если файлы не хранятся вообще, а генерируются на каждый запрос
> на скачивание, можно было менять алгоритм сжатия только для новых релизов,расскажи это разработчикам гита.
Чё прямо так и используют git.exe без модификации? Ужас то какой... 😱
И их прямо заставляют обновлять этот git.exe при выходе новой версии...
И скопировать предыдущую версию git.exe и делать архивы старых релизов, старым гитом они тоже не могут?Раз не могут, тогда ради одного хостинга придется приделывать костыли вида архивации разными методами в зависимости от даты комита к самому гиту
GitHub скорее всего даже git.exe --stable запустить тоже не сможет, по этому только разные методы сжатия по дате коммита прямо в git, только хардкор
А чтобы гарантировать что на серверах GitHub (хостинга) время и временные зоны не перепуганы, в git (систему контроля версий) нужно добавить ещё и синхронизацию времени по NTP
Ты-то конечно не такой, ты его весь сам переписал?
А, нет... опять админ локалхоста, не умеющий кодить, откуда тут другие...Да, заставляют:
* 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)
Если не знаешь как правильно сделать - вынеси в настройки.Э... это сложно?
Ну ты новость читать не пробовал?"Разработчики Git пока лишь обсуждают возможные действия."
Они еще пару комиссий назначат и двести митингов проведут.
> Ну ты новость читать не пробовал?
> "Разработчики Git пока лишь обсуждают возможные действия."
> Они еще пару комиссий назначат и двести митингов проведут.Так то я вовсе не git имел ввиду.
И, признаться, не могу понять, каким он тут боком причастен.
А вот разработчики гитхаба - да. Их логику понять сложно.
И, таки да. Если вынести в настройки тип архивации сложно, дай два типа архива параллельно.Один вариант - простая архивация.
Второй вариант - архивация с воспроизводимой контрольной суммой.
В Гите можно менять тип архивации. Напимер, черезgit config tar.tar.gz.command ...
задать свою комманду.
> В Гите можно менять тип архивации. Напимер, через
> git config tar.tar.gz.command ...
> задать свою комманду.Речь о гитхабе.