It was reported that file-roller will start eating CPU and the application will freeze if a crafted .zip file opened. Upstream bug report: https://bugzilla.gnome.org/show_bug.cgi?id=752245 There's not fix available yet.
Created file-roller tracking bugs for this issue: Affects: fedora-all [bug 1242486]
This has changed throughout versions. RHEL6: There's something that can become similar to an invinite loop in get_alternative_uri() function (the while loop). Apparently fixed via https://git.gnome.org/browse/file-roller/commit/src/file-utils.c?id=34b64f3a897c4b4e8e180c028f326bc921eb08ec RHEL7: This only crashed the very first time for me. It was a NULL-pointer dereference in fr_archive_create(): archive can be NULL after the call to create_archive_for_mime_type(), but this condition is never checked. > archive = create_archive_for_mime_type (archive_type, > file, > mime_type, > FR_ARCHIVE_CAN_WRITE); > > parent = g_file_get_parent (file); > archive->priv->have_write_permissions = _g_file_check_permissions > (parent, W_OK); Introduced via: https://git.gnome.org/browse/file-roller/commit/src/fr-archive.c?id=4b64c5ece7a4e209799b72845b1587d4b9323940 Fedora: It seems like the RHEL7 flaw is still in the code. But there's a new option to handle zips using libarchive, which probably hides the problem.
A zip file with a folder named "#" inside it can crash the file-roller utility. There is no indication that code execution is possible, so this should be limited to a crash only. If you encounter a crash and suspect that a "#" folder inside the zip file may be the culprit, refrain from opening the file again in file-roller. You can alternatively try to unpack the zip file using other zip decompression utilities.