Georg, Any idea when that will hit the TW repos? Thanks! Joe

Hi Georg, Would you take lack of response you and I got regarding if there were plans to move the newer 7zip to factory because 1) There are no plans (hope this is not the case) 2) People are really busy or already away/off for the holidays? Thanks!

Hi Georg, Great news, thanks so much for the update! Happy Holidays to you! Joe

On Tuesday 2021-12-21 11:35, Danilo Spinella wrote:

2) 7zip source code is archived in its own format, which means that p7zip is required to extract it or there should be a dependency to itself. I could tarball the code myself, but I would prefer if there was an official tarball provided.

One has to determine whether the security impact of an old p7zip is worse than recompressing the source.. and I would expect to see the second option is the lesser problem.

Hi Georg, thanks for the detailed response! On Tue, 2021-12-21 at 21:42 +0100, Georg Pfuetzenreuter wrote:

Hi Danilo,

thanks a lot for getting back!

1) It looks like p7zip is very wide spread - there might be other software or scripts depending on it. From a quick glance at the %files, the two packages don't seem conflict which each other - do they? I am not sure what SUSE's policy is about phasing out old packages, but possibly a deprecation note could be added instead of directly removing it?

Quoting Joe from another mail in this thread so that we have all the information in one place:

The pk7zip package creates /usr/bin/7z, /usr/bin/7za, and /usr/bin/7zr where are 1 line shell scripts which just run /usr/lib64/p7zip/7z.

The executable (binary) is named 7zz which I believe was done to avoid conflict with pk7ip which is most likely already installed.

Indeed, there is no conflict between them, but since they have the same command line interface, I think there is no reason to have them both. Replacing p7zip with 7zip is straightforward, I can create a symlink from 7zz to 7z and manually include 7za and 7zr.

2) I agree with you that repacking the sources is not ideal - but I also agree with Jan that keeping p7zip as a dependency could become a security concern. Someone seems to have picked up on this issue and releases the sources unofficially via Git https://github.com/kornelski/7z - however it being a third party source could make for some trust issues. Is it possible to trust the integrity of those sources? If not, what about keeping p7zip as a BuildDependency only? If p7zip is being phased out however, the latter could become an issue - and I can only come up with very hacky solutions, such as providing the binary .tar.xz release as an additional source to then use the binary to decompress the sources as part of the %prep - yes, writing that gave me a headache. :-)

Someone saved the day by pointing out that bsdtar can extract 7z archives; I think this solves it. https://github.com/justdan96/7zip_static/issues/1#issuecomment-999192941

Best, Georg

On 12/21/21 11:35, Danilo Spinella wrote:

...

Hello Georg, Joe, sorry for the late reply.

There are two reasons why 7zip hasn't been pushed to Factory yet:

1) Since it's the same as p7zip, I thought that having the same program in different packages wouldn't make sense. I wasn't aware that p7zip hasn't been updated in years. In my opinion, the best course of action is replacing p7zip with 7zip.

2) 7zip source code is archived in its own format, which means that p7zip is required to extract it or there should be a dependency to itself. I could tarball the code myself, but I would prefer if there was an official tarball provided.

I'd like to hear your opinion on this matter, but if there was an agreement, there would be no problem for me to adjust the specfile and push it to Factory.

-- Best Regards, Danilo Spinella

From the Arch Linux wiki: * 7z(1) uses plugins to handle archives. * 7za(1) is a stand-alone executable that handles fewer archive formats than 7z. * 7zr(1) is a stand-alone executable. It is a "light-version" of 7za that only handles 7z archives. In contrast to 7za, it cannot handle encrypted archives. https://wiki.archlinux.org/title/p7zip#Differences_between_7z.2C_7za_and_7zr... I am not sure that 7za and 7zr can be symlinked to 7z at this point. p7zip also provides a gzip-like script installed in /usr/bin/p7zip, so I don't think p7zip package can be removed entirely. There is also a library 7z.so provided by p7zip, but, according to [1], it's used for non-free rar code. [1]: https://sourceforge.net/p/sevenzip/discussion/45797/thread/df012dffa9/#4e9b/... On Wed, 2021-12-22 at 10:51 +0100, Georg Pfuetzenreuter wrote:

Amazing - bsdtar being able to extract .7z is handy to know and good news! Thanks a lot for your work!

Best, Georg

On 12/22/21 10:42, Danilo Spinella wrote:

...

Hi Georg,

thanks for the detailed response!

On Tue, 2021-12-21 at 21:42 +0100, Georg Pfuetzenreuter wrote:

...

Hi Danilo,

thanks a lot for getting back!

1) It looks like p7zip is very wide spread - there might be other software or scripts depending on it. From a quick glance at the %files, the two packages don't seem conflict which each other - do they? I am not sure what SUSE's policy is about phasing out old packages, but possibly a deprecation note could be added instead of directly removing it?

Quoting Joe from another mail in this thread so that we have all the information in one place:

...

The pk7zip package creates /usr/bin/7z, /usr/bin/7za, and /usr/bin/7zr where are 1 line shell scripts which just run /usr/lib64/p7zip/7z.

...

The executable (binary) is named 7zz which I believe was done to avoid conflict with pk7ip which is most likely already installed.

Indeed, there is no conflict between them, but since they have the same command line interface, I think there is no reason to have them both. Replacing p7zip with 7zip is straightforward, I can create a symlink from 7zz to 7z and manually include 7za and 7zr.

...

2) I agree with you that repacking the sources is not ideal - but I also agree with Jan that keeping p7zip as a dependency could become a security concern. Someone seems to have picked up on this issue and releases the sources unofficially via Git https://github.com/kornelski/7z - however it being a third party source could make for some trust issues. Is it possible to trust the integrity of those sources? If not, what about keeping p7zip as a BuildDependency only? If p7zip is being phased out however, the latter could become an issue - and I can only come up with very hacky solutions, such as providing the binary .tar.xz release as an additional source to then use the binary to decompress the sources as part of the %prep - yes, writing that gave me a headache. :-)

Someone saved the day by pointing out that bsdtar can extract 7z archives; I think this solves it.

https://github.com/justdan96/7zip_static/issues/1#issuecomment-999192941

...

Best, Georg

On 12/21/21 11:35, Danilo Spinella wrote:

...

Hello Georg, Joe, sorry for the late reply.

There are two reasons why 7zip hasn't been pushed to Factory yet:

1) Since it's the same as p7zip, I thought that having the same program in different packages wouldn't make sense. I wasn't aware that p7zip hasn't been updated in years. In my opinion, the best course of action is replacing p7zip with 7zip.

2) 7zip source code is archived in its own format, which means that p7zip is required to extract it or there should be a dependency to itself. I could tarball the code myself, but I would prefer if there was an official tarball provided.

I'd like to hear your opinion on this matter, but if there was an agreement, there would be no problem for me to adjust the specfile and push it to Factory.

-- Best Regards, Danilo Spinella

Hi Danilo, Sorry I didn't mean to imply we should keep both, I was just letting you know I could not find any conflict between them so if there was a reason to keep the old version too it did not appear to be a problem. I agree though I think you should replace it and create the 7z symlink to 7zz. The 7zz source that I previously linked to did not include the 7za and 7zr files only 7zz. I expect that most people just use the main program and not those other two and doubt anymore would miss them (but I could be wrong :- ) Joe

Hi Danilo, Thanks for getting back to me. It is my understanding that p7zip was a fork of 7zip to provide a Linux version back in 2016. It has not been updated since then and is back at version 16.02. I agree with your suggestion to just replace p7zip with 7zip. I've been using 7zip on Windows for a long time and have not had any issues with backward compatibility. There was also some discussion on the 7zip website about getting the newer version into all the Linux distros. The pk7zip package creates /usr/bin/7z, /usr/bin/7za, and /usr/bin/7zr where are 1 line shell scripts which just run /usr/lib64/p7zip/7z. FWIW, I downloaded the x86-64 version from sourceforge https://sourceforge.net/p/sevenzip/discussion/45797/thread/cec5e63147/ And have been playing around with it to see if I ran into any issues (I haven't so far). That link also contains some of the discussion about the Linux version I mentioned above. The executable (binary) is named 7zz which I believe was done to avoid conflict with pk7ip which is most likely already installed. Hope that helps! Thanks! Have a great holiday! Joe