Hi all, Also Cc 874065, The only thing I'm concerned about is programs which depends on "unrar" command line tool. I'd really like to see all the programs moved to unar. Especially when listing files or iterate files into rar file, lsar's json output is far better than parsing unrar's console output.
But just some old program still using the older way so that makes unrar-free still here. Basically the code of unrar-free is not really high quality. I think I'll start working on fixing those security issues to see if they are easy. If not, I'll start working on patching the rdepends to use unar and lsar. Or wrote another scripts that use unar and lsar and replacing unrar-free. Yours, Paul On Sun, Oct 1, 2017 at 3:56 PM, Salvatore Bonaccorso <car...@debian.org> wrote: > Hi Ying-Chung, > > On Sun, Oct 01, 2017 at 12:25:59AM +0200, Moritz Muehlenhoff wrote: > > Hi Ying-Chun, > > https://security-tracker.debian.org/tracker/CVE-2017-14120 doesn't > warrant > > a DSA update. > > > > There's still the possibility to fix this via a stable point update > > [1], so I was wondering whether anything of that sort is planned by > > you. > > Do you have as well possibly an opinion/arguments as maintainer for > #874065? The forensics-extra have already removed unrar-free in favour > of unrar in their 1.9 upload. > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874065#18 > > unrar-free will be removed from testing around 16th of october, and > the dependency from python-rarfile to unrar-free will need to be > dropped, cf. #797730 but IMHO tha would be the best course of action > given libarchive can handle rar-files. > > Please let us know your opinion if you thin the above is wrong in > particular, there is still time. > > Regards, > Salvatore >
