Sadly, p7zip looks unmainaited upstream. So, I'd like to suggest some security patches from debian:
CVE-2017-17969
https://salsa.debian.org/debian/p7zip/commit/d6fd3b37345489ec2907fcf70aabf0c754f5371f
CVE-2018-5996
https://salsa.debian.org/debian/p7zip-rar/commit/6c08c0ee8ee45cd22146d06a10730181c1acb168
CVE-2018-10115
https://salsa.debian.org/debian/p7zip-rar/commit/cd8c3f633ea94b256fe108bf0b73176bcc0053c0
CVE-2018-5996 and CVE-2018-10115 are RAR related and could AFAIK also be fixed by building without RAR support (support unneeded due to unrar package).
What difference between p7zip and p7zip-rar?
could AFAIK also be fixed by building without RAR support (support unneeded due to unrar package)
Well, why don't we just ditch the whole p7zip package from our repo then, since libarchive/bsdtar apparently supports everything
What difference between p7zip and p7zip-rar?
p7zip-rar can't be used stand-alone, it provides just a module/library. Unrar has a license, that is unsuitable for some use cases. The p7zip-rar package is labeled non-free in debian. So users can opt for rar support (if needed).
Well, why don't we just ditch the whole p7zip package from our repo then, since libarchive/bsdtar apparently supports everything
I'm unsure, if there is really full support for native 7-zip compression and if so, for the various supported methods. It says "7-Zip (read only, starting in libarchive 3.0)".
https://github.com/libarchive/libarchive/wiki/LibarchiveFormats
It says "7-Zip (read only, starting in libarchive 3.0)".
bsdtar can create 7zip archives too. Just tried.
Archiving to 7z with bsdtar:
[~/test]:$ echo foo > myfile.txt
[~/test]:$ bsdtar -acvf my_7z_archive.7z myfile.txt
a myfile.txt
[~/test]:$ file my_7z_archive.7z
my_7z_archive.7z: 7-zip archive data, version 0.3
There just -a option which selects compression depending on file extension.
Extracting with p7zip (bsdtar can do this as well):
[~/test]:$ 7z x my_7z_archive.7z
7-Zip [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=utf8,Utf16=on,HugeFiles=on,64 bits,8 CPUs LE)
Scanning the drive for archives:
1 file, 154 bytes (1 KiB)
Extracting archive: my_7z_archive.7z
--
Path = my_7z_archive.7z
Type = 7z
Physical Size = 154
Headers Size = 140
Method = LZMA:23
Solid = -
Blocks = 1
Would you like to replace the existing file:
Path: ./myfile.txt
Size: 4 bytes (1 KiB)
Modified: 2019-03-05 22:36:39
with the file from archive:
Path: myfile.txt
Size: 4 bytes (1 KiB)
Modified: 2019-03-05 22:36:39
? (Y)es / (N)o / (A)lways / (S)kip all / A(u)to rename all / (Q)uit? y
Everything is Ok
Size: 4
Compressed: 154
https://github.com/libarchive/libarchive/wiki/LibarchiveFormats
libarchive wiki is outdated: amejia1 edited this page on 4 Feb 2012 · 2 revisions.
Had no luck with bsdtar and encrypted 7z archives:
7z a -t7z -mx=0 -mhe=on -p"password" test.7z [some_file]
Unpacking fails for me.
bsdtar does not support encrypted archives.
bsdtar: The archive header is encrypted, but currently not supported
It is unlikely that p7zip will get removed. There should not be any problem with patching. And I guess there fair amount of people using it. Package mc also use p7zip for working with 7z archives.
I may have a try.
I try to use debian salsa team of repo.
Shall I create a new package call p7zip-rar?
Fixed, now the packages (p7zip, p7zip-rar) build successfully. I want to test the packages. But you guys who know how to test the bug? Also, shell I add a new package call p7zip-rar? If not, I will find another way to build it with all format include rar.
I will upload the changes later. <= If the bug fixed.
Also, shell I add a new package call p7zip-rar
Our p7zip already built with rar support so p7zip-unrar will be useless.
./lib/p7zip/Codecs
./lib/p7zip/Codecs/Rar.so
I have uploaded. #3466
I don't know how to test the bug so I can't finish the test yet.
Also, shell I add a new package call p7zip-rar
Our p7zip already built with rar support so
p7zip-unrarwill be useless../lib/p7zip/Codecs ./lib/p7zip/Codecs/Rar.so
You can remove the p7zip-rar file.
The security problems may work out.
Why not to just apply security patches ?
That could update to newer patches easily.
The patches in the source debian/patches/
I found the official source of p7zip had no update => a looooog day ago.
Shall we remove the support of p7zip and delete it?
Shall we remove the support of p7zip and delete it?
A lot of people who use it will cry if we remove p7zip package.
I guess we may just throw away rar support as it is replaced by unrar which is the official unarchiver for RAR.
Ok, I just put the secure patches to it.
I may have a try.
Shall I patch the mc to remove the p7zip support?
Shall I patch the mc to remove the p7zip support?
No, left it as-is. 7z support is optional in mc and just depends on existence of p7zip binaries.
I think it's a pity that the salas team will keep the p7zip of secure up to date. We just update the _COMMIT variable and build again. Than enjoy.😎
New pull request. #3470
https://github.com/termux/termux-packages/pull/3470 has been merged and the updated package is now just a pkg up away - thanks a lot @kenneth-Q !