Danilo Spinella

Hello, is there any update on this CVE? Even though 7zip is now available on Linux, many people still uses p7zip so a fix would be helpful...

Hi! We at openSUSE also are experiencing similar errors when using FORTIFY_SOURCE=3. You can try by compiling zip using -DFORTIFY_SOURCE=3 and using the following command line: $ touch α.txt $ zip a.zip α.txt openSUSE bug for reference: https://bugzilla.suse.com/show_bug.cgi?id=1200712

Hi teoberi! As pointed in this GitHub comment, bsdtar is able to extract 7z archives, so this solve the self dependency problem. https://github.com/justdan96/7zip_static/issues/1#issuecomment-999192941 I also had the same problem as you about the unrar support; in the end I have written a small patch to avoid compiling unrar support: https://build.opensuse.org/package/view_file/Archiving/7zip/remove-rar-handler.patch?expand=1

Since p7zip hasn't been updated since 2016, I don't see any reason to keep it in openSUSE. 7zip has the same command line interface and it's the official program, I consider replacing p7zip entirely by 7zip a better solution overall.

Hi there! I am the current package maintainer for both 7zip and p7zip in openSUSE. Packages in RPM based distributions, such as openSUSE and Fedora, contain the source code archive and start building by unpacking it. 7zip source code is released as a 7z archive, which means that 7zip is required to build itself. This self dependency creates some problem, especially for building it on multiple architectures. Would it be possible to also release a tarball containing the source code? Thank you in advance...

Replace __always_inline with __attribute__