View Issue Details

IDProjectCategoryView StatusLast Update
0016544CentOS-7spamassassinpublic2020-01-10 03:33
Status newResolutionopen 
Product Version7.7-1908 
Target VersionFixed in Version 
Summary0016544: Update spamassassin
DescriptionVersion 3.4.2 has been released:

2018-09-16: SpamAssassin 3.4.2 has been released! This release contains numerous tweaks and bug fixes over the past three and 1/2 years including:
sa-update now uses SHA-256 & SHA-512 hashing to verify rule updates;
4 new plugins; and
Four CVE security bug fixes: CVE-2017-15705, CVE-2016-1238, CVE-2018-11780 & CVE-2018-11781.

But most importantly, there are checks (i.e. to increase spam score) that are only available in versions >= 3.4.1 so having such an outdated release in CentOS-7 is actually allowing spam to be under-scored.
TagsNo tags attached.




2019-10-06 10:04

reporter   ~0035346

FWIW, with this PR: builds on EL7:


2019-10-06 10:11

administrator   ~0035347

as you know that spamassassin is a pkg from upstream RHEL 7, maybe the request should be made upstream (so on so that when it enters upstream rhel, it will land automatically on centos


2019-10-06 10:33

reporter   ~0035348

Yes, but as you know, RH typically only really pay attention to RHEL bug reports from RHEL subscribers.

I was assuming there was some amount of relationship between CentOS and RH (now that RH owns CentOS) that would enable getting these kinds of updates upstream in a more responsive manner than reports from average-joe non-RHEL-subscribers.


2019-10-06 10:34

reporter   ~0035349

In any case, I have my update, in my COPR and it's working much better than 3.4.0.

I just thought I would try to initiate some activity that would provide this benefit to the larger community rather than just solving it for myself.


2020-01-06 10:46

reporter   ~0035937


I've had the same experience, redhat closed my ticket because I am not a RHEL paid customer.

My suggestion, is to have a talk about special cases, when packages become "garbage" because they are too old or when significant changes in our environment require some kind of intervention. For example, a package like "yum" may not require any updates over a 10 year period, but a package like spamassassin is affected by various external factors, like the evolution of spam, rule updates and changes to the signature algorithm.

Either a member of the CentOS dev team pushes for a change, or we find a big redhat client and have them push for it. Otherwise I don't see anything happening and the only solution would be to migrate to CentOS 8. Something that is not possible at the moment, due to the bad state of 8. Waiting for 8.1 to see how that goes.

I've been around since CentOS 4 and the same situation repeats itself, almost all tickets around here receive the same reply: "report it upstream to redhat", but redhat only cares about their paid customers.


2020-01-06 13:34

reporter   ~0035938

> same reply: "report it upstream to redhat"

What exactly is the point of this bug tracker if that is the standard response?

It's equally annoying to have CentOS subverting abrt reports to report them here instead of upstream at RH's bugzilla because of this common "report it upstream to redhat". So please stop subverting abrt reports and having them report here if nothing is going to be done with them. At least perhaps an abrt report of something like a segfault reported to RH even by non RH customers *might* get some attention rather than being ignored as "report it upstream to redhat" like it gets here.


2020-01-06 13:46

reporter   ~0035939

From what little I understand, this bug tracker exists to report a bug that ONLY exists in CentOS and probably happened during the conversion from RHEL to CentOS. It seems everything else is pretty much ignored... how else would they get you to pay for RHEL?


2020-01-06 14:40

manager   ~0035941

CentOS is a rebuild of RHEL from the same sources. It is NOT a bug if CentOS displays the same behaviour as RHEL even if RHEL has a bug. We aim for bug for bug compatibility with RHEL. If you need a bug fixed in CentOS that is also in RHEL then the only way that happens is to get RH to fix it in RHEL first and then it gets picked up and rebuilt by CentOS. If you find a bug in CentOS that is NOT in RHEL then it will get fixed by reporting it here. If you report a bug here that IS in RHEL then it won't be until RHEL fix it.


2020-01-06 14:46

reporter   ~0035942

Thanks. I completely understand what CentOS is.

But given your description above about what a CentOS bug is, please stop subverting abrt bug reports then as those will 99.99% of the time be a bug in RHEL, not CentOS.

Having abrt report here is useless to both the CentOS community as well as the RHEL community if non-CentOS bugs are not going to be dealt with here.


2020-01-10 03:33

reporter   ~0035993

FWIW this has been reported upstream:
It looks like they consider a rebase to be out of scope, so I suspect this won't happen. I can confirm that the Fedora SRPM installs cleanly on CentOS 7 (for me, it installs even without the PR mentioned in the first comment).

(Note also that 3.4.3 was released last month.)

Issue History

Date Modified Username Field Change
2019-10-06 07:30 brianjmurrell New Issue
2019-10-06 10:04 brianjmurrell Note Added: 0035346
2019-10-06 10:11 arrfab Note Added: 0035347
2019-10-06 10:33 brianjmurrell Note Added: 0035348
2019-10-06 10:34 brianjmurrell Note Added: 0035349
2020-01-06 10:46 KernelOops Note Added: 0035937
2020-01-06 13:34 brianjmurrell Note Added: 0035938
2020-01-06 13:46 KernelOops Note Added: 0035939
2020-01-06 14:40 TrevorH Note Added: 0035941
2020-01-06 14:46 brianjmurrell Note Added: 0035942
2020-01-10 03:33 cepheid Note Added: 0035993