View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0016544||CentOS-7||spamassassin||public||2019-10-06 07:30||2020-01-10 03:33|
|Target Version||Fixed in Version|
|Summary||0016544: Update spamassassin|
|Description||Version 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.
|Tags||No tags attached.|
|FWIW, https://src.fedoraproject.org/rpms/spamassassin/tree/master with this PR: https://src.fedoraproject.org/rpms/spamassassin/pull-request/9 builds on EL7: https://copr.fedorainfracloud.org/coprs/brianjmurrell/epel-7/build/1048927/|
|as you know that spamassassin is a pkg from upstream RHEL 7, maybe the request should be made upstream (so on bugzilla.redhat.com) so that when it enters upstream rhel, it will land automatically on centos|
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.
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.
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.
> 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.
|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?|
|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.|
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.
FWIW this has been reported upstream: https://bugzilla.redhat.com/show_bug.cgi?id=1787382
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.)
|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|