| 1.1, Аноним (1), 18:03, 03/02/2023 [ответить] [﹢﹢﹢] [ · · · ]
| +16 +/– |
Контрольная сумма должна рассчитываться самостоятельно каждым проектом своим способом по исходным файлам, а не сторонним архивам.
| | |
| |
| 2.14, Аноним (14), 18:48, 03/02/2023 [^] [^^] [^^^] [ответить]
| +5 +/– | |
> что привело к изменению их контрольных сумм и массовым сбоям
как раз в духе микрософта.
| | |
| 2.21, НяшМяш (ok), 19:24, 03/02/2023 [^] [^^] [^^^] [ответить]
| –3 +/– |
 Я даже не знаю как они так формируют архивы, что у них контрольные суммы не совпадают. Формируют архив, делают сумму, а потом говорят гитхабу "заархивируй мне вот это но уже сам для себя" что ли? Обычно сначала пакуют, потом прогоняют чексумму и в конце заливают всё готовое. Чем паковать вообще фиолетово - хоть таргз, хоть 7з, хоть винраром.
| | |
| |
| 3.31, ms (??), 19:58, 03/02/2023 [^] [^^] [^^^] [ответить]
| +3 +/– | |
Еще круче: говорят шитхабу - сформируй-ка нам архив _своего_ репо с ~нашим~ (мвахахаха) кодом.
И сами мизинчиком так в экранчик тык-потык.
А у нас оно вот такое - архив сами даже не знаем зачем (до нас писали) создается каждые пять минут заново, а ВДРУГ в репо сами собой изменились комиты пятилетней давности - обязательно надо переупаковать, нельзя ж просто так ничего не трогать, особенно старые срезы исходников.
| | |
| |
| 4.222, Аноним (222), 17:38, 07/02/2023 [^] [^^] [^^^] [ответить]
| +/– |
Я так понимаю, что иначе пришлось бы хранить вечно архивы для каждого коммита, да даже если для релизов это весьма и весьма дофига
| | |
|
|
| 2.131, Аноним (-), 12:20, 04/02/2023 [^] [^^] [^^^] [ответить]
| +/– |
> Контрольная сумма должна рассчитываться самостоятельно каждым проектом
> своим способом по исходным файлам, а не сторонним архивам.
Для этого придется репу гита клонить. Скачать gzip c релизом все ж быстрей. Я кстати не понимаю - а какого черта трогать уже сгенеренные файлы? Ну ок, для новых оно поменяется - и чрет бы с ними. Индусам никогда не приходила в голову идея что старые файлы можно просто оставить в покое а не генерить постоянно?
| | |
| |
| 3.140, www2 (??), 12:45, 04/02/2023 [^] [^^] [^^^] [ответить] | +1 +/– | Ну есть какой-нибудь потребитель какого-то архива, сделанного из какого-то конкр... большой текст свёрнут, показать | | |
| |
| 4.145, Аноним (-), 13:45, 04/02/2023 [^] [^^] [^^^] [ответить]
| +/– |
> Ну есть какой-нибудь потребитель какого-то архива, сделанного из какого-то конкретного
> коммита. И этот потребитель приходит скачивать свой архив раз в 5
> лет. И представь, что таких потребителей миллионы,
Откуда их миллионы и что они делают? Это боты ботнета? Зобанить гадов.
> а каждый архив весит сотни мегабайт.
Жесткие диски нынче емкие, им похрену. Выгрузить на медленные но емкие сторажи, пусть качают неспешно.
> платящие ей деньги, могут что-то требовать с неё.
Да я уже понял что MS перехватив это нечто решил картинно самоубиться о стену, то 2FA, то теперь это, скоро эта штука станет как codeplex и народ о нем забудет. Broken links чинить народ задолбается конечно, что поделать. Поэтому всякие штуки типа notabug'а стали в разы популярнее.
| | |
| |
| |
| 6.162, нейм (?), 18:00, 04/02/2023 [^] [^^] [^^^] [ответить]
| +/– |
сходу jekyll
если поискать, то таких статических можно нарыть и больше
| | |
| 6.185, Аноним (-), 03:00, 05/02/2023 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> А чем заменить pages?
Двухбаксовой впской. Намного круче будет и без зависимости от п-сов которые могут все перефигачить в любой момент.
| | |
| |
| 7.205, Аноним (205), 20:00, 05/02/2023 [^] [^^] [^^^] [ответить]
| +/– |
Бесплатный pages, который пользователю не нужно обслуживать и в который можно публиковать пушем в репу сразу же, без промежуточных действий заменить двухбаксовой впской на хостинге, который мало того, что точно так же может всё перефигачить в любой момент, так ещё и не будет за тебя админить ничего. Ох уж эта нердота. Хлебом не корми, дай в консольке попечатать.
| | |
|
|
|
|
| 3.167, Аноним (167), 19:17, 04/02/2023 [^] [^^] [^^^] [ответить]
| –1 +/– | |
>Для этого придется репу гита клонить
Так клоньте, б****. Необучаемые. Если у каких-то отсталых архивы - прибитый гвоздями формат, то ффтопку такие системы сборки пакетов.
| | |
| |
| 4.186, Аноним (-), 03:02, 05/02/2023 [^] [^^] [^^^] [ответить]
| +/– | |
> Так клоньте, б****.
Это заметно дольше. И врядли слабей грузит серваки сабжа.
> Если у каких-то отсталых архивы - прибитый гвоздями формат,
Таких систем на все вкусы, от опенврт, внезапно, до всяких хипстеров.
| | |
|
|
|
| |
| |
| 3.8, Аноньимъ (ok), 18:26, 03/02/2023 [^] [^^] [^^^] [ответить]
| +7 +/– |
 > ну виляет и виляет, что бубнить то
Главное не бухтеть, всё схвачено у кого нужно, вопрос под контролем, всё решат нужно только подождать.
| | |
|
| 2.35, ms (??), 20:06, 03/02/2023 [^] [^^] [^^^] [ответить]
| –2 +/– | |
Собака сама виновата. Какой вообще смысл в контрольных суммах исходников которые каждый день новые - сами не знаем. Это у них пережитки времен sourceforge, где архивы и исходники вообще никак не пересекались, что разработчик (или стыривший его пароли) залил, то и отдавалось.
Вместо того чтоб эту глупость просто убрать, они вот, понаделали новых костылей а теперь обижаются, когда самый нижний вдруг выпал.
Либо пусть доверяют целиком нашей инфраструктуре, либо не выпендриваются и делают каждый раз clone.
| | |
| |
| 3.132, Аноним (-), 12:23, 04/02/2023 [^] [^^] [^^^] [ответить]
| +1 +/– | |
Что значит какой смысл? Там обычно качают конкретный тарбол и чекают его хэш, захардкожено в чей-то сборочный или деплойский скрипт. Чтобы проверить что это и правда оно а не левый троян от васяна.
И как видим - это отлично работает, "васян" удумавший тихой сапой менять что-то там в сорцах был запален.
| | |
| |
| 4.163, ms (??), 18:12, 04/02/2023 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> И как видим - это отлично работает,
"Например, нарушилась сборка около 5800 портов"
- отлично работает.
Напоминаем - вы "нарушились" только потому что мы рутинно обновили git (авторами которого не являемся и отслеживать все подобные улучшизмы не подписывались).
Но вы продолжайте, продолжайте.
| | |
| |
| 5.187, Аноним (-), 03:04, 05/02/2023 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> "Например, нарушилась сборка около 5800 портов" - отлично работает.
Было бы сильно хуже если бы микросакс отгрузил измененное файло 5800 сборочницам без того чтобы они это еще и заметили.
> Напоминаем - вы "нарушились" только потому что мы рутинно обновили git (авторами
> которого не являемся и отслеживать все подобные улучшизмы не подписывались).
Я не понимаю какого черта они уже релизнутые файлы трогают, прямо повтор сорсфоржных грабель, осталось еще рекламу в виндовый инсталлер врезать наверное.
| | |
| |
| 6.211, Stellarwind (?), 10:51, 06/02/2023 [^] [^^] [^^^] [ответить]
| +/– | |
Очевидно же, что они хранят релизнутые файлы, если они залиты вручную.
А если вы запрашиваете архив конкретного тега\коммита, он формируется автоматом и может подчищаться для экономии. С ними и возникла проблема.
| | |
|
|
|
|
|
| 1.9, Михаил (??), 18:27, 03/02/2023 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
Пихать в архив файл с контрольными суммами содержимого? Ну, действительно, проверять контрольную сумму архива - это как-то тупо, важна-то целостность содержимого.
| | |
| |
| 2.12, Шарп (ok), 18:46, 03/02/2023 [^] [^^] [^^^] [ответить]
| +1 +/– |
 Здесь контрольная сумма не для целостности, а для защиты от подмены.
| | |
| |
| |
| 4.75, ms (??), 23:15, 03/02/2023 [^] [^^] [^^^] [ответить]
| +1 +/– | |
Нет, у наших друзей из freebsd именно для защиты от подмены. Для этого они ее просто хранят у себя, один раз посчитанную при опакечивании конкретной версии. Без всяких ненужных подписей, закрытые ключи от которых вы так любите нечаянно закомитить в репозиторий. Просто и эффективно. Было.
Потому что битый архив скачать еще ладно, а вот вместо распаковки, как у вас всех принято, ненароком исполнить какой-нибудь интересный код - так себе идея.
Но это все имело смысл во времена, когда архивы были архивами, для хранения навечно. А не просто сжатыми исходниками для упрощения скачивания. Если нас поломают - вам никакие контрольные суммы не помогут. Так что передайте им чтоб кончали устаревшей ерундой заниматься.
| | |
| |
| 5.104, Sw00p aka Jerom (?), 07:02, 04/02/2023 [^] [^^] [^^^] [ответить]
| +/– | |
>А не просто сжатыми исходниками для упрощения скачивания.
ну а кто виноват? бсдешник гит не придумывали, который на лету формирует архив от любого коммита. А как иначе понять, что я скачал необходимый срез состояния проекта, если заранее не сохраню его контрольную сумму? Тупо по циферкам в имени файла ориентироваться?
| | |
| |
| 6.129, пох. (?), 12:13, 04/02/2023 [^] [^^] [^^^] [ответить] | +/– | Обама, наверное Он еще помнится в подъезде у меня нассал bsdшники гит не приду... большой текст свёрнут, показать | | |
| |
| 7.174, Sw00p aka Jerom (?), 20:41, 04/02/2023 [^] [^^] [^^^] [ответить]
| +/– | |
>А оно - вот.
вот оно что у шитхаба места для архивов нет
>переложив окончательно ответственность на microsoft?
кек, тут я считаю майки как хотят так и вертят, проблема в тех кто их услугами пользуются.
>Все равно в конечном итоге ты доверяешь его содержимому.
после проверки
| | |
| |
| 8.180, пох. (?), 01:27, 05/02/2023 [^] [^^] [^^^] [ответить] | +/– | Ну тебе ж объяснили - там механизм наверняка общий в том числе для вообще однора... большой текст свёрнут, показать | | |
| |
| |
| 10.214, пох. (?), 17:30, 06/02/2023 [^] [^^] [^^^] [ответить] | +/– | Так других-то нет ну не переписывать же им самим git Тем более вони опять буде... текст свёрнут, показать | | |
|
|
|
| 7.177, Michael Shigorin (ok), 22:19, 04/02/2023 [^] [^^] [^^^] [ответить]
| +1 +/– |
 Не, Грета. Что не объяснила до сих пор за неприемлемость нагрева её детства сжиманием одних и тех же архивов в промышленных масштабах -- и заодно за SSL по поводу и без оного.
| | |
|
|
|
| 4.134, Аноним (-), 12:28, 04/02/2023 [^] [^^] [^^^] [ответить] | +/– | Захардкодить sha256 тарбола какой в сборочный скрипт достигает ту же цель но быс... большой текст свёрнут, показать | | |
| |
| 5.176, Sw00p aka Jerom (?), 22:04, 04/02/2023 [^] [^^] [^^^] [ответить]
| +/– | |
> Ах да, чтобы майк вообще смог подписать что-то - ему приватный ключ надо давать.
эммммм, зачем? подписывает владелец (автор, мейнтейнер и т.д.)
> для хэша взял и почему я им доверяю но это другой вопрос.
доверяй, но проверяй :) а хеш получать из рук в руки (шутка)
> Зачем майкам потребовалось ворошить уже существующие тарболы - вопрос интересный.
у них не то, чтобы места нет для хранения тарболов, но и выходит временного места нет при сжатии на лету, вот и заменили алгоритм на с большим кэфом сжатия.
| | |
| |
| 6.181, пох. (?), 01:29, 05/02/2023 [^] [^^] [^^^] [ответить]
| +1 +/– |
>> Ах да, чтобы майк вообще смог подписать что-то - ему приватный ключ надо давать.
> эммммм, зачем? подписывает владелец (автор, мейнтейнер и т.д.)
владелец уже выложил все исходники на шитхаб и уже нажал кнопочку "релиз". Как теперь он что-то подпишет не давая ключей владельцу шитхаба?
> у них не то, чтобы места нет для хранения тарболов, но и
> выходит временного места нет при сжатии на лету, вот и заменили
> алгоритм на с большим кэфом сжатия.
б-ть, эксперт, ты новость-то вообще читать пробовал а не бредить?
| | |
| |
| 7.197, Sw00p aka Jerom (?), 12:14, 05/02/2023 [^] [^^] [^^^] [ответить]
| +/– |
> владелец уже выложил все исходники на шитхаб и уже нажал кнопочку "релиз".
> Как теперь он что-то подпишет не давая ключей владельцу шитхаба?
а причем тут вообще шитхаб? подписывает владелец и выкладывает владелец
> б-ть, эксперт, ты новость-то вообще читать пробовал а не бредить?
такс, зачем генерить архив на лету?
| | |
|
| 6.194, Аноним (-), 11:44, 05/02/2023 [^] [^^] [^^^] [ответить]
| +/– | |
> эммммм, зачем? подписывает владелец (автор, мейнтейнер и т.д.)
Вообще-то конкретный хэш пишут для предсказуемости процесса сборки, а тут вон тот господин сможет черти что отгрузать. Если у меня компонент A билдился с комионентом B версии X это еще ничего не говорит что с версией X+5 он тоже нормально сбилдится, мало ли кто там какие апи поменять решил.
А с точки зрения верификации origin - примерно 1 фиг, что я хэш ключа которым подписано где-то узнаю, что хэш тарбола, разницы никакой только канители больше.
> доверяй, но проверяй :) а хеш получать из рук в руки (шутка)
Fingerprint ключа аналогичен в этом аспекте.
| | |
| |
| 7.200, Sw00p aka Jerom (?), 12:37, 05/02/2023 [^] [^^] [^^^] [ответить]
| +/– | |
> Вообще-то конкретный хэш пишут для предсказуемости процесса сборки
речь идет о хешах тарболов
> что я хэш ключа которым подписано где-то узнаю, что хэш тарбола, разницы никакой
> только канители больше.
у вас лежит тарбол, контрольная сумма и подпись, рядом ключа для верификации лежать не должно, это совсем другая тема, как безопасно его получить, конечно когда он там же будет лежать - толку не будет.
> Fingerprint ключа аналогичен в этом аспекте.
фингерпринты выкладывать нет смысла, другой механизм должен быть, и это не тема сего обсуждения.
мы же не будем обсуждать как хранится приватный ключ у мейнтейнера, ясно же - секрет должен храниться - в секрете :)
| | |
|
|
|
|
| 3.111, Аноним (111), 09:13, 04/02/2023 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Проблему вызвало то, что сжатые архивы, генерируемые встроенной реализацией gzip на базе zlib, бинарно отличаются от архивов, созданных утилитой gzip
Вот это и вопрос - что за код массово добавляется в исходники неизвестно кем, в результате чего контрольные суммы не совпадают. Несовпадение контрольных сумм означает только одно - подмену исходников. Всё. Другие пояснения не требуются
| | |
| |
| 4.120, www2 (??), 10:26, 04/02/2023 [^] [^^] [^^^] [ответить]
| +1 +/– | |
Несовпадение контрольных сумм архивов может означать банальное изменение степени сжатия. Захочет, допустим, github снизить нагрузку на ппоцессоры своих серверов и настроит их так, чтобы они не старались сильно сжимать - понизят степень сжатия.
А подмену исходников нужно проверять не по контрольной сумме архива, а по контрольной сумме каждого файла, входящего в состав архива. Вы целостность исходников проверяете или увеличив степень сжатия вам можно напихать в архив другие исходники и ещё один фиктивный файл для того, чтобы контрольная сумма и размер совпали с прежними?
| | |
| |
| 5.130, пох. (?), 12:19, 04/02/2023 [^] [^^] [^^^] [ответить] | +/– | во времена когда писали pkg, идиотизм снизить нагрузку , перепаковывая архивы к... большой текст свёрнут, показать | | |
| |
| 6.135, Аноним (-), 12:30, 04/02/2023 [^] [^^] [^^^] [ответить]
| +/– |
Вообще-то очень странная идея менять gzip'ы уже сгенереных релизов. Какой-то индусский способ "оптимизации" нагрузки. Они что, каждому юзеру тарбол релиза индивидуально чтоли генерили?!
| | |
| |
| 7.142, пох. (?), 13:17, 04/02/2023 [^] [^^] [^^^] [ответить] | +/– | ну вот похоже, что да, они настолько ну может не каждому, кэшировали наверняк... большой текст свёрнут, показать | | |
| |
| 8.146, Аноним (-), 13:49, 04/02/2023 [^] [^^] [^^^] [ответить] | +/– | Выгрузить на вон ту пачку 10терабайтных винчей и пусть там качают по 100 кило в ... большой текст свёрнут, показать | | |
| |
| 9.158, пох. (?), 15:09, 04/02/2023 [^] [^^] [^^^] [ответить] | +/– | херак, выпуск новой версии какого-нибудь npm, ее качает миллиард васянов, все др... текст свёрнут, показать | | |
|
|
|
| 6.141, www2 (??), 12:59, 04/02/2023 [^] [^^] [^^^] [ответить] | +/– | Хэш, будь он хоть трижды криптографическим, это всего лишь функция настоящего со... большой текст свёрнут, показать | | |
| |
| 7.169, Аноним (169), 19:28, 04/02/2023 [^] [^^] [^^^] [ответить]
| +/– |
Ты вот развёл теорию, но не довёл до конца. Тгебую от вас довести до конца - взять наиболее удобный для вас архив tar с наиболее удобным для вас содержимым, и сгенерировать коллизию любой современной хеш-функции по вашему выбору, играя на изменении настроек компрессора. Когда сгенеришь - тогда и пиши снова.
| | |
| |
| 8.215, пох. (?), 17:37, 06/02/2023 [^] [^^] [^^^] [ответить] | +/– | ну, если бы такое было даже в теории невозможно - мы бы изобрели работающий архи... текст свёрнут, показать | | |
|
| 7.196, Аноним (-), 11:50, 05/02/2023 [^] [^^] [^^^] [ответить]
| +/– |
Чисто теоретически вы можете угадать мой 4096-битный ключ случайно сгенерив такой же. Практически... это даже было однажды в дебиане и убунте :)
| | |
| |
| 8.226, www2 (??), 17:04, 08/02/2023 [^] [^^] [^^^] [ответить] | +/– | Зачем угадывать, если знаешь Хэш-суммы архивов известны Надо только изменить с... текст свёрнут, показать | | |
|
|
|
|
|
|
| 2.13, keydon (ok), 18:48, 03/02/2023 [^] [^^] [^^^] [ответить]
| +2 +/– |
 Это нормально. Гораздо лучше чем иметь по контрольной сумме на каждый файл/директорию.
А с пожатым архивом еще лучше - меньше размер, быстрее хэш вычислить.
| | |
| |
| 3.85, YetAnotherOnanym (ok), 02:14, 04/02/2023 [^] [^^] [^^^] [ответить]
| +2 +/– |
 Ненене, на каждый файл - контрольную сумму. Обязательно в xml, так энтерпрайзнее. А потом уже всё затарить и зазиповать.
| | |
| |
| 4.128, пох. (?), 12:05, 04/02/2023 [^] [^^] [^^^] [ответить]
| +2 +/– |
В json жеж, xml - прошлый век!
Формат сделать плавающим, описание формата положить в тот же json.
У нас, модного поколения зуммерков, так нынче принято, а ты, хипстота бородатая, иди на свалку истории - сколько ты ни закрашиваешь седину, все равно ее видно.
| | |
| |
| 5.136, Аноним (-), 12:31, 04/02/2023 [^] [^^] [^^^] [ответить]
| +/– |
Бывает и хуже, некоторые вообще лысеют. И там закрашивай, не закрашивай, разве что маркером что-нибудь неприличное написать останется.
| | |
|
|
|
| 2.19, Атон (?), 19:21, 03/02/2023 [^] [^^] [^^^] [ответить]
| +4 +/– | |
>> контрольную сумму архива - это
защита от сбоев передачи данных по сети и ошибок носителей
| | |
| |
| 3.125, Омномним (?), 10:49, 04/02/2023 [^] [^^] [^^^] [ответить]
| +/– |
Тут маленькая проблемка: это должна быть чексумма неизменного архива.
А если архив каждый раз переупаковывается, да ещё третьей стороной - получается идиотизм, а не защита от сбоев.
| | |
| |
| 4.149, Атон (?), 13:57, 04/02/2023 [^] [^^] [^^^] [ответить]
| –2 +/– |
> Тут маленькая проблемка: это должна быть чексумма неизменного архива.
> А если архив каждый раз переупаковывается, да ещё третьей стороной - получается
> идиотизм, а не защита от сбоев.
Какая "третья сторона" у тебя перепаковывает архив между HDD и CPU, и между сервером в интернете и твоим компом?
Введите код 49794
| | |
|
|
|
| 1.15, Аноним (14), 18:53, 03/02/2023 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– | |
> редставители GitHub вначале ссылались на то, что постоянные контрольные суммы для архивов никогда не гарантировались.
2+2=4, а может 5 или 33.
| | |
| |
| 2.17, aploskov.dev (ok), 19:05, 03/02/2023 [^] [^^] [^^^] [ответить]
| +/– |
 gzip будет давать разные контрольные суммы при разных настройках сжатия по умолчнию. Можно оптимизировать на скорость сжатия, а можно - на размер архива. Кроме того, в результате оптимизации алгоритма сжатия может получиться иной файл.
Высчитывать контрольную сумму от файла, который получен алгоритмом который может улучшаться и показывать лучшие результаты скорости/коэф. сжатия - это надо быть профнепригодным.
Там отнюдь не 2+2, а f(...) = best( size, compression speed, decompression speed ).
| | |
| |
| 3.20, Атон (?), 19:22, 03/02/2023 [^] [^^] [^^^] [ответить]
| +3 +/– | |
> gzip будет давать разные контрольные суммы при разных настройках сжатия
а бывает архиватор, который дает одинаковые контрольные суммы при разных настройках сжатия?
| | |
| |
| 4.22, aploskov.dev (ok), 19:24, 03/02/2023 [^] [^^] [^^^] [ответить]
| +/– |
>> gzip будет давать разные контрольные суммы при разных настройках сжатия
> а бывает архиватор, который дает одинаковые контрольные суммы при разных настройках сжатия?
Вряд ли. Разве что собранный на коленке, который игнорирует настройки, рандом, временные отметки, окружение и т.д.
| | |
| 4.30, Аноним (-), 19:53, 03/02/2023 [^] [^^] [^^^] [ответить] | –2 +/– | Я подозреваю тебя тут кусают в зад твои вольные формулировки Архиватор не даёт ... большой текст свёрнут, показать | | |
| |
| 5.44, Атон (?), 20:57, 03/02/2023 [^] [^^] [^^^] [ответить]
| +/– | |
> Хотя, если так подумать,
с этого нужно начинать. всегда.
> github зря прогнулся. Если бы он не прогнулся, то был бы повод разработать утилиту/библиотеку,
он не прогнулся, он отложил на время. тут у тебя не только повод, тут уже дедлайн преодолен.
хотя мне другое странно: зачем вообще гитхаб озаботился настройкой оптимизации архиватора для получения архивов меньшего объема.
на "диске" место кончается? звоночек!
Введите код, 58692
| | |
| |
| 6.47, Аноним (-), 21:03, 03/02/2023 [^] [^^] [^^^] [ответить]
| –2 +/– | |
> зачем вообще гитхаб озаботился настройкой оптимизации архиватора для получения архивов меньшего объема.
Чтобы меньше платить за трафик? А может дело не в размере, а в том сколько процессоры ватт сжигают?
| | |
| 6.71, ms (??), 23:08, 03/02/2023 [^] [^^] [^^^] [ответить]
| +1 +/– |
> хотя мне другое странно: зачем вообще гитхаб озаботился настройкой оптимизации архиватора для
> получения архивов меньшего объема.
Это не мы. Это разработчиков git спросите, сколько битов они сэкономили на своем новом 20терабайтнике. Мы же внутри используем их поделку as-is, а не переписали все с нуля.
Мы просто обновились на новую модную версию, чтоб не перестать ненароком быть совместимыми с новыми модными скриптами.
| | |
|
| 5.121, www2 (??), 10:33, 04/02/2023 [^] [^^] [^^^] [ответить]
| +2 +/– |
Кстати да, можно же проверять контрольную сумму tar-архива, а не сжатого варианта, который модет быть хоть gz, хоть bz2, хоть lz или ещё каким угодно с разными настройками степени сжатия. Разжал - проверил контрольную сумму tar. А в tar можно добавить опцию для получения детерминированного результата, чтобы всегда, например, сортировал список сжимаемых файлов по алфавиту и не выравнивал их по каким-нибудь 512-байтным границам, не добавлял внутрь отметку о времени создания архива и т.п.
| | |
| |
| 6.165, YetAnotherOnanym (ok), 19:03, 04/02/2023 [^] [^^] [^^^] [ответить]
| +/– | |
> чтобы всегда, например, сортировал список сжимаемых файлов по алфавиту
А потом выйдет новая версия glibc с другим порядком collation, и снова произойдёт такой же пц. Если и сортировать на основе имени, то не по самому имени, а по его хэшу - всё-таки есть надежда, что порядок 0<1<2<3<4<5<6<7<8<9<A<B<C<D<E<F в обозримом будущем никто менять не будет.
| | |
| |
| 7.170, Аноним (170), 19:32, 04/02/2023 [^] [^^] [^^^] [ответить]
| +/– |
Зачем, если можно сортировать просто по бинарнику имени (не декодируя строку в соответствии с правилами кодировки, а просто сравнивая байтики).
| | |
|
|
|
| 4.91, Аноним (91), 05:19, 04/02/2023 [^] [^^] [^^^] [ответить]
| +/– | |
>а бывает архиватор, который дает одинаковые контрольные суммы при разных настройках сжатия?
Чтобы были одинаковые суммы, файлы должны быть одинаковыми. Ты хочешь одинаковые результаты при разных настройках сжатия?
| | |
| |
| 5.117, Атон (?), 09:46, 04/02/2023 [^] [^^] [^^^] [ответить]
| +/– |
>>а бывает архиватор, который дает одинаковые контрольные суммы при разных настройках сжатия?
> Чтобы были одинаковые суммы, файлы должны быть одинаковыми. Ты хочешь одинаковые результаты
> при разных настройках сжатия?
мимо.
этот вопрос следует задать aploskov.dev который не только хочет, но, видимо, и получает одинаковые суммы при разных настройках сжатия.
Введите код 42124
| | |
|
| 4.122, www2 (??), 10:37, 04/02/2023 [^] [^^] [^^^] [ответить]
| +1 +/– |
Кстати, в unix архиввтор и компрессор - это два разных класса программ. Архиватор - это tar или cpio, для них можно детерминированный результат получить. А для компрессора это не имеет смысла, т.к. не даст возможности менять степень сжатия и улучшать алгоритмы сжатия.
| | |
|
| 3.48, Аноним (14), 21:04, 03/02/2023 [^] [^^] [^^^] [ответить]
| +4 +/– | |
> gzip будет давать разные контрольные суммы при разных настройках сжатия
Не может быть! А мужики-то думали, что у всех любых архивов сумма одна и та же! Но тут оказалось, что разные файлы имеют... разные суммы! Да как так-то?!
| | |
| |
| 4.50, aploskov.dev (ok), 21:09, 03/02/2023 [^] [^^] [^^^] [ответить]
| –1 +/– | |
1. Прочитай новость. Действительно думали.
2. Посмотри, на какой комментарий я ответил. Чел иронизирует по поводу 2+2=4, а может 5 или 33. Ну так вот, операция не 2+2, иронию аноним выразил через жопу.
| | |
| |
| 5.59, Аноним (14), 22:37, 03/02/2023 [^] [^^] [^^^] [ответить]
| +/– |
Думали-думали, да недодумали... В результате всё навернули, как обычно.
| | |
|
|
|
| 2.127, YetAnotherOnanym (ok), 11:39, 04/02/2023 [^] [^^] [^^^] [ответить]
| +/– | |
> 2+2=4, а может 5 или 33.
Все мало-мальски знающие люди в курсе, что 2+2=104 - 50 мне, 50 тебе и 4 в кассу.
| | |
|
| |
| 2.70, ms (??), 23:05, 03/02/2023 [^] [^^] [^^^] [ответить]
| –3 +/– |
Вам количество CVE в гите напомнить за последние пол-года?
Да, нам тоже приходится обновляться. Во-первых из-за них, во-вторых, если мы не будем поддерживать все вчера высосанные из пальца фичи, смузихлебы могут побежать на гитляп, где уже обновили и поддерживают.
| | |
|
| |
| 2.54, Аноним (54), 21:31, 03/02/2023 [^] [^^] [^^^] [ответить]
| –3 +/– |
Все проблемы индустрии в том, что никто не читает опеннетных экпертов...
| | |
| |
| 3.58, анонна (?), 22:29, 03/02/2023 [^] [^^] [^^^] [ответить]
| –3 +/– |
он и прав и не прав. гит должен быть свой. на своем серваке, а не у мелкосранска(мелкософинска?) в х** знает где. люди пошли такие доверчивые. вот раз пришел приказ партии в сша и все все твои проекты конфискуются с передачей прав другим компаниям. а вас назовут потом плагиатором)) сама идея гит хороша, но предполагалось не общественный гит, а каждой конторы свой.))
| | |
|
|
| 1.26, Аноним (-), 19:39, 03/02/2023 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– | |
> Рассматривались такие варианты, как [...] добавление флага "--stable" для сохранения совместимости
Непредусмотрительно. Флаг надо называть --fucking-legacy, лет через десять будет очень актуально.
| | |
| 1.27, fuggy (ok), 19:40, 03/02/2023 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
 Они каждый раз для каждого вызова собирали архив? Неудивительно. Тем более что формировать архив каждый раз это долго. Человек загружая tar.gz ожидает что он скачивает только файл, а не сформированный архив на лету.
Если бы они сохраняли бы уже созданные архивы, то проблема бы решилась более гладко.
| | |
| |
| 2.32, Аноним (-), 20:00, 03/02/2023 [^] [^^] [^^^] [ответить]
| +/– | |
> Человек загружая tar.gz ожидает что он скачивает только файл, а не сформированный архив на лету.
Ты хотел сказать "_наивный_ человек"? Или может "человек склонный делать ничем не обоснованные выводы"?
> формировать архив каждый раз это долго.
Ты хотел сказать "дорого"? Ведь не важно, насколько это долго, потому что передавать по сети ещё дольше. Важно то, что это отнимает время процессора, которое ограниченный ресурс, и увеличивает сумму в квитанции за электроэнергию. Но хранить архив на диске занимает пространство на диске. И тут мы получаем tradeoff между стоимостью такого объёма диска и стоимостью сжатия на лету.
| | |
| |
| 3.34, ms (??), 20:02, 03/02/2023 [^] [^^] [^^^] [ответить]
| +/– | |
Вы это так говорите, как будто архив (причем вместе с контрольной суммой) сохранялся не на диск а куда-то в облачко... В принципе, он туда и сохранялся, только вот... это мое облачко, и внутри мои диски.
| | |
| |
| 4.46, Аноним (-), 21:02, 03/02/2023 [^] [^^] [^^^] [ответить]
| +1 +/– |
Ты имеешь в виду "сохранялся при создании на сервере"? Он сохранялся скорее всего в tmpfs, то есть на на диск, а в оперативную память. А контрольная сумма высчитывалась заносилась в субд. Точнее сказать, я не знаю, как там у них было сделано, но я б сделал именно так.
| | |
|
|
| 2.133, www2 (??), 12:24, 04/02/2023 [^] [^^] [^^^] [ответить]
| +1 +/– |
На github можно любой коммит в виде архива скачать. Ты представляешь, сколько места всё это богатство будет занимать, если его на диске хранить? Подозреваю, что они действительно генерируют каждыц архив по запросу и хранят потом его некоторое время в кэше, а удаляют из кэша потом только то, что не было востребовано в течение некотрого времени.
| | |
| |
| 3.148, fuggy (ok), 13:53, 04/02/2023 [^] [^^] [^^^] [ответить]
| +/– |
Они и так хранят релизы и много чего ещё. Во-вторых диски дешевле процессоров.
| | |
|
| 2.206, Аноним (205), 20:12, 05/02/2023 [^] [^^] [^^^] [ответить]
| +/– |
Не для каждого, а по факту релиза. Архив клали в кэш, и если обращений к кэшу не было какое-то время — удаляли, место на дисках не бесконечное и хранить релиз my-hello-world-0.0.1-beta.tar.gz двести лет никто не подписывался. После апдейта кэши, видимо, инвалидировали, что и привело к каскаду ошибок у потребителей. Напоминает как Линус в своё время сломал сборочные скрипты разным локалхостным васянам, выпустив ядро с неожиданной версией. И ехидно так заметил, что, мол, у плохих программистов поломается, да так им и надо.
| | |
|
| |
| 2.45, Атон (?), 21:00, 03/02/2023 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> посконный zip и то куда лучше.
для бинарников ARJ
для текстов HA
| | |
| |
| 3.74, Аноним (74), 23:15, 03/02/2023 [^] [^^] [^^^] [ответить]
| +/– |
Lrzip+zpaq всё ещё непревзойдённая связка, но только распаковывается столько же сколько сжимается. Lrzip+lzma9 как дешёвый вариант.
| | |
| |
| 4.118, Атон (?), 09:48, 04/02/2023 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Смех смехом, но на сайте росстата статистику отдают в arj...
А кто-то шутил?
| | |
|
|
| 2.112, Аноним (111), 09:14, 04/02/2023 [^] [^^] [^^^] [ответить]
| –1 +/– |
Последнее время часто rar наблюдаю. Напомнить, что означает жаргонное словечко "винрарный"?
| | |
|
| 1.41, ihatenpm (?), 20:41, 03/02/2023 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
гитшваб, нпм, карго-культ - это все только начало прогрессивных модных молодежных ультрасвободных и экстраудобных супертехнолгий.
| | |
| 1.43, Аноним (54), 20:51, 03/02/2023 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– | |
> В ответ на первые жалобы о возникших сбоях представители GitHub вначале ссылались на то, что постоянные контрольные суммы для архивов никогда не гарантировались.
Вполне справедливо. А я-то раньше удивлялся: зачем некоторые люди на странице релизов Гитхаба выкладывают свой отдельный tar.gz архив, если по ссылке ниже есть автоматически сгенерированный Гитхабом. А вон оно что, оказывается!
Вообще, классическая картина в разработке ПО: сперва
недальновидно завязываемя на недокументированные делтали реализации, потом плачем, что все поломано.
| | |
| |
| 2.51, ms (??), 21:11, 03/02/2023 [^] [^^] [^^^] [ответить]
| +/– |
> недальновидно завязываемя на недокументированные делтали реализации, потом плачем, что
> все поломано.
Разьве не логично предполагать что архив конкретной версии софта - нечто неизменное и постоянное? А, действительно, нелогично. Пришлите нам резюме, вы подходите на позицию pr менеджера.
| | |
| |
| 3.53, Аноним (54), 21:25, 03/02/2023 [^] [^^] [^^^] [ответить]
| +/– | |
> предполагать
Как бы в этом вся суть проблемы, не?
Ну, предполагайте на здоровье вместо чтения документации - только не плачте потом.
| | |
| 3.57, Аноним (57), 22:23, 03/02/2023 [^] [^^] [^^^] [ответить]
| –1 +/– |
кого волнует твой архив. бери исходный файл конкретной версии и наслаждайся неизменной контрольной суммой.
| | |
| |
| 4.105, Sw00p aka Jerom (?), 07:06, 04/02/2023 [^] [^^] [^^^] [ответить]
| +1 +/– | |
он предлагает верить циферкам в названии файла.
пс:куда ушли времена, Новая Папка1, Новая Папка1_Copy, Новая Папка1 НЕ УДАЛЯТЬ :)
| | |
|
|
|
| 1.73, Kuromi (ok), 23:11, 03/02/2023 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
 Мне нравится в этой историито, что ПЕРВОЙ реакции Гитхаба (читай Микрософт) на жалобы было завуалированное "А идите вы лесом, ваши проблемы нас не волнуют".
Традиции-с.
| | |
| |
| 2.78, Аноним (77), 00:43, 04/02/2023 [^] [^^] [^^^] [ответить]
| +/– |
Не то что в опенсорсе - сначала совещание, потом конференция, а потом мы посмотрим на ваши пул-реквесты... Может быть...
| | |
| 2.84, mikhailnov (ok), 01:39, 04/02/2023 [^] [^^] [^^^] [ответить]
| +/– |
 Ну а какой гений решил надеяться на постоянность контрольной суммы создаваемого на лету архива?
| | |
| |
| 3.109, Бывалый смузихлёб (?), 08:24, 04/02/2023 [^] [^^] [^^^] [ответить]
| –2 +/– | |
Ну а какой гений зачем-то додумается впилить свою версию архиватора, дающую другие контрольные суммы ?
Ведь проблема началась с этого. И тем «гением» оказался микрософт
| | |
| |
| 4.137, www2 (??), 12:32, 04/02/2023 [^] [^^] [^^^] [ответить]
| +1 +/– |
Проблемы начались у того, кто не думал головой. Улучшение в алгоритме сжатия или простое изменение степени сжатия архива неизбежно приведёт к изменению контрольной суммы. Что теперь, оставлять неэффективную реализацию алгоритма или покупать новые процессоры или диски из-за того, что кто-то опирается на свои выдуманнные предположения, а не на очевидные гарантии?
| | |
|
|
| 2.171, Аноним (171), 19:36, 04/02/2023 [^] [^^] [^^^] [ответить]
| +/– |
Именно такой она и должна была быть. Проблемы долбоящеров не должны волновать корпорацию. Сами они такую херню учинили - а как исправлять свои ошибки - "айайай, какие плохие разрабы git и microsoft, не хотят подстраиваться под наши ошибки".
| | |
|
| 1.79, edo (ok), 00:50, 04/02/2023 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
 Я правильно понял, проблема в том, что все эти релизные tgz у github нигде не хранятся и формируются по запросу?
| | |
| |
| 2.83, mikhailnov (ok), 01:37, 04/02/2023 [^] [^^] [^^^] [ответить]
| +/– |
Да, именно так, у пострадавших.
В Росе (abf.io/import), например, в очень многих пакетах используются тарболлы с гитхаба, но загружаются в своё хранилище (file-store.rosalinux.ru), а пострадавшие такового не имеют.
| | |
|
| 1.82, Аноним (82), 01:36, 04/02/2023 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– | |
> Разработчики Git пока не пришли к какому-то решению и лишь обсуждают возможные действия.
Здрастия, мы - большая злая корпорация, и нам очень важна гарантия безопасности, поэтому мы хотим везде сделать 2FA и отключить логин в гит через пароль. А контрольные суммы не нужно, потому что для маргиналов.
| | |
| |
| 2.164, ms (??), 18:19, 04/02/2023 [^] [^^] [^^^] [ответить]
| +/– |
>> Разработчики Git пока не пришли к какому-то решению и лишь обсуждают возможные действия.
> Здрастия, мы - большая злая корпорация, и нам очень важна гарантия безопасности,
> поэтому мы хотим везде сделать 2FA и отключить логин в гит
> через пароль. А контрольные суммы не нужно, потому что для маргиналов.
Простите, вы опять все перепутали. МЫ корпорация зла!
А контрольные суммы - это разработчики git, оне белые и пушистые. И уже устроили два совещания и одну конференцию по этому поводу. (но патчей разумеется нет и не ждите)
| | |
|
| 1.90, Аноним (90), 04:34, 04/02/2023 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– | |
Можно считать контрольную сумму для tar файла до его архивации (.gz,.zst,.xz). Тогда сумма не будет зависеть от архиватора.
Но это нарушит обратную совместимость (зато избавит от зависимости от архиватора).
| | |
| |
| 2.114, Аноним (111), 09:18, 04/02/2023 [^] [^^] [^^^] [ответить]
| +1 +/– |
Когда они купили Нокию, самое худшее, что они могли сделать в области нанесения вреда СПО - прикрыть Qt. Я ошибался в их изобретательности.
| | |
| |
| 3.179, Аноним (14), 00:27, 05/02/2023 [^] [^^] [^^^] [ответить]
| +/– |
Они пошли выше и удалили то, что использовало это кутэ и жабу, погрузив сие инструменты в пучину стагнации.
| | |
|
|
| 1.123, Омномним (?), 10:46, 04/02/2023 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
> для подтверждения целостности осуществляют сверку загружаемых с GitHub архивов с ранее сохранёнными контрольными суммами
Мда, лютые любители стрелять себе по ногам опять пострадали, что ж ты будешь делать-то.
| | |
| 1.138, Аноним (138), 12:35, 04/02/2023 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– | |
Ни хрена не понятно. Если архив для релиза/тега уже был создан, то нафига его пересоздавать в будущем? или это результат работы альтернативно одаренных розовых пони которые генерят их "on-demand"?
Я всегда создаю релиз локально и затем заливаю вручную.
Конечно, можно создать github actions но и тогда результат будет в виде файлов к релизу которые в будущем не трогаются даже гитхабом.
| | |
| |
| 2.143, Аноним (143), 13:18, 04/02/2023 [^] [^^] [^^^] [ответить]
| +/– |
Видимо на GitHub было что-то вроде кэша с удалением давно не запрашиваемых архивов и генерацией новых через "git archive".
| | |
| |
| 3.152, Аноним (152), 14:04, 04/02/2023 [^] [^^] [^^^] [ответить]
| +1 +/– |
Они реально считают что архивы в среднем от 100кб до скажем 5 мб реально делают погоды когда там всякие Дениски Поповы заливают очередную сборку убунты или арча по 4гб каждый месяц?
| | |
| |
| 4.153, Аноним (152), 14:06, 04/02/2023 [^] [^^] [^^^] [ответить]
| +/– |
Более того я могу сам скачать архив из тега релиза tar.gz/zip и залить их обратно вручную, вот они точно никогда "не пересоздадутся" автоматически.
| | |
|
|
| 2.156, Аноним (14), 14:48, 04/02/2023 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Если архив для релиза/тега уже был создан, то нафига его пересоздавать в будущем?
Это же микрософт.
| | |
| 2.160, Аноним (54), 16:34, 04/02/2023 [^] [^^] [^^^] [ответить]
| +/– | |
> или это результат работы альтернативно одаренных розовых пони
Гитхаб может выдавать архив для любого коммита. Педставь, сколько нужно дискового пространства, чтобы все это хранить.
| | |
| |
| 3.161, Аноним (152), 17:29, 04/02/2023 [^] [^^] [^^^] [ответить]
| –1 +/– |
Архивы каждого коммита не попадают на страницу Release. Не тормозим, включаем мозг. Коммитов может быть 10 тысяч, релизов может быть всего штук 5.
| | |
| |
| 4.166, Аноним (54), 19:06, 04/02/2023 [^] [^^] [^^^] [ответить]
| +/– | |
> Коммитов может быть 10 тысяч, релизов может быть всего штук 5.
И что? Очевидно, что у Гитхаба для этого унифицированный механизм. Ничто не мешает особо одаренным привязаться к контрольной сумме архива произвольного коммита?
> Не тормозим, включаем мозг.
Ты свои ценные советы лучше давай не мне, а всем тем тем, кто завязался на Гитхаб и у кого вся инфраструктура отвалилась от одного коммита.
| | |
| |
| 5.182, пох. (?), 01:34, 05/02/2023 [^] [^^] [^^^] [ответить]
| +/– | |
> Ты свои ценные советы лучше давай не мне, а всем тем тем, кто завязался на Гитхаб
а у них что - выбор был?
> и у кого вся инфраструктура отвалилась
потому что те чья инфраструктура - берут исходники там куда их соизволили выложить авторы. А те кроме шитхаба давным-давно уже ничего не умеют.
Или это ты так тонко ms обоc@л, что завязали свою инфраструктуру на чужой совершенно ушлепский продукт? Ну да, ну да, могли бы свой git написать, у них есть разработчики получше неудачников принесших нам go[a]t. Но, увы, не хотят. В конце-концов это малодоходный или даже убыточный проект.
| | |
| |
| 6.184, Аноним (54), 02:07, 05/02/2023 [^] [^^] [^^^] [ответить]
| +/– | |
> потому что те чья инфраструктура - берут исходники там куда их соизволили выложить авторы.
Так авторы исходники по факту не выкладывали :) А остальные почему-то решили, что сгенерированный на лету архив от Гитхаба - это аналог официального тарбола. Причем если в репе есть субмодули, то git archive их не подтягивает, т.е. архивы от Гитхаба в этом случае вообще неюзабельны.
| | |
| |
| 7.198, пох. (?), 12:21, 05/02/2023 [^] [^^] [^^^] [ответить]
| +1 +/– | |
Ну авторы вообще-то кнопку нажаль, подтвердив что да, это именно оно. Релиз с артефактами сам из любого тега не образуется, этот факт отдельно гитхапу обозначать надо.
> А остальные почему-то решили, что сгенерированный на лету архив от Гитхаба - это аналог
> официального тарбола.
других, еще более официальных, у меня для вас - нет.
Собственно, если оно помечено как релиз - чем это неофициальный тарбол? А что оказывается он каждый день новый - ну так про это нигде даже самым мелким шрифтиком не было.
(У фри есть некоторые порты не на релизах, которых либо вообще нет, "жрите свежайшее вот прям из под mcedit", либо они неработоспособны и приходится брать промежуточную версию, но их ни разу не пятьтыщ, и они-то как раз не сломались, там не архив берется.)
| | |
|
|
|
|
| 3.193, Омномним (?), 11:39, 05/02/2023 [^] [^^] [^^^] [ответить]
| +/– |
Именно. Поэтому привязываться к чексумме конкретного архива, тем более, что он на лету формируется - это клиника.
| | |
|
|
| |
| 2.201, Аноним (201), 12:39, 05/02/2023 [^] [^^] [^^^] [ответить]
| +/– |
Подписи тут не помогут особо. Ведь чтобы подписать новый архив нужен ключ. А если этот ключ дать гитхабу то он может подписывать что угодно и когда угодно.
| | |
| |
| 3.202, пох. (?), 15:17, 05/02/2023 [^] [^^] [^^^] [ответить] | +3 +/– | Как будто если его не давать шитхабу это что-то изменит В лучшую, я имею в виду... большой текст свёрнут, показать | | |
|
|
| 1.208, Аноним (207), 20:46, 05/02/2023 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
GitHub виноват что стал менять настройки сжатия для уже сгенерированных архивов-релизов. Даже если файлы не хранятся вообще, а генерируются на каждый запрос на скачивание, можно было менять алгоритм сжатия только для новых релизов, а старым оставить старый алгоритм и старые настройки сжатия
| | |
| |
| 2.209, Аноним (207), 20:57, 05/02/2023 [^] [^^] [^^^] [ответить]
| +/– |
В прочем в нашей днищешаражке та же самая проблема, для старых актов сверки и счетов меняются адреса, фамилии и т.д.
Но у нас руки из ж..мы и мы даже документацию языков программирования, библиотек и фреймворков не читаем. Потому что если оно скомпилировалось и запустились то можно не тратить время на её чтение.
| | |
| 2.210, пох. (?), 09:48, 06/02/2023 [^] [^^] [^^^] [ответить]
| +/– | |
> GitHub виноват что стал менять настройки сжатия для уже сгенерированных архивов-релизов.
опять обама виноват? Или неумение опеннетовских экспертов читать написанное?
github использует git.
Никаких настроек в том - нет.
> Даже если файлы не хранятся вообще, а генерируются на каждый запрос
> на скачивание, можно было менять алгоритм сжатия только для новых релизов,
расскажи это разработчикам гита.
| | |
| |
| 3.216, Аноним (207), 09:34, 07/02/2023 [^] [^^] [^^^] [ответить]
| +/– |
Чё прямо так и используют git.exe без модификации? Ужас то какой... 😱
И их прямо заставляют обновлять этот git.exe при выходе новой версии...
И скопировать предыдущую версию git.exe и делать архивы старых релизов, старым гитом они тоже не могут?
Раз не могут, тогда ради одного хостинга придется приделывать костыли вида архивации разными методами в зависимости от даты комита к самому гиту
| | |
| |
| 4.217, Аноним (207), 09:41, 07/02/2023 [^] [^^] [^^^] [ответить]
| –1 +/– |
GitHub скорее всего даже git.exe --stable запустить тоже не сможет, по этому только разные методы сжатия по дате коммита прямо в git, только хардкор
А чтобы гарантировать что на серверах GitHub (хостинга) время и временные зоны не перепуганы, в git (систему контроля версий) нужно добавить ещё и синхронизацию времени по NTP
| | |
| 4.218, ms (??), 12:01, 07/02/2023 [^] [^^] [^^^] [ответить]
| +/– |
Ты-то конечно не такой, ты его весь сам переписал?
А, нет... опять админ локалхоста, не умеющий кодить, откуда тут другие...
Да, заставляют:
* 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)
| | |
|
|
|
| 1.212, Серб (ok), 13:54, 06/02/2023 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Если не знаешь как правильно сделать - вынеси в настройки.
Э... это сложно?
| | |
| |
| 2.219, ms (??), 12:03, 07/02/2023 [^] [^^] [^^^] [ответить]
| +/– | |
Ну ты новость читать не пробовал?
"Разработчики Git пока лишь обсуждают возможные действия."
Они еще пару комиссий назначат и двести митингов проведут.
| | |
| |
| 3.220, Серб (ok), 12:08, 07/02/2023 [^] [^^] [^^^] [ответить]
| +/– |
> Ну ты новость читать не пробовал?
> "Разработчики Git пока лишь обсуждают возможные действия."
> Они еще пару комиссий назначат и двести митингов проведут.
Так то я вовсе не git имел ввиду.
И, признаться, не могу понять, каким он тут боком причастен.
А вот разработчики гитхаба - да. Их логику понять сложно.
| | |
|
|
| 1.213, Серб (ok), 13:57, 06/02/2023 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
И, таки да. Если вынести в настройки тип архивации сложно, дай два типа архива параллельно.
Один вариант - простая архивация.
Второй вариант - архивация с воспроизводимой контрольной суммой.
| | |
| |
| 2.221, Аноним (54), 16:45, 07/02/2023 [^] [^^] [^^^] [ответить]
| +/– | |
В Гите можно менять тип архивации. Напимер, через
git config tar.tar.gz.command ...
задать свою комманду.
| | |
| |
| 3.224, Серб (ok), 09:55, 08/02/2023 [^] [^^] [^^^] [ответить]
| +/– |
> В Гите можно менять тип архивации. Напимер, через
> git config tar.tar.gz.command ...
> задать свою комманду.
Речь о гитхабе.
| | |
|
|
|
