Bug 7618 - Obtain variance to keep producing SHA-1 signatures for rules
Summary: Obtain variance to keep producing SHA-1 signatures for rules
Status: RESOLVED FIXED
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: 2022-04-26 03:33 UTC (History)
6 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.
Comment 8 Henrik Krohns 2020-01-29 21:33:22 UTC
Please, let's not call checksums as _signatures_ in public. It's slightly embarassing.
Comment 9 Kevin A. McGrail 2020-01-30 15:05:19 UTC
I have not done a threat model on the weakness in sha1 sig's and why their weakness presents a risk either to rules or distributions but the policy[1] is very clear.  

[1] The policy is here: https://www.apache.org/dev/release-distribution#sigs-and-sums

The March deadline was to give distros and administrators time to come to terms with this problem.
Comment 10 Henrik Krohns 2020-01-30 15:59:07 UTC
Let me fully reiterate:

I object to calling checksums "signatures", which they are not. It simply creates confusion.

Apache has it correct https://www.apache.org/dev/release-distribution#sigs-and-sums:
  .asc for a (ASCII-armored) PGP _signature_
  .sha1 for a SHA-1 _checksum_

- Checksums are file integrity checks, nothing more
- Signatures verify authenticity cryptographically

As already mentioned here, SHA-whatever makes no difference for security. It's simply a file integrity check. PGP is used for verification.

I also do not see anything in that Apache policy that would affect how sa-update does it's job. It's not related to software artifacts or any .apache.org site. The sa-update rules are not even hosted on ASF infra.

That said, I have no vote either way as it makes no difference to anything. It just seems a big hassle about nothing. But it's a good thing if it makes people upgrade some installations.
Comment 11 Kevin A. McGrail 2020-01-30 16:56:00 UTC
My apologies for calling it a sig instead of a sum.  That is clearly wrong and me just being lazy.

What is important is that sa-update's use of a combination of GPG signature and hash sum was part of the reason we got the ASF extension on this policy previously.  However, it's not permitted to use md5 or sha1 to checksum and publish the veracity of a release.  Our rules are considered releases and I can't show there is no risk.
Comment 12 Henrik Krohns 2020-01-30 17:05:54 UTC
(In reply to Kevin A. McGrail from comment #11)
> Our rules are considered releases

Is this your interpretation, or is there an official ASF comment about this somewhere?
Comment 13 Kevin A. McGrail 2020-01-30 19:19:19 UTC
It is not my interpretation.  It's been reported to the board as a release artifact for eons: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=139627492
Comment 14 RW 2020-01-31 01:08:34 UTC
(In reply to Kevin A. McGrail from comment #9)
> I have not done a threat model on the weakness in sha1 sig's and why their
> weakness presents a risk either to rules or distributions but the policy[1]
> is very clear.  

The wording is "SHOULD NOT supply a MD5 or SHA-1 checksum file", using the terminology of RFC 2119:

  " SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
   there may exist valid reasons in particular circumstances when the
   particular behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed
   before implementing any behavior described with this label."
Comment 15 Kevin A. McGrail 2020-01-31 05:22:13 UTC
(In reply to RW from comment #14)
> (In reply to Kevin A. McGrail from comment #9)
> > I have not done a threat model on the weakness in sha1 sig's and why their
> > weakness presents a risk either to rules or distributions but the policy[1]
> > is very clear.  
> 
> The wording is "SHOULD NOT supply a MD5 or SHA-1 checksum file", using the
> terminology of RFC 2119:
> 
>   " SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
>    there may exist valid reasons in particular circumstances when the
>    particular behavior is acceptable or even useful, but the full
>    implications should be understood and the case carefully weighed
>    before implementing any behavior described with this label."

Agreed. The Mar 1 not very distant future warning is for when the policy goes from should not to must not so people are not caught off guard.
Comment 16 RW 2020-01-31 16:19:50 UTC
There are some cases were hash files could be used for authentication, for example, someone might download one via HTTPS to verify a tarball from a shared insecure cache. Clearly those rules apply to the rule tarball on this page:

  http://spamassassin.apache.org/downloads.cgi

There are no SHA-1 or MD5 hash files there for the rule tarball, it's already compliant.  

The URLs used by sa-update are part of a private interface that isn't exposed to the public (unless they dig around in the internals), and where the security of the hashes is irrelevant.   To apply the same rules here is stretching the letter of the law and ignoring its spirit IMO.
Comment 17 Kevin A. McGrail 2020-01-31 16:27:39 UTC
I recommend this is discussed with the PMC and then email security@ with an ask once consensus is reached.
Comment 18 Sidney Markowitz 2020-01-31 22:29:45 UTC
Given that we have announced that on March 1, 2020 we will stop publishing SHA-1 hashes for sa-update rulesets, removing the ability of SpamAssassin versions older than 3.4.2 to run sa-update to get ruleset updates, what is left to discuss in the PMC? I don't even see an issue to reach consensus about.


Perhaps with exactly a month to go we can today repeat the announcement with the proper phrasing calling it "checksums" rather than "signatures", but I see nothing else that needs to be done or decided. Oh, I guess it would be good if one committer volunteers to be the person to actually make the change on March 1 so that it doesn't fall through the cracks.
Comment 19 Kevin A. McGrail 2020-02-01 04:23:47 UTC
Well it's not my intent to take anyone by surprise.  This announcement is the same information that was included in 3.4.3 just carried forward to 3.4.4 based on requests to stop using SHA-1 checksums.

Some PMC members have raised flags and I'd like them to have the opportunity to discuss and see if they can determine there is no security risk and if a variance request makes sense.  I'm a 0 on that effort and 3.4.2 was release in 2018 with 3.4.1 in 2015.

Are there command line parameters to ignore the sums with 3.4.0 & 3.4.1 that we can recommend people use?

An unofficial channel could also just repackage the rules and provide a sha-1 sig if there is demand for it.

I have updated the verbiage on the index and news page on the website.  I'm not the only one to refer to them as signatures though (https://en.wikipedia.org/wiki/SHA-1)

I have a reminder from Dec on my to-list to stop sha-1 checksums and will lead the effort with SA Sysadmins to implement it.

Anything I missed, Sidney?
Comment 20 Henrik Krohns 2020-02-01 05:36:11 UTC
(In reply to Kevin A. McGrail from comment #19)
>
> I have updated the verbiage on the index and news page on the website.  I'm
> not the only one to refer to them as signatures though
> (https://en.wikipedia.org/wiki/SHA-1)

I know you are busy, but I wish you'd take a small breather to think. :-) I'm pretty sure even you know the difference between using SHA-1 _in signatures_ (as part of a certificate checksum) and a generic file.
Comment 21 Henrik Krohns 2020-02-01 05:57:09 UTC
sa-update thankfully has things very clear:

"sa-update by default will verify update archives by use of SHA256 and SHA512
checksums and GPG signature.  SHA* hashes can verify whether or not the
downloaded archive has been corrupted, but it does not offer any form of
security regarding whether or not the downloaded archive is legitimate
(aka: non-modifed by evildoers).  GPG verification of the archive is used to
solve that problem."

Debian/Ubuntu already have 3.4.2 and even RedHat seems to be getting SHA256 support, so hopefully will be good there:
https://bugzilla.redhat.com/show_bug.cgi?id=1787382
Comment 22 Sidney Markowitz 2020-02-01 14:20:25 UTC
(In reply to Kevin A. McGrail from comment #19)
> Some PMC members have raised flags and I'd like them to have the opportunity
> to discuss and see if they can determine there is no security risk and if a
> variance request makes sense.  I'm a 0 on that effort and 3.4.2 was release
> in 2018 with 3.4.1 in 2015.

I didn't see any flags raised since the decisions that were made in September 2018. Nobody objected to the March 1, 2020 date that was announced in the release of 3.4.3 and 3.4.4. The only objection was to point out that the word "signature" should be "checksum", but that doesn't invalidate the announcement.

> 
> Are there command line parameters to ignore the sums with 3.4.0 & 3.4.1 that
> we can recommend people use?

No. There is one to ignore the GPG signature, but sa-update before 3.4.2 will exit with a channel failed message if no SHA-1 checksum file can be downloaded. This will make March 1, 2020 a hard deadline for running sa-update in versions older than 3.4.2. The only workaround would be to patch sa-update like RedHat is proposing to do in https://bugzilla.redhat.com/show_bug.cgi?id=1787382

BTW, I don't think RedHat's approach is a good idea. We have made sure that rule updates work with old versions, including conditionals as necessary, but with this change the backwards compatibility will no longer be tested and IMO should not be counted on.

> An unofficial channel could also just repackage the rules and provide a
> sha-1 sig if there is demand for it.
>

That's the right way to do it if anyone really wants to set one up. However, that will still depend on rule developers making sure that the rules stay backward compatible. Can we count on sufficient testing for that?

> I have updated the verbiage on the index and news page on the website.  I'm
> not the only one to refer to them as signatures though
> (https://en.wikipedia.org/wiki/SHA-1)

Nope, the wikipedia article talks about *use* of SHA-1 in computing signatures. A signature is a cryptographic hash checksum that is encrypted with a private key. The checksum by itself is not a signature.

> 
> I have a reminder from Dec on my to-list to stop sha-1 checksums and will
> lead the effort with SA Sysadmins to implement it.
> 
> Anything I missed, Sidney?

+1 on that from me
Comment 23 Ondrej Lysonek 2020-02-04 09:57:07 UTC
Hi everyone,

(In reply to Sidney Markowitz from comment #22)
> The only workaround would be to
> patch sa-update like RedHat is proposing to do in
> https://bugzilla.redhat.com/show_bug.cgi?id=1787382
> 
> BTW, I don't think RedHat's approach is a good idea. We have made sure that
> rule updates work with old versions, including conditionals as necessary,
> but with this change the backwards compatibility will no longer be tested
> and IMO should not be counted on.

In the 3.4.2 announcement [1] it said the following, which I understood to mean that the rules would continue to be compatible with spamassassin >= 3.3.2.

"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."

Am I misunderstanding something, or has the position of the SpamAssassin project changed with regard to this?

Due to the late phase of its lifecycle, packages cannot be rebased to newer versions in RHEL-7. So it would be lovely if the rules remained compatible with older spamassassin versions.

[1] https://lists.apache.org/thread.html/1ac11532235b5459aa16c4e9d636bf4aa0b141d347d1361e40cc1b78@%3Cannounce.apache.org%3E
Comment 24 Kevin A. McGrail 2020-02-04 22:56:54 UTC
The rules will remain compatible.  How they are updated and installed is an issue since the older sa-update's will fail without a sha-1 file.
Comment 25 Sidney Markowitz 2020-02-05 01:06:58 UTC
(In reply to Ondrej Lysonek from comment #23)
> Am I misunderstanding something, or has the position of the SpamAssassin
> project changed with regard to this?

The rules should remain compatible and are intended to remain compatible. I was expressing my concern that when we make this change there will be fewer people actually running the rule updates in older versions of SpamAssassin and so it will be easier for a backwards compatibility bug in a rule update to slip by.

Also, I was not speaking for the project when I posted the comment.
Comment 26 Ondrej Lysonek 2020-02-05 10:43:58 UTC
OK. Thank you!
Comment 27 Sidney Markowitz 2022-04-26 03:33:06 UTC
This issue doesn't have to be left open. On 2018-09-19 the PMC was notified by the Board that we don't have to request a variance. The policy was changed and now says that SHA-1 SHOULD NOT be used instead of MUST NOT. See
https://infra.apache.org/release-distribution#sigs-and-sums

We can decide when is a suitable time to stop generating SHA-1 hashes in mkupdate, based on when we consider it suitable to add that level of extra step to people who insist on using a sufficiently old version.