» FreeArc: бесплатный open-source архиватор - Часть 2

ICESCREAM
пролистал темы FreeArc 0.36, FreeArc 0.40, нашёл только упомянутые вскользь похожие моменты

Цитата:

Nabljudatel писал(а):
кстати, скоро там версия 0.4? а то формат архива планируется пометь. Будет ли обратная совместимость?

пока что да. в этой версии формат архива не изменится, только добавятся алгоритмы сжатия и будет полная обратная совместимость. планирую..

Цитата:

У меня есть несколько вопросов.
1.А почему ECM обяательно должен быть внешним? Вроде, исходники есть... Или времени нет, нужно сначала выпустить финальную версию, а потом добавить ?
2. BCJ2 нет, как я понимаю, потому, что у него 4 выходных потока?

Возможно оттого что встроенные методы быстрее работают или ещё из каких соображений, просто интересны были мотивы автора

Цитата:

для чего понадобилось встраивать "внутренние" методы в arc.exe, ведь существуют консольные аналоги rep, dict, lzp и т.п. Не проще ли было покидать исполняемые файлы в bin и вызывать их по мере надобности? И удобнее было бы совершенствовать методы - допустим появился lzma2 - просто закинули lzma2.exe в папочку и прописали его в arc.ini, а сам arc.exe остался бы неизменным. И насчёт обратной совместимости голова не будет болеть. Если в дальнейших планах полноценная поддержка внешних компрессоров в SFX - то так ведь легче будет. К SFX модулю приклеятся только те упаковщики и препроцессоры, которые были использованы при создании архива, и в этом ракурсе неважно будет - "свои" они или разработаны левыми людьми

1. вызов внешних программ - довольно медленное удовольствие. если для распаковки 5-килобайтного файла потребуется вызвать 4 внешних проги - это будет не очень здорово

2. первоначально arc.exe был самодостаточен, это сейчас появилась целая куча файлов которые так и так нужно тащить за собой

3. сама идея внешних упаковщиков появилась гораздо позже

4. до сих пор внешние упаковщики поддерживают далеко не все возможности, которые есть у внутренних. кстати, есть ещё и CLS

5. sfx с внешними упаковщиками пока тоже не поддерживаются, а авто-подклеивание не стоит даже в планах. кстати, хорошая идея - сделать один "пустой" базовый sfx, а всё остальное добавлять к нему по необходимости в виде dll, включая инсталлер, gui, поддержку linux...

crotoff
May be...
Arc.exe and freearc.exe execute PATH command in console mode (before call preprocessors and etc.). PATH set paths to preprcessors and etc.

Цитата:

Не проще ли было покидать исполняемые файлы в bin и вызывать их по мере надобности?

А не отразится ли это сильно негативно на производительности? Разве что сам FA будет определять типы файлов (например, по заголовкам), а после передавать по группам различным прероцессорам, препаковщикам и пр., после чего производить уже, непосредственно, объединение в один архив. При создании sfx, в комплект должны будут "докладываться" используемые для данного архива препроцессоры и пр.
Для больших объемов данных - это было бы отличным решением. Но что делать с архивом в мару МБ, если для его упаковки будет применено с десяток препроцессоров (допустим)? Если же не создавать "автономные" sfx, то встает проблема совместимости с более ранними версиями - так не очень-то "наобновляешься".
Если же подобное реализовать, то стоит сделать обязательно опцию включения используемых при упаковке препроцессоров внутрь архива, в какую-нибудь скрытую область, чтобы они при распаковку помещались во временную папку или вызывались напрямую (как в приложениях виртуализации, вроде thinstall). И тогда бы еще было бы логично что-то делать с прогресс-баром, какм-то образом свзязывать его с внешними модулями, которые, в свою очередь, эстетичнее было бы не отображать на экране.

добавил http://code.google.com/p/freearc/issues/detail?id=79


Цитата:

Я как раз говорю о том, чтобы сам архиватор, при запуске командной строки, указывал бы пути. Т.е. выполнял команду PATH, где указывал бы папки с препроцессорами и пр.

http://code.google.com/p/freearc/issues/detail?id=78


Цитата:

1) Сейчас упаковка большого количества файлов идёт порциями по 20 тыс штук - если увеличить порцию до 100 тыс штук, то явно размер требуемой памяти будет больше?

сейчас программа составляет полный список файлов, сортирует его, затем бьёт на куски по 20к, и каждый кусок попадает в отдельный directory block. это позволяет уменьшить память для распаковки, не более того


Цитата:

3) Можно ли данную опцию выставить в ГУИ или нужно прописывать её руками (например, в ГУИ в дополнительных параметрах)?

вручную


Цитата:

-mrep:1g
в логе
tempfile+rep:1gb
блок 1024м - есть, 256m -нет.
должен был сразу скинуть настройки, зачем tempfile?

счас посмотрю

Добавлено:

Цитата:

Если же подобное реализовать, то стоит сделать обязательно опцию включения используемых при упаковке препроцессоров внутрь архива, в какую-нибудь скрытую область, чтобы они при распаковку помещались во временную папку или вызывались напрямую (как в приложениях виртуализации, вроде thinstall).

так делать нельзя - это прямая дорога вирусам. полноценную виндовую VM встроить не предлагайте

Bulat_Ziganshin

Цитата:

1. вызов внешних программ - довольно медленное удовольствие. если для распаковки 5-килобайтного файла потребуется вызвать 4 внешних проги - это будет не очень здорово

Ввести "границы" применимости внешних модулей, основываясь на количестве, размерах и типах файлов. Например, если в архивируемой папке всего пара-тройка txt, общим объемом в десяток кБ и еще 1 jpeg на полсотни, то FA не будет вызывать ppmonstr и packjpg. "пороговые" значения можно рассчитывать, основываясь, к примеру, на размерах самих применяемых модулей. Допустим, если мы пакуем пяток МБ чистого текста, то включение в состав ppmonstr будет нивелировано повышением степени сжатия на объем больше 75 кБ, занимаемых модулем.

Цитата:

2. первоначально arc.exe был самодостаточен, это сейчас появилась целая куча файлов которые так и так нужно тащить за собой

Примерно тоже самое и с другими архиваторами. Ничего смертельного в этом нет. И в худшем случае, если очень сильно понадобится, то можно было бы все упихнуть снова в один файл. Неудобно, громоздко, "труднообновляемо", но вариант...

Цитата:

4. до сих пор внешние упаковщики поддерживают далеко не все возможности, которые есть у внутренних. кстати, есть ещё и CLS

Можно чуть подробнее, из-за чего так? И о каких возможностях идет речь?

Цитата:

5. sfx с внешними упаковщиками пока тоже не поддерживаются, а авто-подклеивание не стоит даже в планах. кстати, хорошая идея - сделать один "пустой" базовый sfx, а всё остальное добавлять к нему по необходимости в виде dll, включая инсталлер, gui, поддержку linux...

Чего уж мелочиться? Сделать сразу кросс-платформенное приложение с автоматической компиляцией под любую ОС и процессор
А если черьезно, включение внешних модулей в архива - это такая плохая идея? В чем именно ее критические недостатки, которые перекрывают (гипотетически) положительные стороны?

Цитата:

Ввести "границы" применимости внешних модулей

ты готов провести исследования всех упаковщиков на предстапвительном объёме данных и расписать полностью этот алгоритм?


Цитата:

Можно чуть подробнее, из-за чего так? И о каких возможностях идет речь?

потому что не сделано. например, выбор словаря по объёму памяти


Цитата:

А если черьезно, включение внешних модулей в архива - это такая плохая идея?

в архив - плохая, в sfx - хорошая

Bulat_Ziganshin

Цитата:

так делать нельзя - это прямая дорога вирусам. полноценную виндовую VM встроить не предлагайте

От вирусов поможет защита хэшированием модулей и, может быть, даже самого архива. А если уж, мало ли каким чудом, модули в архиве оказались заражены, то обязательно указывать версии используемых при упаковки модулей, чтобы можно было всегда распаковать с использованием внешних версий.

А скрытую обдасть, я имел ввиду область архива. Необязательно делать ее совершенно невидимой, просто сделать так, чтобы модули не распаковывались прямо в п туже папку, что и остальные файлы, или, по крайней мере, сразу оттуда удалялись по окончанию процедуры. Полностью скрывать не стоит еще из-за того, что если очень понадобится, чтобы можно было вытащить модули из состава наружу.

Кстати, одно из преимуществ thinstall-приложений в том, что они могут работать только в своей "песочнице", хоть с вирумаси, хоть без, не угрожая реальной системе, тоже самое верно и наоборот.

Полноценная виндовая VM пока есть только в Windows 7

Цитата:

От вирусов поможет защита хэшированием модулей и, может быть, даже самого архива. А если уж, мало ли каким чудом, модули в архиве оказались заражены, то обязательно указывать версии используемых при упаковки модулей, чтобы можно было всегда распаковать с использованием внешних версий.

нет. представь себе - пользователь скачивает архив с jpg-картинкой. распаковывает его и бах - система заражена вирусами


Цитата:

Кстати, одно из преимуществ thinstall-приложений в том, что они могут работать только в своей "песочнице", хоть с вирумаси, хоть без, не угрожая реальной системе, тоже самое верно и наоборот.

вот для этого и надо иметь встроенную VM

Bulat_Ziganshin

Цитата:

ты готов провести исследования всех упаковщиков на предстапвительном объёме данных и расписать полностью этот алгоритм?

С удовольствием. Только диплом допишу
Я серьезно.

Цитата:

выбор словаря по объёму памяти

Доступной системной или выделенной для конкретной степени сжатия?

Цитата:

в архив - плохая, в sfx - хорошая

В архив я предложил только для гарантии совместимости, не более того. Если это можно будет как-то обойти - я только за и ни в коем случае не буду настаивать на включении модулей внутрь.
Если модули не обновляются раз в месяц, да так, что алгоритмы меняются полностью от версии к версии, то можно обходится более старыми версиями до мажорного обновления FA, где все разом будут обновлены.

Добавлено:

Цитата:

нет. представь себе - пользователь скачивает архив с jpg-картинкой. распаковывает его и бах - система заражена вирусами

Каким образом? Предположим, моя машина заражена вирусом, добавляющим свой код ко всем exe-файлам. Я создаю архив с помощью FA, с применением внешних модулей (да, пусть это бутет архив фоток в jpg). Можно сделать проверку хэшей уже при упаковке. Изначально FA известны хэши модулей и самого себя (самый примитивный, но далеко неидеальный вариант - прописывание хэшей в arc.ini - неидеальный, потому что слишком легко изменить, хотя, если кто-то захочет засунуть внутрь зараженный файл, думаю, это у него в любом случае получится). Если при проверке, хэш не сходится, то FA выдает предупреждение об этом.
Тоже самое должно происходить при распаковке (есть же проверка CRC у sfx рара и я ее на себе уже испытывал...). Т.е. если FA при попытке распаковки sfx определяет, что хэш не сходидся, то выдается сообщение о повреждении архива и (может еще предложить распаковать с помощью внешних, заведомо незараженных, модулей). 100% защиты от вирусов не бывает, в любом случае.

есть надёжный механизм - цифровые подписи, основанные на асимметричном шифровании. т.е. зашифровать/создать подпись могу только я (зная закрытый ключ), а расшифровать/проверить подпись - любой, знающий открытый ключ (этот ключ просто вшивается в fa)

но таким образом можно распространять только модули, которые я сам написал/проверил, т.е. полной автономности от меня не будет. у нас кстати была в своё время мысль - загружать недостающие модули вообще по инету

Цитата:

нет. представь себе - пользователь скачивает архив с jpg-картинкой. распаковывает его и бах - система заражена вирусами

Если же речь идет о W32/Perrun, но тоже самое произойдет при использовании любого из существущих архиваторов. При использовании внешних модулей, вполне возможно, этого как раз получится избежать. Я не уверен, что зараженный W32/Perrun jpeg также легко переварится packjpg, как и незараженное изображение.

Цитата:

100% защиты от вирусов не бывает, в любом случае.

как ни странно, сейчас любые типы архивов 100%-но защищены от того, что при их распаковке машину могут заразить вирусы

Цитата:

есть надёжный механизм - цифровые подписи, основанные на асимметричном шифровании. т.е. зашифровать/создать подпись могу только я (зная закрытый ключ), а расшифровать/проверить подпись - любой, знающий открытый ключ (этот ключ просто вшивается в fa)

есть надёжный механизм - цифровые подписи, основанные на асимметричном шифровании. т.е. зашифровать/создать подпись могу только я (зная закрытый ключ), а расшифровать/проверить подпись - любой, знающий открытый ключ (этот ключ просто вшивается в fa)
Это надежно, но, как выходит, не панацея. Под рар уже появился киген, с которым можно подписывать архивы электронной подписью, что было невозможно ранее. Точно неизвестно, каким образом это получилось, но факт...
Просто интересно, каким образом защищаются от вирусов инсталляторы, упаковщики и др.? Да и если моя машина заражена, а в архив я положу не только безобидные txt, но и уже рараженные PE-файлы, то толку от цифровой подписи никакой не будет. Кстати, ведь если я заражу sfx модуль рара или 7z, то будет, фактически, тоже самое.

Добавлено:

Цитата:

как ни странно, сейчас любые типы архивов 100%-но защищены от того, что при их распаковке машину могут заразить вирусы

Обычные - да, sfx - нет.
Но с "внедрением" модулей в обычные архивы, вроде бы, разобрались, что так делать не стоит, т.к. алгоритмы упаковщиков и препроцессоров меняются очень редко.

Добавлено:

Цитата:

у нас кстати была в своё время мысль - загружать недостающие модули вообще по инету

Интересная мысль. А почему ее не "превратили" в своеобразный web-update?

Кстати, что касается совместимости старых и новых версий (в случае, если нужно обновлять модули или сам FA для распаковки). К примеру, разные версии архивов образов, созданных Acronis True Image далеко не всегда (мягко говоря) открываются всеми версиями. И ничего - пользователей от этого как-то не убывает. Я не призываю к намеренному внесению такого рода изменений, но это не так ужасно. Рар, в свое время тоже пержил переход на третью версию, несовместимую со старыми (меньше 2.80). И 7z сейчас вводит LZMA2, несовместимый со тарыми версиями. И тоже это воспринимается почти в порядке вещей.

Цитата:

Это надежно, но, как выходит, не панацея. Под рар уже появился киген, с которым можно подписывать архивы электронной подписью, что было невозможно ранее.

взломать асимметричное шифрование - невозможно. что сделано в раре и что там на самом деле взломали - я не в курсе


Цитата:

Просто интересно, каким образом защищаются от вирусов инсталляторы, упаковщики и др.? Да и если моя машина заражена, а в архив я положу не только безобидные txt, но и уже рараженные PE-файлы, то толку от цифровой подписи никакой не будет. Кстати, ведь если я заражу sfx модуль рара или 7z, то будет, фактически, тоже самое.

в том-то и дело, что это две разные вещи. запуская sfx, человек доверяет источнику его получения. распаковывая архив, он должен быть уверен, что это ему ничем не грозит

Добавлено:

Цитата:

Интересная мысль. А почему ее не "превратили" в своеобразный web-update?

прверка новых версий сейчас есть. на большее как всегда не было времени


Цитата:

Кстати, что касается совместимости старых и новых версий

в fa добавляются новые алгоритмы. мы здесь обсуждали именно внешние модули

Цитата:

в том-то и дело, что это две разные вещи. запуская sfx, человек доверяет источнику его получения. распаковывая архив, он должен быть уверен, что это ему ничем не грозит

Я, к примеру, если возможно распаковать любой sfx (даже инсталлер) без его запуска (сторонним ПО) - так и делаю. Если говорить о доверии источнику, но не зря же на очень многих сайтах, откуда что-то можно скачать, пишут, чтобы файлы дополнительно проверялись антивирусами. И если, все-таки, говорить о внедрении внутрь не sfx архива дополнительных модулей, то их хэши должны проверятся самим FA, с помощью которого будет производиться распаковка. И еще, если версий моделей установленного FA хватает для распаковки архива, то внутренние модули (в архиве) не должны затрагиваться.

Один момент с заражением exe-файлов... Во-первых, такой тип вирусов встречается в разы реже различных троянов и malware. Во-вторых, симптомы заражения просто не дают спокойно пользоваться ПК (тот же FA должен проверять хотябы свой хэш при запуске, т.к. если заражен хотя бы один exe-файл в папке FA, то будут заражены и все остальные).
...
Вот... Примерный вариант для предотвращения заражения стороннего ПК, разархивирующего не-sfx архив, созданный на зараженном ПК.
- FA при запуске проверяет свой хэш. Если он не совпадает, то архиватор выдает предупреждение о повреждении файла, возможно вирусом. После чего, использование, потенциально также зараженных внешних модулей зарещается. (т.е. выходит, что на зараженном ПК архив, содержащий возможно зараженные модули, не сделаешь)
- модули, используемые FA могут иметь расширение, отличное от exe, что значительно уменьшит вероятность заражения.
- модули, используемые FA могут хранится в zip (или 7z или еще каком-либо) архиве, позволяющем быстро получать доступ к отдельным файлам. (это также кардинально уменьшает вероятность заражения модулей)
- при распаковке арихива с модулями, FA должен заранее спрашивать, использовать ли эти модули или использовать свои внешние.

Такие варианты возможны? Так лучше?

Добавлено:

Цитата:

в fa добавляются новые алгоритмы. мы здесь обсуждали именно внешние модули

Я именно о внешних моделях и писал...

Bulat_Ziganshin

Цитата:

что сделано в раре и что там на самом деле взломали - я не в курсе

Там закейгенили алгоритм на эллиптических кривых (ECNR):
http://en.wikipedia.org/wiki/Elliptic_curve_cryptography

Добавлено:
http://aagern.com/blog/2009/03/взлом-алгоритма-цифровой-подписи-winrar/

Цитата:

Я именно о внешних моделях и писал...

ты писал об acronis/rar/7z и на их примере убеждал меня, что можно добавлять новые алгоритмы


Цитата:

Я, к примеру, если возможно распаковать любой sfx (даже инсталлер) без его запуска (сторонним ПО) - так и делаю. Если говорить о доверии источнику, но не зря же на очень многих сайтах, откуда что-то можно скачать, пишут, чтобы файлы дополнительно проверялись антивирусами.

ага. сначала добавим опасную возможность в архиватор, затем будем с ней бороться

далее. про вирусы я говорю условно, проще представить троянского коня

и вообще, извини, мне надоело всё разжёвывать. распаковка архива не должна выполнять в открытой среде (вне VM) кода, внедрённого в этот архив. точка. для sfx такие правила не нужны, поэтому к нему можно цеплять внешние модули

4kusNick
Тоже хотел указать ссылку , но wzor лежит... а в кэшах поисковиков его не видно...

Цитата:

http://aagern.com/blog/2009/03/взлом-алгоритма-цифровой-подписи-winrar/

словом, либо ключ был слишком мал, либо его потеряли собственно, последнее является одним из недостатков такого метода защиты

Цитата:

ты писал об acronis/rar/7z и на их примере убеждал меня, что можно добавлять новые алгоритмы

Да, но в данном случае речь изначально шла о внешних модулях, и как следствие, совместимости конечных архивов. Думаю, что пользователю будет все равно, почему его архив не распаковывается - потому что нет нужного внешнего модуля или потому что внутренний аргоритм архиватора сменился.

Цитата:

далее. про вирусы я говорю условно, проще представить троянского коня

Для обычного конечного пользователя разныцы не будет. о не суть...

Цитата:

и вообще, извини, мне надоело всё разжёвывать. распаковка архива не должна выполнять в открытой среде (вне VM) кода, внедрённого в этот архив. точка. для sfx такие правила не нужны, поэтому к нему можно цеплять внешние модули

Хорошо. Я уже давно не настаиваю на внедрении модулей в не-sfx архивы.

Добавлено:
Bulat_Ziganshin
Единственное, из-за чего я вообще предложил сначала такой вариант (с включеним модулей в обычные архивы), так только из-за того, что этим модули не идут по умолчанию в комплекте с дистрибутивом FA. И о том, что они могут в некоторых случаях понадобится при распаковке, рядом со ссылкой на дистрибутив, не написано. Не пользоваться ими - нехороший вариант. Остается либо хранить рядом с архивами (и распространять тоже) дистрибутив и архив с модулями или создавать sfx (после включения поддержки встроенных модулей в нем).

Bulat_Ziganshin
Giesmos
А если сделать тупо и примитивно:
при создании архива с использованием внешних модулей включать в команду распаковки проверку наличия таких модулей на компе получателя архива и, в случае их отсутствия, выдавать Интернет-ссылку с предложением скачать недостающие файлы (которые FA потом сам положит в нужную папку)?

Цитата:

А если сделать тупо и примитивно:
при создании архива с использованием внешних модулей включать в команду распаковки проверку наличия таких модулей на компе получателя архива и, в случае их отсутствия, выдавать Интернет-ссылку с предложением скачать недостающие файлы (которые FA потом сам положит в нужную папку)?

Ну вот и замечательно тогда выходит! Двух зайцев сразу - он-лайн обновление поможет решить эту задачу, как и свою непосредственную. Могу только добавить, что в случае отсутствия доступа к и-нету (неплохо бы, тогда еще настройки прокси включить, а то х в очень многих програмах не хватает), сделать запрос на указание файлов обновления или модулей вручную. Допустим, обновления всегда будут идти в архиве arc, а модули - и так и так (чтобы вместе с архимом можно было бы их передать также).

Добавлено:
Bulat_Ziganshin
Все-таки, возможно ли хранить модули в архиве (в папке FA), чтобы они прямо оттуда и вызывались? Я не изучал этот вопрос, но некоторые плееры и эмуляторы консолей могут проигрывать/открывать файлы напрямую из архивов (в т.ч. если в архиве больше одного файла), поэтому подумал, что может быть здесь такое удастся.

Цитата:

Да, но в данном случае речь изначально шла о внешних модулях, и как следствие, совместимости конечных архивов.

тогда мог бы привести в пример сам fa


Цитата:

Не пользоваться ими - нехороший вариант.

хороший. пока что внешние упаковщики - это возможность на любителя. их поддержка потихоньку улучшается, только пожалуйста без шашек наголо в стиле "пусть проверяют архив антивирусами"


Цитата:

А если сделать тупо и примитивно:
при создании архива с использованием внешних модулей включать в команду распаковки проверку наличия таких модулей на компе получателя архива и, в случае их отсутствия, выдавать Интернет-ссылку с предложением скачать недостающие файлы (которые FA потом сам положит в нужную папку)?

в общем, есть два основных варианта: либо программа предлагает пользователю проапгрейдиться, либо качает и использует модули сама

сейчас первое и так худо-бедно есть, хотя сообщение об unknown compression method не помешало бы разбавить советом поставить новую версию

Giesmos
Взор из-за релиза нового офиса лежит, они тут отписывались по этому поводу в своей ветке.


Цитата:

а модули - и так и так

а не слишком ли это уже будет?

Как-то по-извращенски это выглядит, вот хранить в архиве инфу о тех компрессорах, при помощи которых он был сделан - думаю, хорошая идея, а вот сами компрессоры - имхо уже перебор.. =\

Nick222

Цитата:

при создании архива с использованием внешних модулей включать в команду распаковки проверку наличия таких модулей на компе получателя архива и, в случае их отсутствия, выдавать Интернет-ссылку с предложением скачать недостающие файлы (которые FA потом сам положит в нужную папку)?

суть не меняется, по ссылки можно запросто вирус загрузить.

egor23
А кто мешает автоматом проверить контрольную сумму при скачивании?
Да и антивирус запустить тоже можно...

Bulat_Ziganshin

Цитата:

в общем, есть два основных варианта: либо программа предлагает пользователю проапгрейдиться, либо качает и использует модули сама

Предлагает, в смысле, что предлагает указать, где лежит архив с обновлением/модулями.
Качает не самопроизвольно, а уточнив у пользователя. Не всем нравится полная самостоятельность ПО. Или хотя бы сделать отключаемую опцию запроса на скачку.
4kusNick

Цитата:

Как-то по-извращенски это выглядит, вот хранить в архиве инфу о тех компрессорах, при помощи которых он был сделан - думаю, хорошая идея, а вот сами компрессоры - имхо уже перебор.. =\

Нет-нет... Меня, видимо, не так поняли...
Информация о версиях используемых модулей внутри архива - это верно, это обязательно.
А модули, либо скачиваются из и-нета, либо спрашиваются у пользователя, который может быть предварительно взял их с ПК, где создавался архив.
egor23

Цитата:

суть не меняется, по ссылки можно запросто вирус загрузить.

Тоже самое можно сказать про любую ссылку. Windows Update тоже тогда может накачать вирусов Если кто-то специально не положит в обновление зараженные файлы - такого не случится. Вариант взлома сайта с целью осуществления массированного заражения ПК, столько целесообразно, сколь эта ситуация реальна. Сылки на обновления (возможно, с зеркалами), думаю, должны быть прописаны в самом FA.

Nick222

Цитата:

А кто мешает автоматом проверить контрольную сумму при скачивании?

ой, а кто эти ссылки будет добавлять? контрольные суммы?
тот кто создаёт архив

или я не понял о чём речь...

Добавлено:
если создатель архива не позаботился о пользователях, которые будут распаковывать архив, это его проблемы.

egor23
Вижу так:
Автор FA при выпуске релиза включает туда ссылки на возможные модули внешних архиваторов (если они могут обновиться за время от релиза до релиза или ссылки не прямые - можно их перевыложить на свой сайт - там не такой большой объём).
При упаковке с использованием внешних модулей FA включает в архив информацию об использованных внешних модулях, прямые ссылки на них, их контрольные суммы.
При распаковке FA проверяет наличие указанных внешних модулей и сверяет их контрольные суммы. При отсутствии или несовпадении - предлагает скачать нужные модули - что - при согласии юзера - сам и делает.

Цитата:

ой, а кто эти ссылки будет добавлять? контрольные суммы?
тот кто создаёт архив

Тот, кто их будет выкладывать на сайте FA. Тот, кто создает архив, максимум, может передать модули/сам дистрибутив вместе с архивом.


Добавлено:

Цитата:

При упаковке с использованием внешних модулей FA включает в архив информацию об использованных внешних модулях, прямые ссылки на них, их контрольные суммы.
При распаковке FA проверяет наличие указанных внешних модулей и сверяет их контрольные суммы. При отсутствии или несовпадении - предлагает скачать нужные модули - что - при согласии юзера - сам и делает.

Что-то нехорошо получается... Контрольные суммы на модули должны лежать там же, где и сами модули, т.е. на сайте FA, а никак не внутри архива. Т.к. версии модулей будут обновляться, их хэши также будут изменяться. Внутри архива никаких ссылок не должно быть.