URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 118937
[ Назад ]

Исходное сообщение
"Уязвимости в cpio и libarchive"

Отправлено opennews , 06-Ноя-19 20:36 
Спустя четыре года с момента прошлого выпуска опубликован релиз утилиты для архивирования файлов cpio 2.13, применяемой в пакетах RPM  и в  initramfs. В новом выпуске устранены три уязвимости:...

Подробнее: https://www.opennet.me/opennews/art.shtml?num=51820


Содержание

Сообщения в этом обсуждении
"Уязвимости в cpio и libarchive"
Отправлено Аноним , 06-Ноя-19 20:36 
Никто не удивлён (привет любителям фряхи).

"Уязвимости в cpio и libarchive"
Отправлено Аноним , 06-Ноя-19 20:43 
А кстати вспомнил, cmake зависит от libarchive. Больше она особо ничем не полезна.

Про cpio давно не слышал, она умеет в дедупликацию? Я хочу дедуплицировать данные в тарболах, но мне почему-то предлагают только платную онлайн дедупликацию тарболов.


"Уязвимости в cpio и libarchive"
Отправлено Аноним , 06-Ноя-19 20:53 
Ну я пробовал использовать её, не понравилось. Взял всякие libzip и написал немного лапшекода к ним, куда лучше libarchive в которой cve за cve (даже при том, что она никому не нужна). А про дедупликацию это так, о наболевшем. Может кто-нибудь поделится опытом.

"Уязвимости в cpio и libarchive"
Отправлено Аноним , 07-Ноя-19 04:35 
Для дедупликации и сжатия заоодно, можно использовать zbackup
Оно работает как фильтр. В сторону zbackup скармливается tar архив. Если надо распаковать, на выходе zbackup дает тоже tar.

"Уязвимости в cpio и libarchive"
Отправлено Аноним , 08-Ноя-19 00:28 
Я не уверен, как это сравнить адекватно. Тарбол 3.6гб, 7z на максимальном сжатии даёт 1.8 гб, сабж - 1.5 гб но при этом это какая-то куча мутных файлов сжатая в непонятной степени (не настраивается?), манов нет, справки по-сути тоже никакой.

"Уязвимости в cpio и libarchive"
Отправлено Аноним84701 , 08-Ноя-19 15:30 
> это какая-то куча мутных файлов

Это использование FS, вместо прикрученной сбоку изолентой DB с индексами кусков и сборки всего в один большой, красивый файл.

> сжатая в непонятной степени (не настраивается?),
> манов нет, справки по-сути тоже никакой.

zbackup config edit <repo>


chunk {
  max_size: 65536
}
bundle {
  max_payload_size: 2097152
  compression_method: "lzma"
}
lzma {
  compression_level: 6
}


"Уязвимости в cpio и libarchive"
Отправлено Аноним , 08-Ноя-19 02:13 
Borgbackup намного удобней и приятней, с lzma9 репа 1.4гб, но это не важно, можно спокойно использовать zstd с любым сжатием и экономить по сравнению с любым архиватором, а вот дедуплицированный тарбол мне тут тоже не дали, всё не то, export-tar даёт такой же тарбол в 3.6 гб (без сжатия). На всякий случай проверил:

дефолтный tgz, он даёт файл 2.2гб (напомню, 7z весит 1.8гб),
xz-9 даёт 1.9гб (очень медленно)

дополнительные эксперименты:

borg без сжатия, объём репы 2.1гб (гб=гибибайты, кстати)

Time (start): Fri, 2019-11-08 01:54:29
Time (end):   Fri, 2019-11-08 01:55:16
Duration: 47.37 seconds
Number of files: 25138
Utilization of max. archive size: 0%
------------------------------------------------------------------------------
                       Original size      Compressed size    Deduplicated size
This archive:                3.83 GB              3.83 GB              2.24 GB
All archives:                3.83 GB              3.83 GB              2.24 GB

                       Unique chunks         Total chunks
Chunk index:                    8875                25834
------------------------------------------------------------------------------

Если эту репу сжать в 7z (lzma9) получается файл 1.4гб (если репу сжимать боргом то же самое выходит), дефолтный zstd для сравнения (троечка что ли) 1.5гб. Файлы по большей части бинарные, да. И никто их не может дедуплицировать мне.


"Уязвимости в cpio и libarchive"
Отправлено Shalik , 08-Ноя-19 05:40 
Если для бэкапов просто - duplicacy.

"Уязвимости в cpio и libarchive"
Отправлено Аноним , 08-Ноя-19 09:34 
Оно на python2. В любом случае, мне для передачи по сети и ответственного хранения, просто удивительно как ни 1 архиватор не дедуплицирует файлы. Видимо, возьму zpaq вместо 7z и буду тралить людей в интернете. Для сравнения zpaq на 9чке сжимает 250 секунд, но разница с 6 там минимальна (6 - 230с что ли)

0.000000 + (3823.484717 -> 2025.510872 -> 1385.343196) = 1385.343196 MB
0.000000 + (3823.484717 -> 2025.510872 -> 1396.953740) = 1396.953740 MB

7z (почему-то только полтора ядра грузит) 17 минут против ~5, однозначная победа за zpaq.


"Уязвимости в cpio и libarchive"
Отправлено Аноним , 08-Ноя-19 00:01 
mksquashfs Luke!

"Уязвимости в cpio и libarchive"
Отправлено Аноним , 08-Ноя-19 00:37 
Не, не работает, это было первое, что я проверил. 7z с большим словарём пока топчик по размеру результата, но он тоже не дедуплицирует - к большим объёмам слабо приминимо. zbackup дедуплицирует (хоть и не даёт настроить компрессор видимо), но хранит при этом файлы в репе, я же хочу простой дедуплицированный архив получить и он этого похоже не умеет.

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


"Уязвимости в cpio и libarchive"
Отправлено gsdh , 10-Ноя-19 23:52 
git может

"Уязвимости в cpio и libarchive"
Отправлено ievoochielaPh5Ph , 06-Ноя-19 20:47 
Ну да. На дворе конец 2019 года, пора бы закрыть CVE-2015-1197 опубликованный 2015-01-19 12:20 UTC. То такими темпами CVE скоро пора будет в школу вести :-D

"Уязвимости в cpio и libarchive"
Отправлено Sluggard , 06-Ноя-19 22:46 
Если ты знаешь дату публикации, значит ходил по ссылке, и не мог не видеть, что оно было пофикшено 2015-02-03.
В чём юмор?

"Уязвимости в cpio и libarchive"
Отправлено Аноним , 07-Ноя-19 18:01 
А почему релиз с фиксом в 2019?

"Уязвимости в cpio и libarchive"
Отправлено Sluggard , 07-Ноя-19 18:42 
Это вопросы к ребятам из GNU. У них большие паузы между выпусками стабильных версий.

"Уязвимости в cpio и libarchive"
Отправлено Аноним , 06-Ноя-19 21:29 
cpio
Интересно, а во Free ее кто-нибудь до сих пор использует.
Это какой-то привет из 90-х

"Уязвимости в cpio и libarchive"
Отправлено OpenEcho , 07-Ноя-19 00:39 
>Это какой-то привет из 90-х

Из начала 80-x... для точности


"Уязвимости в cpio и libarchive"
Отправлено chubartavec , 07-Ноя-19 03:15 
Конечно. Скрипты архивации вида: "find dir | cpio -o -H newc | gzip -9 > arch.`date '+%Y%m%d'`.cpio.gz" с середины 90-х используются, еще со вторых версий Free. Работают - зачем что-то менять?

"Уязвимости в cpio и libarchive"
Отправлено Аноним , 07-Ноя-19 05:06 
cpio менять может и не надо, а вот сменить gzip на zstd таки наверное уже пора.

"Уязвимости в cpio и libarchive"
Отправлено пох. , 07-Ноя-19 10:11 
я использую. Юникс - он вообще из 70х, если вы не в курсе.
Приветы из "2k19" - это оставляю вам, любители обмазываться свежайшим "новым стандартом".

P.S. справедливости ради - в современной freebsd что cpio, что tar - врапперы над пресловутой libarchive, отличающиеся только набором параметров.


"Уязвимости в cpio и libarchive"
Отправлено fi2fi , 07-Ноя-19 11:42 
ну так как фри претендует на гордое имя Unix, то да, должно быть согласно спецификациям  )))

"Уязвимости в cpio и libarchive"
Отправлено Free , 07-Ноя-19 12:32 
На имя - не, не претендуем. Имя досталось полным п-сам, сборщикам денег за воздух. Об это мараться нет никакого смысла. По слухам даже оракл отказался от сертификации новых сборок solaris. Нехай эпл платит, это в их духе, платить за побрякушки.

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

А сертификата - у того юникс, который писали Ритчи с Томсоном, тоже никогда не было, представляете?!


"Уязвимости в cpio и libarchive"
Отправлено Аноним , 07-Ноя-19 19:55 
" позволяет перезаписать файлы за пределами каталога, в который раскрывается архив. "
а, то есть можно указать куда распаковывать? а то я как то попробовал потрогать архив от другой платформы, а оно мне его в корень раскатало

"Уязвимости в cpio и libarchive"
Отправлено Ordu , 10-Ноя-19 16:49 
возможно твоя ситуация была обусловлена тем, что в архиве были указаны полные пути файлов, а не относительные. Относительные применяются к текущей директории и туда всё и распаковывается. А вот полные пути... их тоже наверное можно сделать относительными посредством каких-нибудь опций распаковки, но я хз, не сталкивался.

"Уязвимости в cpio и libarchive"
Отправлено юникснуб , 12-Ноя-19 16:41 
Блин, люди, у вас документация по любой команде за несколько секунд доступна! Не надо бегать по этажам и писать запросы; не надо оформлять читательские билеты; не надо шариться по книжным рынкам... Всё на блюдечке, просто набрать "man foo" или хотя бы в гугле строчку вбить! Но - нет, мы будем избегать любой ценой полезной информации, вместо этого переливая из пустого в порожнее на форуме.

Господь, если ты есть, - жги...


"Уязвимости в cpio и libarchive"
Отправлено Ordu , 12-Ноя-19 21:01 
> Блин, люди, у вас документация по любой команде за несколько секунд доступна!
> Не надо бегать по этажам и писать запросы; не надо оформлять
> читательские билеты; не надо шариться по книжным рынкам... Всё на блюдечке,
> просто набрать "man foo" или хотя бы в гугле строчку вбить!
> Но - нет, мы будем избегать любой ценой полезной информации, вместо
> этого переливая из пустого в порожнее на форуме.

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