Bug 19351 - libarchive new security issue CVE-2016-5418
Summary: libarchive new security issue CVE-2016-5418
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: Security (show other bugs)
Version: 5
Hardware: All Linux
Priority: Normal critical
Target Milestone: ---
Assignee: QA Team
QA Contact: Sec team
URL: http://lwn.net/Vulnerabilities/700519/
Whiteboard: has_procedure MGA5-64-OK MGA5-32-OK
Keywords: validated_update
: 19606 (view as bug list)
Depends on:
Blocks:
 
Reported: 2016-09-13 22:00 CEST by David Walser
Modified: 2016-10-18 20:52 CEST (History)
9 users (show)

See Also:
Source RPM: libarchive-3.2.1-1.mga5.src.rpm
CVE:
Status comment:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Description David Walser 2016-09-13 22:00:30 CEST 
RedHat has issued an advisory on September 12:
https://rhn.redhat.com/errata/RHSA-2016-1844.html

The patches they added are these two:
https://git.centos.org/raw/rpms!libarchive.git/9952851f8b327a8c93d26a5873c190c1fb09ae6c/SOURCES!libarchive-3.1.2-CVE-2016-5418-variation.patch
https://git.centos.org/raw/rpms!libarchive.git/9952851f8b327a8c93d26a5873c190c1fb09ae6c/SOURCES!libarchive-3.1.2-CVE-2016-5418.patch

Those would need to be rediffed to be used with 3.2.1.  Hopefully there are upstream commits with these fixes as well.

In fact, it looks like the commits from September 11 may be what we need:
https://github.com/libarchive/libarchive/commits/master
David Walser 2016-09-13 22:01:03 CEST

CC: (none) => nicolas.salguero, rverschelde
Whiteboard: (none) => MGA5TOO

Comment 1 Marja Van Waes 2016-09-14 08:39:18 CEST 
Assigning to all packagers collectively, since there is no registered maintainer for this package.

CC: (none) => fundawang, marja11, thierry.vignaud
Assignee: bugsquad => pkg-bugs

Comment 2 Nicolas Salguero 2016-09-15 11:28:39 CEST 
Hi,

A commit (on Aug 10, 2016) for issue #744 was already added in Cauldron.

When looking at the commits, I found some other ones that might be related to security as well:
- Commits on Aug 21, 2016:
  - Issue #770: Be more careful about extra_length
  - Issue #767: Buffer overflow printing a filename
- Commits on Aug 22, 2016:
  - Issue #748: Zip decompression failure with highly-compressed data
  - Issue #744 (part of Issue #743): Enforce sandbox with very long pathnames
  - Issue #731: Reject tar entries >= INT64_MAX

I added all those patches and the one for CVE-2016-5418 and libarchive built locally without any problem (on Mga5).  So, do I add all the patches on SVN for Cauldron and Mga5?

Best regards,

Nico.
Comment 3 David Walser 2016-09-15 15:11:19 CEST 
Please do, thanks.
Comment 4 Nicolas Salguero 2016-09-15 16:00:52 CEST 
Done for Cauldron and Mga5, then.

Suggested advisory:
========================

The updated packages fix several security vulnerabilities:

A flaw was found in the way libarchive handled hardlink archive entries of
non-zero size. Combined with flaws in libarchive's file system sandboxing, this
issue could cause an application using libarchive to overwrite arbitrary files
with arbitrary data from the archive. (CVE-2016-5418, issues #745 and #746)

Very long pathnames evade symlink checks (issue#744)

size_t underflow leading to out of bounds heap read in process_extra() / archive_read_support_format_zip.c (issue#770)

stack-based buffer overflow in bsdtar_expand_char (util.c) (issue#767)

libarchive can compress, but cannot decompress zip some files (issue#748)

hang in tar parser (issue#731)

References:
https://rhn.redhat.com/errata/RHSA-2016-1844.html
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-5418
https://github.com/libarchive/libarchive/issues/745
https://github.com/libarchive/libarchive/issues/746
https://github.com/libarchive/libarchive/issues/744
https://github.com/libarchive/libarchive/issues/770
https://github.com/libarchive/libarchive/issues/767
https://github.com/libarchive/libarchive/issues/748
https://github.com/libarchive/libarchive/issues/731
========================

Updated packages in core/updates_testing:
========================
i586:
libarchive13-3.2.1-1.1.mga5.i586.rpm
libarchive-devel-3.2.1-1.1.mga5.i586.rpm
bsdcat-3.2.1-1.1.mga5.i586.rpm
bsdcpio-3.2.1-1.1.mga5.i586.rpm
bsdtar-3.2.1-1.1.mga5.i586.rpm

x86_64:
lib64archive13-3.2.1-1.1.mga5.x86_64.rpm
lib64archive-devel-3.2.1-1.1.mga5.x86_64.rpm
bsdcat-3.2.1-1.1.mga5.x86_64.rpm
bsdcpio-3.2.1-1.1.mga5.x86_64.rpm
bsdtar-3.2.1-1.1.mga5.x86_64.rpm

Source RPMs:
libarchive-3.2.1-1.1.mga5.src.rpm

========================

Procedure: https://bugs.mageia.org/show_bug.cgi?id=9671#c2

Status: NEW => ASSIGNED
Version: Cauldron => 5
Assignee: pkg-bugs => qa-bugs
Whiteboard: MGA5TOO => (none)

Nicolas Salguero 2016-09-16 09:31:08 CEST

Whiteboard: (none) => has_procedure

Comment 5 Brian Rockwell 2016-09-17 15:38:10 CEST 
mga5-32


$ ls *.JPG | bsdcpio -ov > jpegs.cpio
100_0764.JPG
100_0765.JPG
100_0766.JPG
100_0767.JPG
100_0768.JPG
100_0769.JPG
100_0770.JPG
100_0771.JPG
100_0772.JPG
100_0773.JPG
100_0774.JPG
21188 blocks

$ bsdcpio -it < jpegs.cpio
100_0764.JPG
100_0765.JPG
100_0766.JPG
100_0767.JPG
100_0768.JPG
100_0769.JPG
100_0770.JPG
100_0771.JPG
100_0772.JPG
100_0773.JPG
100_0774.JPG
21188 blocks


[brian@localhost 2006-03-26]$ cd ../../tmp
[brian@localhost tmp]$ cpio -iv < ~/Pictures/2006-03-26/jpegs.cpio
100_0764.JPG
100_0765.JPG
100_0766.JPG
100_0767.JPG
100_0768.JPG
100_0769.JPG
100_0770.JPG
100_0771.JPG
100_0772.JPG
100_0773.JPG
100_0774.JPG
21188 blocks

I pulled up a couple of the pictures - they are displayable with no errors.

[brian@localhost tmp]$ bsdtar cJf tarfile.tar.xz *.JPG
[brian@localhost tmp]$ ls
100_0764.JPG  100_0767.JPG  100_0770.JPG  100_0773.JPG
100_0765.JPG  100_0768.JPG  100_0771.JPG  100_0774.JPG
100_0766.JPG  100_0769.JPG  100_0772.JPG  tarfile.tar.xz

[brian@localhost tmp]$ rm *.JPG
rm: remove write-protected regular file â100_0771.JPGâ? y
[brian@localhost tmp]$ ls
tarfile.tar.xz
[brian@localhost tmp]$

---note I didn't use -f so had to answer Y a lot.  This is expected

[brian@localhost tmp]$ bsdtar xJf tarfile.tar.xz
[brian@localhost tmp]$ ls
100_0764.JPG  100_0767.JPG  100_0770.JPG  100_0773.JPG
100_0765.JPG  100_0768.JPG  100_0771.JPG  100_0774.JPG
100_0766.JPG  100_0769.JPG  100_0772.JPG  tarfile.tar.xz
[brian@localhost tmp]$ 

I was able to view the pictures without errors.

CC: (none) => brtians1
Whiteboard: has_procedure => has_procedure mga5-32-ok

Comment 6 Brian Rockwell 2016-09-17 15:40:23 CEST 
(In reply to Brian Rockwell from comment #5)
> mga5-32
> 
> 
> $ ls *.JPG | bsdcpio -ov > jpegs.cpio
> 100_0764.JPG
> 100_0765.JPG
> 100_0766.JPG
> 100_0767.JPG
> 100_0768.JPG
> 100_0769.JPG
> 100_0770.JPG
> 100_0771.JPG
> 100_0772.JPG
> 100_0773.JPG
> 100_0774.JPG
> 21188 blocks
> 
> $ bsdcpio -it < jpegs.cpio
> 100_0764.JPG
> 100_0765.JPG
> 100_0766.JPG
> 100_0767.JPG
> 100_0768.JPG
> 100_0769.JPG
> 100_0770.JPG
> 100_0771.JPG
> 100_0772.JPG
> 100_0773.JPG
> 100_0774.JPG
> 21188 blocks
> 
> 
> [brian@localhost 2006-03-26]$ cd ../../tmp
> [brian@localhost tmp]$ cpio -iv < ~/Pictures/2006-03-26/jpegs.cpio
> 100_0764.JPG
> 100_0765.JPG
> 100_0766.JPG
> 100_0767.JPG
> 100_0768.JPG
> 100_0769.JPG
> 100_0770.JPG
> 100_0771.JPG
> 100_0772.JPG
> 100_0773.JPG
> 100_0774.JPG
> 21188 blocks
> 
> I pulled up a couple of the pictures - they are displayable with no errors.
> 
> [brian@localhost tmp]$ bsdtar cJf tarfile.tar.xz *.JPG
> [brian@localhost tmp]$ ls
> 100_0764.JPG  100_0767.JPG  100_0770.JPG  100_0773.JPG
> 100_0765.JPG  100_0768.JPG  100_0771.JPG  100_0774.JPG
> 100_0766.JPG  100_0769.JPG  100_0772.JPG  tarfile.tar.xz
> 
> [brian@localhost tmp]$ rm *.JPG
> rm: remove write-protected regular file â100_0771.JPGâ? y
> [brian@localhost tmp]$ ls
> tarfile.tar.xz
> [brian@localhost tmp]$
> 
> ---note I didn't use -f so had to answer Y a lot.  This is expected
> 
> [brian@localhost tmp]$ bsdtar xJf tarfile.tar.xz
> [brian@localhost tmp]$ ls
> 100_0764.JPG  100_0767.JPG  100_0770.JPG  100_0773.JPG
> 100_0765.JPG  100_0768.JPG  100_0771.JPG  100_0774.JPG
> 100_0766.JPG  100_0769.JPG  100_0772.JPG  tarfile.tar.xz
> [brian@localhost tmp]$ 
> 
> I was able to view the pictures without errors.

FYI - Thanks Claire for the procedure!!!
Comment 7 Brian Rockwell 2016-09-17 17:41:26 CEST 
$ uname -a
Linux localhost 4.4.16-desktop-1.mga5 #1 SMP Tue Jul 26 09:23:40 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux


The following 5 packages are going to be installed:

- bsdcat-3.2.1-1.1.mga5.x86_64
- bsdcpio-3.2.1-1.1.mga5.x86_64
- bsdtar-3.2.1-1.1.mga5.x86_64
- lib64archive13-3.2.1-1.1.mga5.x86_64
- meta-task-5-28.1.mga5.noarch

168KB of additional disk space will be used.

424KB of packages will be retrieved.


$ ls *.JPG | bsdcpio -ov > jpegs.cpio
100_0775.JPG
100_0776.JPG
100_0777.JPG
100_0778.JPG
100_0779.JPG
100_0780.JPG
100_0781.JPG
100_0782.JPG
100_0783.JPG
100_0784.JPG
100_0785.JPG
100_0786.JPG
100_0787.JPG
100_0788.JPG
100_0789.JPG
100_0790.JPG
100_0791.JPG
100_0792.JPG
100_0793.JPG
100_0794.JPG
100_0795.JPG
100_0796.JPG
100_0797.JPG
100_0798.JPG
100_0799.JPG
100_0800.JPG
100_0801.JPG
100_0802.JPG
100_0803.JPG
100_0804.JPG
100_0805.JPG
100_0806.JPG
100_0807.JPG
100_0808.JPG
100_0809.JPG
100_0810.JPG
100_0811.JPG
100_0812.JPG
100_0813.JPG
100_0814.JPG
100_0815.JPG
100_0816.JPG
100_0817.JPG
100_0818.JPG
100_0819.JPG
100_0820.JPG
100_0821.JPG
100_0822.JPG
100_0823.JPG
100_0824.JPG
100_0825.JPG
100_0826.JPG
100_0827.JPG
100_0828.JPG
100_0829.JPG
100_0830.JPG
100_0831.JPG
100_0832.JPG
100_0833.JPG
100_0834.JPG
100_0835.JPG
100_0836.JPG
100_0837.JPG
100_0838.JPG
100_0839.JPG
100_0840.JPG
100_0841.JPG
100_0842.JPG
100_0843.JPG
100_0844.JPG
100_0845.JPG
100_0847.JPG
100_0848.JPG
100_0849.JPG
100_0850.JPG
104665 blocks

bsdcpio -it < jpegs.cpio
<blah blah blah>
104665 blocks

cpio -iv < ~/Pictures/2006-04-06/jpegs.cpio
100_0775.JPG
<blah blah blah>
104665 blocks

$ bsdtar cJf tarfile.tar.xz *.JPG

$ ls
100_0775.JPG  100_0791.JPG  100_0807.JPG  100_0823.JPG  100_0839.JPG
100_0776.JPG  100_0792.JPG  100_0808.JPG  100_0824.JPG  100_0840.JPG
100_0777.JPG  100_0793.JPG  100_0809.JPG  100_0825.JPG  100_0841.JPG
100_0778.JPG  100_0794.JPG  100_0810.JPG  100_0826.JPG  100_0842.JPG
100_0779.JPG  100_0795.JPG  100_0811.JPG  100_0827.JPG  100_0843.JPG
100_0780.JPG  100_0796.JPG  100_0812.JPG  100_0828.JPG  100_0844.JPG
100_0781.JPG  100_0797.JPG  100_0813.JPG  100_0829.JPG  100_0845.JPG
100_0782.JPG  100_0798.JPG  100_0814.JPG  100_0830.JPG  100_0847.JPG
100_0783.JPG  100_0799.JPG  100_0815.JPG  100_0831.JPG  100_0848.JPG
100_0784.JPG  100_0800.JPG  100_0816.JPG  100_0832.JPG  100_0849.JPG
100_0785.JPG  100_0801.JPG  100_0817.JPG  100_0833.JPG  100_0850.JPG
100_0786.JPG  100_0802.JPG  100_0818.JPG  100_0834.JPG  tarfile.tar.xz
100_0787.JPG  100_0803.JPG  100_0819.JPG  100_0835.JPG
100_0788.JPG  100_0804.JPG  100_0820.JPG  100_0836.JPG
100_0789.JPG  100_0805.JPG  100_0821.JPG  100_0837.JPG
100_0790.JPG  100_0806.JPG  100_0822.JPG  100_0838.JPG

$ rm -f *.JPG
$ ls
tarfile.tar.xz
$ bsdtar xJf tarfile.tar.xz
$ ls
100_0775.JPG  100_0791.JPG  100_0807.JPG  100_0823.JPG  100_0839.JPG
100_0776.JPG  100_0792.JPG  100_0808.JPG  100_0824.JPG  100_0840.JPG
100_0777.JPG  100_0793.JPG  100_0809.JPG  100_0825.JPG  100_0841.JPG
100_0778.JPG  100_0794.JPG  100_0810.JPG  100_0826.JPG  100_0842.JPG
100_0779.JPG  100_0795.JPG  100_0811.JPG  100_0827.JPG  100_0843.JPG
100_0780.JPG  100_0796.JPG  100_0812.JPG  100_0828.JPG  100_0844.JPG
100_0781.JPG  100_0797.JPG  100_0813.JPG  100_0829.JPG  100_0845.JPG
100_0782.JPG  100_0798.JPG  100_0814.JPG  100_0830.JPG  100_0847.JPG
100_0783.JPG  100_0799.JPG  100_0815.JPG  100_0831.JPG  100_0848.JPG
100_0784.JPG  100_0800.JPG  100_0816.JPG  100_0832.JPG  100_0849.JPG
100_0785.JPG  100_0801.JPG  100_0817.JPG  100_0833.JPG  100_0850.JPG
100_0786.JPG  100_0802.JPG  100_0818.JPG  100_0834.JPG  tarfile.tar.xz
100_0787.JPG  100_0803.JPG  100_0819.JPG  100_0835.JPG
100_0788.JPG  100_0804.JPG  100_0820.JPG  100_0836.JPG
100_0789.JPG  100_0805.JPG  100_0821.JPG  100_0837.JPG
100_0790.JPG  100_0806.JPG  100_0822.JPG  100_0838.JPG

confirmed pictures are viewable

Whiteboard: has_procedure mga5-32-ok => has_procedure mga5-32-ok mga5-64-ok

Brian Rockwell 2016-09-17 17:43:20 CEST

Keywords: (none) => validated_update
CC: (none) => sysadmin-bugs

Comment 8 Lewis Smith 2016-09-18 11:31:52 CEST 
Ah, it does not look as if 'bsdcat' was tested. This is essentially the same as zcat. It only (?) seems to apply to *.gz compressed character files. The man page is vague: "expand files to standard output", but the only examples show .gz . I tried it on a zipped character file, and only got rubbish.
Ark uses lib[64]archive13.

Testing 'bsdcat' & Ark on M5 x64, Mate desktop.

BEFORE update: bsdtar-3.2.1-1.mga5 bsdcpio-3.2.1-1.mga5 bsdcat-3.2.1-1.mga5
lib64archive13-3.2.1-1.mga5
Played with Ark on various archives (open only), tried bsdcat. No problems.

AFTER update to version 3.2.1-1.1:
Tried Ark (open only) on a huge variety of archives: tar.xz, 7z, tar, tar.bz2, tar.gz, zip, iso, rpm, deb, cpio; all opened OK, including archives within archives.

I found an obscure and trivial Ark bug whereby if it has opened a compressed archive within a deb file, it continues to work OK, but crashes when you eventually exit. Specifically tried: deb/tar.gz, deb/tar.xz . I cannot confirm this before update, and it does not warrant stopping the update. A new bug perhaps.

For bsdcat, where poedit.po is a large text file:
 $ cp poedit.po poedit2.po        [because gzip ovewrites the original]
 $ gzip poedit2.po                [creates poedit2.po.gz]
 $ bsdcat poedit2.po.gz > popo2   [popo2 should be the same as the original]
 $ diff poedit.po popo2           [no difference]
 
which is OK.

CC: (none) => lewyssmith

Comment 9 Lewis Smith 2016-09-18 11:42:53 CEST 
Advisory uploaded.

Whiteboard: has_procedure mga5-32-ok mga5-64-ok => has_procedure mga5-32-ok mga5-64-ok advisory

Comment 10 David Walser 2016-09-19 18:39:22 CEST 
Nicolas, there are a few more security-related commits in git now from September 18, and now there's a post saying all issues have been fixed:
http://openwall.com/lists/oss-security/2016/09/19/2

Could you include those additional commits and resubmit this?
Comment 11 David Walser 2016-09-19 18:43:00 CEST 
Also, the original CVE issue had to do with hardlinks, so at this commit from September 11 which you didn't already include may be security-related:
https://github.com/libarchive/libarchive/commit/9f0dee226163de2490510fd258fbd9547a032f16
Comment 12 Nicolas Salguero 2016-09-20 09:48:55 CEST 
I added the 3 commits in Cauldron and Mga5.

Updated packages in core/updates_testing:
========================
i586:
libarchive13-3.2.1-1.2.mga5.i586.rpm
libarchive-devel-3.2.1-1.2.mga5.i586.rpm
bsdcat-3.2.1-1.2.mga5.i586.rpm
bsdcpio-3.2.1-1.2.mga5.i586.rpm
bsdtar-3.2.1-1.2.mga5.i586.rpm

x86_64:
lib64archive13-3.2.1-1.2.mga5.x86_64.rpm
lib64archive-devel-3.2.1-1.2.mga5.x86_64.rpm
bsdcat-3.2.1-1.2.mga5.x86_64.rpm
bsdcpio-3.2.1-1.2.mga5.x86_64.rpm
bsdtar-3.2.1-1.2.mga5.x86_64.rpm

Source RPMs:
libarchive-3.2.1-1.2.mga5.src.rpm
Comment 13 Nicolas Salguero 2016-09-20 09:57:43 CEST 
We should also add to the advisory:

Out of bounds read in mtree parser (issue#747)

heap-based buffer overflow in read_Header (archive_read_support_format_7zip.c) (issue#761)
Comment 14 David Walser 2016-09-20 15:44:03 CEST 
Back to QA for a little more testing (please add the advisory bits from Comment 13 in SVN also).

Keywords: validated_update => (none)
Whiteboard: has_procedure mga5-32-ok mga5-64-ok advisory => has_procedure

Comment 15 Lewis Smith 2016-09-24 10:43:09 CEST 
Testing M5 x64 with:
Comment 16 Lewis Smith 2016-09-24 10:46:53 CEST 
Testing M5 x64 with:
 bsdcat-3.2.1-1.2.mga5
 bsdcpio-3.2.1-1.2.mga5
 bsdtar-3.2.1-1.2.mga5
 lib64archive13-3.2.1-1.2.mga5

bsdcat
------
$ cp poedit.po poedit2.po
$ gzip poedit2.po
$ bsdcat poedit2.po.gz > popo2
$ diff poedit.po popo2
$ cmp poedit.po popo2
Comment 17 Lewis Smith 2016-09-24 11:46:47 CEST 
continued...[this is getting on my nerves]
[poedit.po is a large text file]
The 'diff' & 'cmp' above show that the O/P of the gz file from bsdcat is identical to the original uncompressed file.
 $ rm poedit2.po.gz        [remove the working duplicate]
 $ rm popo2                [& this]
OK.

I used Ark to inspect archives produced by bsdcpio & bsdtar, thus testing it (lib64archive13) also. This included looking directly at individual viewable files.

bsdcpio
-------
Extract/List an existing cpio archive:
 $ bsdcpio -itv < /mnt/common/finance/cyfrifon.cpio
 -rwxrwxrwx   1 root     root        21868 Aws 23  2001 arian00.mm4
etc etc. O/P correct.

Extract/List an existing tar archive:
 $ bsdcpio -itv < bsdtar.tar
 drwx------   0 lewis    lewis           0 Med 24 09:35 mnt/common/tmp/
 -rw-r--r--   0 lewis    lewis       27093 Gor 30 20:51 mnt/common/tmp/megabusLimLon.png
 drwxr-xr-x   0 lewis    lewis           0 Ion  3  2016 mnt/common/tmp/ISIS/
etc etc. Looks OK.

Create an archive:
 $ find /mnt/common/tmp/ | bsdcpio -ov > bsdcpio.cpio
 /mnt/common/tmp/
 /mnt/common/tmp/megabusLimLon.png
 /mnt/common/tmp/ISIS
etc etc.
Archives such as this with absolute pathnames (/...) curiously are *not* handled by Ark. So try again:
 $ cd /mnt/common/tmp/
 $ find . | bsdcpio -ov > ~/tmp/bsdcpio.cpio
 .
 ./megabusLimLon.png
 ./ISIS
etc etc. Confirmed OK with Ark.

Read an archive:
 $ bsdcpio -itv -F ~/tmp/bsdcpio.cpio 
 drwx------   3 lewis    lewis           0 Med 24 09:35 .
 -rw-r--r--   1 lewis    lewis       27093 Gor 30 20:51 ./megabusLimLon.png
 drwxr-xr-x   2 lewis    lewis           0 Ion  3  2016 ./ISIS
etc etc. OK.
 $ rm ~/tmp/bsdcpio.cpio       [Remove this]

bsdtar
------
Create a straight 'tar' archive:
 $ bsdtar -cf tmp/bsdtar.tar /mnt/common/tmp/
 bsdtar: Removing leading '/' from member names
Result OK with Ark.

Create a 'bzip2' archive:
 $ bsdtar -cjf tmp/bsdtar.tar.bz2 /mnt/common/tmp/
 bsdtar: Removing leading '/' from member names
Result OK with Ark.

Create an 'xz' archive:
 $ bsdtar -cJf tmp/bsdtar.tar.xz /mnt/common/tmp/
 bsdtar: lzma compression failed: lzma_code() call returned status 11
This failure only occured once, thereafter the same thing worked:
 $ bsdtar -cJf tmp/bsdtar.tar.xz /mnt/common/tmp/
 bsdtar: Removing leading '/' from member names

Read a 'tar' archive:
 $ bsdtar -tvf bsdtar.tar
 drwx------  0 lewis  lewis       0 Med 24 09:35 mnt/common/tmp/
 -rw-r--r--  0 lewis  lewis   27093 Gor 30 20:51 mnt/common/tmp/megabusLimLon.png
 drwxr-xr-x  0 lewis  lewis       0 Ion  3  2016 mnt/common/tmp/ISIS/
etc etc. OK.

Read a 'bzip2' archive:
 $ bsdtar -tvf bsdtar.tar.bz2
 drwx------  0 lewis  lewis       0 Med 24 09:35 mnt/common/tmp/
 -rw-r--r--  0 lewis  lewis   27093 Gor 30 20:51 mnt/common/tmp/megabusLimLon.png
 drwxr-xr-x  0 lewis  lewis       0 Ion  3  2016 mnt/common/tmp/ISIS/
etc etc. OK.

Read an 'xz' archive:
 $ bsdtar -tvf bsdtar.tar.xz
 drwx------  0 lewis  lewis       0 Med 24 09:35 mnt/common/tmp/
 -rw-r--r--  0 lewis  lewis   27093 Gor 30 20:51 mnt/common/tmp/megabusLimLon.png
 drwxr-xr-x  0 lewis  lewis       0 Ion  3  2016 mnt/common/tmp/ISIS/
etc etc. OK.

Ark/lib64archive13-3.2.1-1.2
----------------------------
Used Ark to open and probe a large variety of archives, including nested ones, and viewing directly suitable (image, PDF, text) individual files therein.
iso, zip/iso, tar.bz2, deb/tar.gz, tar, zip, tar.gz, rpm, deb/tar.xz/gz, 7z.
The very obscure & trivial bug noted in Comment 8 is still there; forget it; and the dislike of absolute pathnames in some archives, which is its normal behaviour.
All round this is impressive and OK.

Whiteboard: has_procedure => has_procedure MGA5-64-OK

Comment 18 Brian Rockwell 2016-09-25 00:11:29 CEST 
Linux localhost 4.4.16-desktop-1.mga5 #1 SMP Tue Jul 26 10:34:04 UTC 2016 i686 i686 i686 GNU/Linux


The following 4 packages are going to be installed:

- bsdcat-3.2.1-1.2.mga5.i586
- bsdcpio-3.2.1-1.2.mga5.i586
- bsdtar-3.2.1-1.2.mga5.i586
- libarchive13-3.2.1-1.2.mga5.i586

4B of disk space will be freed.

440KB of packages will be retrieved.


$ ls -1 *.JPG | wc -l
24


$ ls *.JPG | bsdcpio -ov > jpegs.cpio
24 loaded
223383 blocks

$ bsdcpio -it < jpegs.cpio | wc -l
223383 blocks
24

$ cpio -iv < ../jpegs.cpio 
Roll1_A114562-R1-00-1A.JPG
Roll1_A114562-R1-01-2A.JPG
Roll1_A114562-R1-02-3A.JPG
Roll1_A114562-R1-03-4A.JPG
Roll1_A114562-R1-04-5A.JPG
Roll1_A114562-R1-05-6A.JPG
Roll1_A114562-R1-06-7A.JPG
Roll1_A114562-R1-07-8A.JPG
Roll1_A114562-R1-08-9A.JPG
Roll1_A114562-R1-09-10A.JPG
Roll1_A114562-R1-10-11A.JPG
Roll1_A114562-R1-11-12A.JPG
Roll1_A114562-R1-12-13A.JPG
Roll1_A114562-R1-13-14A.JPG
Roll1_A114562-R1-14-15A.JPG
Roll1_A114562-R1-15-16A.JPG
Roll1_A114562-R1-16-17A.JPG
Roll1_A114562-R1-17-18A.JPG
Roll1_A114562-R1-18-19A.JPG
Roll1_A114562-R1-19-20A.JPG
Roll1_A114562-R1-20-21A.JPG
Roll1_A114562-R1-21-22A.JPG
Roll1_A114562-R1-22-23A.JPG
Roll1_A114562-R1-23-24A.JPG
223383 blocks

$ ls -1 *.JPG | wc -l
24

$ bsdtar cJf tarfile.tar.xz *.JPG
$ ls
Roll1_A114562-R1-00-1A.JPG   Roll1_A114562-R1-13-14A.JPG
Roll1_A114562-R1-01-2A.JPG   Roll1_A114562-R1-14-15A.JPG
Roll1_A114562-R1-02-3A.JPG   Roll1_A114562-R1-15-16A.JPG
Roll1_A114562-R1-03-4A.JPG   Roll1_A114562-R1-16-17A.JPG
Roll1_A114562-R1-04-5A.JPG   Roll1_A114562-R1-17-18A.JPG
Roll1_A114562-R1-05-6A.JPG   Roll1_A114562-R1-18-19A.JPG
Roll1_A114562-R1-06-7A.JPG   Roll1_A114562-R1-19-20A.JPG
Roll1_A114562-R1-07-8A.JPG   Roll1_A114562-R1-20-21A.JPG
Roll1_A114562-R1-08-9A.JPG   Roll1_A114562-R1-21-22A.JPG
Roll1_A114562-R1-09-10A.JPG  Roll1_A114562-R1-22-23A.JPG
Roll1_A114562-R1-10-11A.JPG  Roll1_A114562-R1-23-24A.JPG
Roll1_A114562-R1-11-12A.JPG  tarfile.tar.xz
Roll1_A114562-R1-12-13A.JPG

$ rm -f *.JPG
$ ls
tarfile.tar.xz
$ ls
Roll1_A114562-R1-00-1A.JPG   Roll1_A114562-R1-13-14A.JPG
Roll1_A114562-R1-01-2A.JPG   Roll1_A114562-R1-14-15A.JPG
Roll1_A114562-R1-02-3A.JPG   Roll1_A114562-R1-15-16A.JPG
Roll1_A114562-R1-03-4A.JPG   Roll1_A114562-R1-16-17A.JPG
Roll1_A114562-R1-04-5A.JPG   Roll1_A114562-R1-17-18A.JPG
Roll1_A114562-R1-05-6A.JPG   Roll1_A114562-R1-18-19A.JPG
Roll1_A114562-R1-06-7A.JPG   Roll1_A114562-R1-19-20A.JPG
Roll1_A114562-R1-07-8A.JPG   Roll1_A114562-R1-20-21A.JPG
Roll1_A114562-R1-08-9A.JPG   Roll1_A114562-R1-21-22A.JPG
Roll1_A114562-R1-09-10A.JPG  Roll1_A114562-R1-22-23A.JPG
Roll1_A114562-R1-10-11A.JPG  Roll1_A114562-R1-23-24A.JPG
Roll1_A114562-R1-11-12A.JPG  tarfile.tar.xz
Roll1_A114562-R1-12-13A.JPG

confirmed pictures are viewable

Whiteboard: has_procedure MGA5-64-OK => has_procedure MGA5-64-OK MGA5-32-OK

Brian Rockwell 2016-09-25 00:12:14 CEST

Keywords: (none) => validated_update

Comment 19 Nicolas Lécureuil 2016-09-25 13:32:47 CEST 
Update ID assignment failed

Checking for QA validation keyword⦠  â
Checking dependent bugs⦠             â (None found)
Checking SRPMs⦠                      â (5/core/libarchive-3.2.1-1.1.mga5) 


'validated_update' keyword reset.

Keywords: validated_update => (none)

Comment 20 Nicolas Lécureuil 2016-09-25 13:34:37 CEST 
src is libarchive-3.2.1-1.2.mga5.src.rpm

Keywords: (none) => validated_update
CC: (none) => mageia

Comment 21 Mageia Robot 2016-09-25 13:42:25 CEST 
An update for this issue has been pushed to the Mageia Updates repository.

http://advisories.mageia.org/MGASA-2016-0318.html

Status: ASSIGNED => RESOLVED
Resolution: (none) => FIXED

Comment 22 David Walser 2016-09-25 17:27:56 CEST 
Thanks for pushing this, but the reason the SRPM was wrong (and this is usually the case when this happens) is the build was updated, and the advisory text was updated.  The additional text from Comment 13 should have been added to the advisory in SVN and wasn't.  Please add it.  Something similar happened with the mariadb update recently when someone failed to update the advisory text in SVN.
Comment 23 Nicolas Lécureuil 2016-09-25 19:02:33 CEST 
ok done.
Comment 24 Lewis Smith 2016-09-26 21:28:32 CEST 
(In reply to David Walser from comment #22)
> Thanks for pushing this, but the reason the SRPM was wrong (and this is
> usually the case when this happens) is the build was updated, and the
> advisory text was updated.  The additional text from Comment 13 should have
> been added to the advisory in SVN and wasn't.  Please add it.

(In reply to Nicolas Lécureuil from comment #23)
> ok done.

I did the original advisory, and was ready to do the updates to it mentioned in Comment 13 once this update got validated 2nd time round (& I had the time). Nicolas L kindly jumped in ahead of me; it was not forgotten.
Comment 25 David Walser 2016-10-17 12:25:10 CEST 
(In reply to David Walser from comment #10)
> Nicolas, there are a few more security-related commits in git now from
> September 18, and now there's a post saying all issues have been fixed:
> http://openwall.com/lists/oss-security/2016/09/19/2

  - CVE-2016-8687 is Issue #767
  - CVE-2016-8688 is Issue #747
  - CVE-2016-8689 is Issue #761

http://openwall.com/lists/oss-security/2016/10/16/11
Comment 26 David Walser 2016-10-17 12:26:11 CEST 
*** Bug 19606 has been marked as a duplicate of this bug. ***
Comment 27 David Walser 2016-10-18 20:52:52 CEST 
(In reply to David Walser from comment #25)
> (In reply to David Walser from comment #10)
> > Nicolas, there are a few more security-related commits in git now from
> > September 18, and now there's a post saying all issues have been fixed:
> > http://openwall.com/lists/oss-security/2016/09/19/2
> 
>   - CVE-2016-8687 is Issue #767
>   - CVE-2016-8688 is Issue #747
>   - CVE-2016-8689 is Issue #761
> 
> http://openwall.com/lists/oss-security/2016/10/16/11

LWN reference:
http://lwn.net/Vulnerabilities/703866/
Note You need to log in before you can comment on or make changes to this bug.