"fr-archive-libarchive.c in GNOME file-roller through 3.36.1 allows Directory Traversal during extraction because it lacks a check of whether a file's parent is a symlink to a directory outside of the intended extraction location."
@maintainer(s), please create an appropriate ebuild if possible.
Given we are at 3.32.4 in tree, it's possible the vulnerable changes slipped in between now and 3.36.1.
This requires investigation (I will look into this, but maintainer knowledge may be needed).
My guess is that older are vulnerable, as there just was no symlink checking code before. file-roller-3.36 should be small enough change over 3.34 to worry about not being in sync with gnome 3.36, so I guess lets just stable it.
Note that other libarchive consumers may be vulnerable as well - mostly I'd suggest app-arch/engrampa would be, which I believe is a MATE fork of file-roller.
all arches done
Please cleanup, thanks!
New GLSA request filed.
This issue was resolved and addressed in
GLSA 202009-06 at https://security.gentoo.org/glsa/202009-06
by GLSA coordinator Thomas Deutschmann (whissi).
Re-opening for cleanup.
The bug has been referenced in the following commit(s):
Author: John Helmert III <firstname.lastname@example.org>
AuthorDate: 2020-12-27 09:45:02 +0000
Commit: Sam James <email@example.com>
CommitDate: 2020-12-29 01:59:59 +0000
app-arch/file-roller: security cleanup (drop <3.36.3)
Package-Manager: Portage-3.0.12, Repoman-3.0.2
Signed-off-by: John Helmert III <firstname.lastname@example.org>
Signed-off-by: Sam James <email@example.com>
app-arch/file-roller/Manifest | 1 -
app-arch/file-roller/file-roller-3.32.4.ebuild | 96 ----------------------
app-arch/file-roller/files/3.32-packages.match | 34 --------
.../files/file-roller-3.32.4-fno-common.patch | 27 ------
4 files changed, 158 deletions(-)
Tree is clean, all done!