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.
Bug 1787382 - Add support for SHA-256/SHA512 signatures to sa-update
Summary: Add support for SHA-256/SHA512 signatures to sa-update
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: spamassassin
Version: 7.7
Hardware: x86_64
OS: Linux
urgent
high
Target Milestone: rc
: 7.7
Assignee: Ondřej Lysoněk
QA Contact: Ondrej Mejzlik
URL:
Whiteboard:
: 1797283 (view as bug list)
Depends On:
Blocks: 1780662 1791820
TreeView+ depends on / blocked
 
Reported: 2020-01-02 16:10 UTC by Robert Scheck
Modified: 2023-12-15 17:08 UTC (History)
10 users (show)

Fixed In Version: spamassassin-3.4.0-5.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1791820 (view as bug list)
Environment:
Last Closed: 2020-09-11 07:39:31 UTC
Target Upstream Version:
Embargoed:
thozza: mirror+

Attachments (Terms of Use)
patch (10.42 KB, patch)
2020-01-16 10:51 UTC, Ondřej Lysoněk 		no flags Details | Diff
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-53504 0 None None None 2022-04-25 22:34:04 UTC

Description Robert Scheck 2020-01-02 16:10:21 UTC 
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.
Comment 2 Robert Scheck 2020-01-02 16:19:24 UTC 
Filed case #02551736 at the Red Hat customer portal.
Comment 5 Ondřej Lysoněk 2020-01-09 17:47:10 UTC 
Rebase is out of scope for RHEL-7, however backporting support for SHA512 and SHA256 signatures should be easy enough.
Comment 6 Robert Scheck 2020-01-09 17:56:28 UTC 
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).
Comment 7 Amir Caspi 2020-01-10 03:28:49 UTC 
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.)
Comment 8 Ondřej Lysoněk 2020-01-13 11:20:36 UTC 
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.
Comment 13 Ondřej Lysoněk 2020-01-16 10:51:44 UTC 
Created attachment 1652727 [details]
patch
Comment 17 Ondřej Lysoněk 2020-02-03 09:29:32 UTC 
*** Bug 1797283 has been marked as a duplicate of this bug. ***
Comment 18 Amir Caspi 2020-02-03 10:04:47 UTC 
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.
Comment 21 Ondřej Lysoněk 2020-02-05 10:54:02 UTC 
(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
Comment 22 Peter Bieringer 2020-02-08 06:43:12 UTC 
unfortunately the zero invasive fix for DCC.pm was not included in that build, would have been a good chance, see also
https://bugzilla.redhat.com/show_bug.cgi?id=1532139
https://bugzilla.redhat.com/show_bug.cgi?id=1473017
Note You need to log in before you can comment on or make changes to this bug.