Description of problem: Please add unar dependency/configuration for *.rar and comment *.lrz support. Version-Release number of selected component (if applicable): amavisd-new-2.11.0-1.el7 unar-1.10.1-1.el7 Expected results: --- snipp --- --- amavisd-new-2.11.0/amavisd.conf 2016-04-26 21:24:26.000000000 +0200 +++ amavisd-new-2.11.0/amavisd.conf.rsc 2017-11-27 00:24:38.000000000 +0100 @@ -326,8 +326,8 @@ ['lzma', \&do_uncompress, ['lzmadec', 'xz -dc --format=lzma', 'lzma -dc', 'unlzma -c', 'lzcat', 'lzmadec'] ], - ['lrz', \&do_uncompress, - ['lrzip -q -k -d -o -', 'lrzcat -q -k'] ], +# ['lrz', \&do_uncompress, +# ['lrzip -q -k -d -o -', 'lrzcat -q -k'] ], ['lzo', \&do_uncompress, 'lzop -d'], ['lz4', \&do_uncompress, ['lz4c -d'] ], ['rpm', \&do_uncompress, ['rpm2cpio.pl', 'rpm2cpio'] ], @@ -335,7 +335,7 @@ # ['/usr/local/heirloom/usr/5bin/pax', 'pax', 'gcpio', 'cpio'] ['deb', \&do_ar, 'ar'], # ['a', \&do_ar, 'ar'], # unpacking .a seems an overkill - ['rar', \&do_unrar, ['unrar', 'rar'] ], + ['rar', \&do_unrar, ['unrar', 'rar', 'unar'] ], ['arj', \&do_unarj, ['unarj', 'arj'] ], ['arc', \&do_arc, ['nomarch', 'arc'] ], ['zoo', \&do_zoo, ['zoo', 'unzoo'] ], --- snapp --- --- snipp --- --- a/amavisd-new.spec +++ b/amavisd-new.spec @@ -47,6 +47,7 @@ Requires: nomarch Requires: p7zip, p7zip-plugins Requires: tar Requires: unzoo +Requires: unar # We probably should parse the fetch_modules() code in amavisd for this list. # These are just the dependencies that don't get picked up otherwise. Requires: perl(Archive::Tar) --- snapp ---
Juan, ping?
Hi, I'll submit an update soon. Why to comment lrz? doesn't if fail gracefully when the decoder is not present?
(In reply to Juan Orti from comment #2) > Why to comment lrz? doesn't if fail gracefully when the decoder is not > present? Yes and no. It gracefully fails, but it still leaves a message mentioning a lack of a decoder (which can not be satisfied due to orphaned lrzip).
lrzip is not only orphaned. It's actually retired. The reason is it contains various security flaws, the upstream is not willing to fix them, other maintainers cannot because the format of the archive has never been specified and moreover it bundles ancient zpaq library (that's part of the vulnerability) that even the lrzip's author cannot unbundle or replace with an up-to-date version because he does not understand the zpaq internals to adjust it to lrzip's needs. In my opinion, amavis should not hard-require various unpacking tools. There are myriads of obscure formats that would drag in obscure and usually unmaintained tools and many of them are not even packaged in the distribution. Using these crappy tools would actually create a new attack vector against the SMTP server and thus actually lowered the security of the whole system. I would prefer if these dependencies were made optional (Recommends or Suggests on RPM level) and amavis should be able to cope with their unavailability (to log that it saw an message that it was unable to unpack, or per an configuration to discard the message because it was unable to inspect it).
unar is not working as-is, it uses different arguments. I'm looking into it. dic 12 09:36:40 helio amavis[3002]: (03002-01) (!)Decoding of p003 (RAR archive data, v4, os: Win32) failed, leaving it unpacked: do_unrar: can't get a list of archive members: exit 1; Unknown option -idcdp
I still can download lrzip from the epel7 repositories, shouldn't it be removed? I'm going to submit the removal of lrzip. I've also made the dependencies weak in rawhide. I'm holding the unar update because it doesn't support pipes and doesn't seem to work with amavis. We may need a wrapper to support it.
amavisd-new-2.11.0-2.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-5f6d89febd
(In reply to Juan Orti from comment #6) > I still can download lrzip from the epel7 repositories, shouldn't it be > removed? > Probably. "robert" is a maintainer in EPEL.
(In reply to Petr Pisar from comment #8) > Probably. "robert" is a maintainer in EPEL. Yes, that's me...
amavisd-new-2.9.1-3.el6 has been submitted as an update to Fedora EPEL 6. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-0f72359c5d
amavisd-new-2.11.0-2.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-5f6d89febd
amavisd-new-2.9.1-3.el6 has been pushed to the Fedora EPEL 6 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-0f72359c5d
amavisd-new-2.11.0-2.el7 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report.
amavisd-new-2.9.1-3.el6 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report.
Well, *.lrz is done, but the unar part is still left.
https://lists.amavis.org/pipermail/amavis-users/2016-December/004694.html
I'd need to package the unar-wrapper, which I don't see the code around. I also think it will be better to be included in the unar package.
This package has changed maintainer in the Fedora. Reassigning to the new maintainer of this component.
EPEL 7 entered end-of-life (EOL) status on 2024-06-30.\n\nEPEL 7 is no longer maintained, which means that it\nwill not receive any further security or bug fix updates.\n As a result we are closing this bug.