https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7614
Bill Cole <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #3 from Bill Cole <[email protected]> --- (In reply to Sidney Markowitz from comment #2) > This is late to bring this up, but I think I have a problem with this > regarding what we did for bug #7596 On 2nd thought, so do I. > It is one thing to keep publishing SHA-1 hash for rules to maintain backward > compatibility with SpamAssassin 3.3.2 while we set an end of life for it. It > is another to have SHA-1 checking in sa-update 3.4.2. If someone runs > sa-update with the --no-gpg option, even if we publish rules with SHA-256 > and SHA-512 hashes, an attacker who somehow introduces a fake rule update > that matches our SHA-1 could block reception of the SHA-256 and SHA-512 > hashes, and sa-update running with --no-gpg would accept the fake rules. > > I think sa-update in 3.4.2 should not check the SHA-1 hash at all. I am not sure that it should not check at all, but it should not consider a SHA1 match adequate for trusting a rule package. > We would > still publish SHA-1 to allow 3.3.2 to accept the rules, only stopping that > after reaching an announced end of life for SpamAssassin 3.3.2. > > Is there any reason to keep support for checking SHA-1 in 3.4.2? Marginally, yes. > Will there > be any rule updates released in the future that do not include the SHA-256 > and SHA-512 hashes? In theory, no. However, weird stuff happens. It would be good to limit the scope of weird stuff that could break SA. The logic I suggest is: 1. Check all 3 hashes and signature (unless --no-gpg is used) 2. Require that ALL available hashes and signature (unless --no-gpg is used) verify. Reject update if any available hash or the signature fails to verify. 3. Require that there is at least one of the SHA256 and SHA512 hashes available and (per (2)) each available hash verifies. 4. (implicit in (2)) If a SHA1 hash is available, require it to verify. Rationale: It is plausible that a usable collision attack on SHA256 and/or SHA512 will become possible in the future. Hash collision attacks exist, so new ones are reasonable to expect. It is NOT plausible that such an attack will provide simultaneous collision with the SHA1 hash of the target file. We will be generating SHA1 hashes anyway, so checking them (NOT trusting them) is a cheap backstop. I will try to get a fix to sa-update ready tomorrow. -- You are receiving this mail because: You are the assignee for the bug.
