Bug 7618 - Obtain variance to keep producing SHA-1 signatures for rules
Summary: Obtain variance to keep producing SHA-1 signatures for rules
Status: NEW
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: Building & Packaging (show other bugs)
Version: unspecified
Hardware: PC Windows NT
: P2 normal
Target Milestone: Undefined
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-09-08 20:25 UTC by Kevin A. McGrail
Modified: 2018-10-01 09:12 UTC (History)
3 users (show)



Attachment Type Modified Status Actions Submitter/CLA Status

Note You need to log in before you can comment on or make changes to this bug.
Description Kevin A. McGrail 2018-09-08 20:25:38 UTC
Bug 7614 got hijacked for this issue.  Recreating here.

KAM: Per https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7596, the policy now is designed to move away from MD5 and SHA-1 to use SHA-256 or SHA-512.

We are now producing binary releases and rule releases with SHA-256 & SHA-512 signatures.  For binary releases, we have stopped using SHA1 & MD5.

However, for rules, we would like approval to keep producing the SHA1 signature along with a SHA-256 & SHA-512 signature.

This will allow older installations back to Apache SpamAssassin 3.3.3 to continue to download and install our rule updates.

Please note that in addition to SHA-1, we also use a GPG signature fingerprint that much match cryptographically in addition to the hash signature.  We hope the combination of these two signatures is suitable for a variance.

Can we continue to produce rules with SHA-1, SHA-256 & SHA-512 signatures as long as it is also cryptographically signed?




Sidney: I'm +1 on doing this, however I think we should include plans for phasing out use of SHA-1, which implies some end of life date for the older versions of SpamAssassin that use it.

One thing that would make a difference in continuing with a variance - Does SpamAssassin 3.3.3 have any option to accept rules if the SHA-1 hash matches but another hash or digital signature does not match?
Comment 1 RW 2018-09-08 23:27:30 UTC
(In reply to Kevin A. McGrail from comment #0)

> One thing that would make a difference in continuing with a variance - Does
> SpamAssassin 3.3.3 have any option to accept rules if the SHA-1 hash matches
> but another hash or digital signature does not match?


The SHA1 check simply provided an integrity test. From a purely technical point of view changing to SHA256/512 makes no difference at all.
Comment 2 Sidney Markowitz 2018-09-09 00:02:50 UTC
With the latest changes to sa-update in 3.4.2 so that it will ignore SHA-1 hashes and require at least one of SHA-256 or SHA-512, I'm +1 with this. Even if we continue to include SHA-1 hashes with the rule updates, the newer versions of sa-update 3.4.2 and later will not be able to be tricked into relying on them.

I do note that the documentation in sa-update makes it explicit that the security comes from the GPG signature. The hashes are only to protect against data corruption in transit. The Apache policy to drop SHA-1 is for security reasons.

As RW pointed out, dropping SHA-1 here doesn't affect security. We are dropping use of SHA-1 for the rule updates because it is Apache policy to stop using SHA-1. If it isn't used anywhere then there is no need to evaluate where it is safe to use. Because it is not a security issue here, we can ask for a variance to last only until end of life of Apache SpamAssassin 3.3.2.

We should choose an end of life date for 3.3.2 compatible rule updates.
 
There is still the typo referring to a SpamAssassin version 3.3.3 instead of 3.3.2.
Comment 3 Kevin A. McGrail 2018-09-09 06:01:15 UTC
Sidney, I believe I fixed the typo in the announcement.  Can you be more specific where you see the typo?

The end of life for updates prior to 3.4.2 really depends on SHA-1 and the willingness to give us a variance on the policy.
Comment 4 Sidney Markowitz 2018-09-09 08:01:47 UTC
(In reply to Kevin A. McGrail from comment #3)
> Can you be more specific where you see the typo?

The description you copied over to create this bug still says 3.3.3. Not a big deal, I was just pointing it out.

> The end of life for updates prior to 3.4.2 really depends on SHA-1 and the
> willingness to give us a variance on the policy.

I'm just saying that it will be polite to state a definite date as soon as we can come up with one. I can see how that might end up depending on a time limit in the variance that we get.
Comment 5 Kevin A. McGrail 2018-09-09 16:18:53 UTC
Yes, the statement about 3.3.3 comes from reading DNS entries.  I am not sure exactly how far back in our releases that the can() and plugin conditionals work.

As you mentioned with the deadline, I think it will be driven by the response from the board re: the policy exemption/variant request.  Can we revisit it after they give input?
Comment 6 Sidney Markowitz 2018-09-09 20:31:39 UTC
(In reply to Kevin A. McGrail from comment #5)
> Can we revisit it after they give input?

Oh, yes, that's actually what I meant by "as soon as we can".
Comment 7 Kevin A. McGrail 2018-10-01 09:12:41 UTC
Variance no longer needed "the requirement to drop SHA1 was initially MUST NOT but
      as dg says it's now SHOULD, at
      http://www.apache.org/dev/release-distribution#sigs-and-sums -
      so nothing to approve indeed, SpamAssassin can continue to use
      SHA1 for a transition period."

Recommend as a team that we notify people that Dec 31, 2019 we will stop producing SHA1 rule signatures.