Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
https://spamassassin.apache.org/ says "*** On March 1, 2020, we will stop publishing rulesets with SHA-1 signatures. If you do not update to 3.4.2 or later, you will be stuck at the last ruleset with SHA-1 signatures. ***"
As of writing, I do not see any backported patch in SpamAssassin in RHEL 7.
Version-Release number of selected component (if applicable):
spamassassin-3.4.0-4.el7_5.x86_64
How reproducible:
By itself on 2020-03-01.
Actual results:
spamassassin-3.4.0-4.el7_5.x86_64
Expected results:
Rebase SpamAssassin to 3.4.2+ to support rules with non-SHA-1 signatures (after 2020-03-01) or backport (rebase still preferred).
Additional info:
I am aware that RHEL 7 is in a later part of its lifecycle, nevertheless without addressing this, it likely renders SpamAssassin quite powerless (or even useless) on RHEL 7 after 2020-03-01.
May I kindly ask if you talked with upstream if they're still including conditionals in their rulesets to cover older SpamAssassin versions properly? I mean upstream could assume that new rulesets (after 2020-03-01) are anyway working only on 3.4.2+ and thus they could (theoretically) skip conditionals (there might be new SpamAssassin features available in 3.4.2+, but not in 3.4.0).
I can't speak for upstream but doing a "grep version" on /var/lib/spamassassin/*/updates_spamassassin_org/*.cf reveals a number of "require_version X" and "if (version >= X)" lines, so I think conditionals are still in play as of now. A message to the SA mailing list suggests that these conditionals will remain for the foreseeable future; the release notes for 3.4.2 say: "This means that while we produce rule updates with the focus on them working for any release from v3.3.2 forward, they will start failing SHA-1 validation for sa-update."
That said, FTR, if your operation allows deviating from the standard RHEL/EPEL packages, the SRPM for 3.4.2 from Fedora installs cleanly (zero modifications) on CentOS 7 -- I imagine it would on RHEL 7 as well. (Note that 3.4.3 was released last month.)
I haven't asked them, however I think the release notes mentioned by Amir answer it. It should be noted though that due to the conditionals, some of the rules will not be available.
FYI, SpamAssassin 3.4.4 was released a few days ago. 3.4.4 fixes a couple of CVEs, as does 3.4.3. Since these are security-related, I imagine they should probably be backported into RHEL, although I hear the changes in 3.4.3 to address the CVEs were highly invasive, and the backport patch for Debian is of order 100KB... so a rebase may actually be easier.
(In reply to Robert Scheck from comment #6)
> May I kindly ask if you talked with upstream if they're still including
> conditionals in their rulesets to cover older SpamAssassin versions
> properly? I mean upstream could assume that new rulesets (after 2020-03-01)
> are anyway working only on 3.4.2+ and thus they could (theoretically) skip
> conditionals (there might be new SpamAssassin features available in 3.4.2+,
> but not in 3.4.0).
I've received a confirmation that the rules are intended to remain compatible.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7618#c24