You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by bu...@bugzilla.spamassassin.org on 2018/08/07 21:29:09 UTC
[Bug 7596] New: Update distribution to satisfy new Apache policies,
including replacing SHA-1 checksums with SHA-256 or SHA-512
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7596
Bug ID: 7596
Summary: Update distribution to satisfy new Apache policies,
including replacing SHA-1 checksums with SHA-256 or
SHA-512
Product: Spamassassin
Version: 3.4 SVN branch
Hardware: PC
OS: Mac OS X
Status: NEW
Severity: normal
Priority: P2
Component: Building & Packaging
Assignee: dev@spamassassin.apache.org
Reporter: sidney@sidney.com
Target Milestone: Undefined
See https://www.apache.org/dev/release-distribution#sigs-and-sums
We need to make sure that we confirm to the current release distribution
policies before our next release.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7596] Update distribution to satisfy new Apache policies,
including replacing SHA-1 checksums with SHA-256 or SHA-512
Posted by bu...@bugzilla.spamassassin.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7596
John Hardin <jh...@impsec.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jhardin@impsec.org
--- Comment #5 from John Hardin <jh...@impsec.org> ---
(In reply to Kevin A. McGrail from comment #4)
> Note, I'm confirming the exact sha1 and sha256 behavior for rules updates.
> We'll be creating both for at least the near future since we are
> cryptographically verifying updates anyway the sha-1 risk is infinitesimally
> low IMO.
I would suggest that (in new code) if both are available then both should be
checked and should both verify the content. At some point in the future we can
completely disable SHA-1 generation and verification.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7596] Update distribution to satisfy new Apache policies,
including replacing SHA-1 checksums with SHA-256 or SHA-512
Posted by bu...@bugzilla.spamassassin.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7596
--- Comment #4 from Kevin A. McGrail <km...@apache.org> ---
Note, I'm confirming the exact sha1 and sha256 behavior for rules updates.
We'll be creating both for at least the near future since we are
cryptographically verifying updates anyway the sha-1 risk is infinitesimally
low IMO.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7596] Update distribution to satisfy new Apache policies,
including replacing SHA-1 checksums with SHA-256 or SHA-512
Posted by bu...@bugzilla.spamassassin.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7596
Kevin A. McGrail <km...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #13 from Kevin A. McGrail <km...@apache.org> ---
Bug 7609 to publish rules with SHA512 and to check SHA1/256/512 if available in
sa-update
3.4:
Committed revision 1839834.
Committed revision 1839835.
Trunk:
At revision 1839836.
--
You are receiving this mail because:
You are the assignee for the bug.
Re: [Bug 7596] New: Update distribution to satisfy new Apache
policies, including replacing SHA-1 checksums with SHA-256 or SHA-512
Posted by Spam Auditor <sp...@linuxmagic.com>.
On 18-08-07 02:29 PM, bugzilla-daemon@bugzilla.spamassassin.org wrote:
> https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7596
>
> Bug ID: 7596
> Summary: Update distribution to satisfy new Apache policies,
> including replacing SHA-1 checksums with SHA-256 or
> SHA-512
> Product: Spamassassin
> Version: 3.4 SVN branch
> Hardware: PC
> OS: Mac OS X
> Status: NEW
> Severity: normal
> Priority: P2
> Component: Building & Packaging
> Assignee: dev@spamassassin.apache.org
> Reporter: sidney@sidney.com
> Target Milestone: Undefined
>
> See https://www.apache.org/dev/release-distribution#sigs-and-sums
>
> We need to make sure that we confirm to the current release distribution
> policies before our next release.
>
Can we have some clarity on 'intentions' in this regard?
Working on our modified sa-update program, and would like to know what
version is road mapped for SHA256, and because of the need to support
both legacy and new versions, want to build in support for both methods,
and want to confirm that the extension will be .sha256 vs .sha1 file
naming conventions.
Might want to suggest that a 'bridge' version might be considered, which
can support .sha1 files as a fallback, during transition, with a version
where .sha1 will no longer be supported.
Giving lead time will assist developers and custom 'channel' suppliers.
Re: Fwd: [Bug 7596] Update distribution to satisfy new Apache
policies, including replacing SHA-1 checksums with SHA-256 or SHA-512
Posted by "Kevin A. McGrail" <km...@apache.org>.
On 8/24/2018 7:24 PM, John Hardin wrote:
> On Fri, 24 Aug 2018, Kevin A. McGrail wrote:
>
>> I was a little more definitive on this comment than I should have been,
>> my apologies.
>>
>> Any comments on my response?
>
> How far back does the SHA256 support go? Would 3.3.x or 3.4.0 be
> broken by dropping the SHA1 sigs?
sha-256 support for rule signatures was added recently. It would break
everything previously released to drop sha1.
We should stop using sha1 though going forward so we could, for example,
add sha 512 support and verify both 512 and 256, perhaps.
Regards,
KAM
>
>
>> -------- Forwarded Message --------
>> Subject: [Bug 7596] Update distribution to satisfy new Apache
>> policies,
>> including replacing SHA-1 checksums with SHA-256 or SHA-512
>> Date: Fri, 24 Aug 2018 20:41:39 +0000
>> From: bugzilla-daemon@bugzilla.spamassassin.org
>> To: dev@spamassassin.apache.org
>>
>>
>>
>> https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7596
>>
>> --- Comment #7 from Kevin A. McGrail <km...@apache.org> ---
>> Just confirmed that code for the support to use sha256 by default for
>> rule
>> signatures and that sha1 is used as secondary if sha256 does not
>> exist IS in
>> 3.4 and trunk.
>>
>> Rules updates will continue to create sha1 and sha256 signatures
>> along with the
>> cryptographic signature.
>>
>> For 3.4.2 code release, we'll add a sha256 and/or sha512 signature
>> per the new
>> policy and NOT publish a sha1 signature.
>>
>> dropping sha1 support for rule publication is not currently under
>> consideration
>> due to legacy installations but we will mention that it's a concern
>> to upgrade
>> to 3.4.2+ in the near future.
>
Re: [Bug 7596] Update distribution to satisfy new Apache policies,
including replacing SHA-1 checksums with SHA-256 or SHA-512
Posted by John Hardin <jh...@impsec.org>.
On Fri, 24 Aug 2018, Bill Cole wrote:
> On 24 Aug 2018, at 19:24, John Hardin wrote:
>
>> How far back does the SHA256 support go?
>
> Not far:
>
> $ svn log sa-update.raw |grep -A1 -B3 SHA256
> ------------------------------------------------------------------------
> r1826916 | billcole | 2018-03-15 23:15:19 -0400 (Thu, 15 Mar
> 2018) | 1 line
>
> added optional support for SHA256 in addition to or instead
> of SHA1 validation
> ------------------------------------------------------------------------
>
>
>> Would 3.3.x or 3.4.0 be broken by dropping the SHA1 sigs?
>
> Yes. 3.4.1 as well.
Rats.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
A sword is never a killer, it is but a tool in the killer's hands.
-- Lucius Annaeus Seneca (Martial) 4BC-65AD
-----------------------------------------------------------------------
Today: the 1939th anniversary of the destruction of Pompeii
Re: [Bug 7596] Update distribution to satisfy new Apache policies,
including replacing SHA-1 checksums with SHA-256 or SHA-512
Posted by Bill Cole <sa...@billmail.scconsult.com>.
On 24 Aug 2018, at 19:24, John Hardin wrote:
> How far back does the SHA256 support go?
Not far:
$ svn log sa-update.raw |grep -A1 -B3 SHA256
------------------------------------------------------------------------
r1826916 | billcole | 2018-03-15 23:15:19 -0400 (Thu, 15 Mar 2018) | 1
line
added optional support for SHA256 in addition to or instead of SHA1
validation
------------------------------------------------------------------------
> Would 3.3.x or 3.4.0 be broken by dropping the SHA1 sigs?
Yes. 3.4.1 as well.
Re: Fwd: [Bug 7596] Update distribution to satisfy new Apache
policies, including replacing SHA-1 checksums with SHA-256 or SHA-512
Posted by John Hardin <jh...@impsec.org>.
On Fri, 24 Aug 2018, Kevin A. McGrail wrote:
> I was a little more definitive on this comment than I should have been,
> my apologies.
>
> Any comments on my response?
How far back does the SHA256 support go? Would 3.3.x or 3.4.0 be broken by
dropping the SHA1 sigs?
> -------- Forwarded Message --------
> Subject: [Bug 7596] Update distribution to satisfy new Apache policies,
> including replacing SHA-1 checksums with SHA-256 or SHA-512
> Date: Fri, 24 Aug 2018 20:41:39 +0000
> From: bugzilla-daemon@bugzilla.spamassassin.org
> To: dev@spamassassin.apache.org
>
>
>
> https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7596
>
> --- Comment #7 from Kevin A. McGrail <km...@apache.org> ---
> Just confirmed that code for the support to use sha256 by default for rule
> signatures and that sha1 is used as secondary if sha256 does not exist IS in
> 3.4 and trunk.
>
> Rules updates will continue to create sha1 and sha256 signatures along with the
> cryptographic signature.
>
> For 3.4.2 code release, we'll add a sha256 and/or sha512 signature per the new
> policy and NOT publish a sha1 signature.
>
> dropping sha1 support for rule publication is not currently under consideration
> due to legacy installations but we will mention that it's a concern to upgrade
> to 3.4.2+ in the near future.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Today: the 1939th anniversary of the destruction of Pompeii
Fwd: [Bug 7596] Update distribution to satisfy new Apache policies,
including replacing SHA-1 checksums with SHA-256 or SHA-512
Posted by "Kevin A. McGrail" <km...@apache.org>.
I was a little more definitive on this comment than I should have been,
my apologies.
Any comments on my response?
-------- Forwarded Message --------
Subject: [Bug 7596] Update distribution to satisfy new Apache policies,
including replacing SHA-1 checksums with SHA-256 or SHA-512
Date: Fri, 24 Aug 2018 20:41:39 +0000
From: bugzilla-daemon@bugzilla.spamassassin.org
To: dev@spamassassin.apache.org
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7596
--- Comment #7 from Kevin A. McGrail <km...@apache.org> ---
Just confirmed that code for the support to use sha256 by default for rule
signatures and that sha1 is used as secondary if sha256 does not exist IS in
3.4 and trunk.
Rules updates will continue to create sha1 and sha256 signatures along with the
cryptographic signature.
For 3.4.2 code release, we'll add a sha256 and/or sha512 signature per the new
policy and NOT publish a sha1 signature.
dropping sha1 support for rule publication is not currently under consideration
due to legacy installations but we will mention that it's a concern to upgrade
to 3.4.2+ in the near future.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7596] Update distribution to satisfy new Apache policies,
including replacing SHA-1 checksums with SHA-256 or SHA-512
Posted by bu...@bugzilla.spamassassin.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7596
--- Comment #7 from Kevin A. McGrail <km...@apache.org> ---
Just confirmed that code for the support to use sha256 by default for rule
signatures and that sha1 is used as secondary if sha256 does not exist IS in
3.4 and trunk.
Rules updates will continue to create sha1 and sha256 signatures along with the
cryptographic signature.
For 3.4.2 code release, we'll add a sha256 and/or sha512 signature per the new
policy and NOT publish a sha1 signature.
dropping sha1 support for rule publication is not currently under consideration
due to legacy installations but we will mention that it's a concern to upgrade
to 3.4.2+ in the near future.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7596] Update distribution to satisfy new Apache policies,
including replacing SHA-1 checksums with SHA-256 or SHA-512
Posted by bu...@bugzilla.spamassassin.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7596
--- Comment #6 from Kevin A. McGrail <km...@apache.org> ---
Interesting suggestion.
The sha-1 issue is going to require a policy exemption from ASF. I think they
will grant it since we are ALSO using crypto verification along with the sha1.
Otherwise we turn off rule generation for anything pre 3.4.2 and leave them on
a static rule set with sha-1 available.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7596] Update distribution to satisfy new Apache policies,
including replacing SHA-1 checksums with SHA-256 or SHA-512
Posted by bu...@bugzilla.spamassassin.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7596
Kevin A. McGrail <km...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |kmcgrail@apache.org
--- Comment #2 from Kevin A. McGrail <km...@apache.org> ---
New Policy from yesterday, not yet linked publicly:
TLDR;
The release distribution checksum policy requires new releases to use SHA-512
or SHA-256 and not SHA-1 for verification. Existing releases do not need to be
changed. Releases still need to be signed via detached PGP signatures.
Details:
Recently, a successful penetration of SHA-1 was verified, and SHA-1 is no
longer considered safe for crypto hashes
https://www.pcworld.com/article/3173791/security/stop-using-sha1-it-s-now-completely-unsafe.html
[1] http://www.apache.org/legal/release-policy.html#release-announcements
[2] https://www.apache.org/dev/release-distribution#download-links
[3] https://www.apache.org/dev/release-distribution#sigs-and-sums
Announcements of Apache project releases must contain a link to the relevant
download page, which might be hosted on an Apache site or a third party site
such as github.com. [1]
All official releases must be uploaded to the official distribution channel,
www.apache.org/dist.
The download page must provide public download links where current official
source releases and accompanying cryptographic files may be obtained. [2]
The policy on release distribution has been changed to require SHA-512 or
SHA-256
and disallow new artifacts to use SHA-1. [3]
Links to the download artifacts must support downloads from mirrors, e.g. via
links to
dyn/closer. Links to metadata (SHA, ASC) must be from
https://www.apache.org/dist/<project>/<release> and specifically not from
dist.apache.org/repos/dist
MD5 is no longer considered useful and should not be used. SHA is required.
Similarly, SHA-1 is no longer considered useful and should not be used.
SHA-512 (preferred) or SHA-256 are required for new releases. Older releases
need not be updated, may continue unchanged, and might use MD5 or SHA-1.
Links to KEYS must be from https://www.apache.org/dist/<project>/ not release
specific.
Announcements that contain a link to the dyn/closer page alone will be
rejected by the moderators.
Announcements that contain a link to a web page that does not include a link
to a mirror to the artifact plus links to the signature and at least one sha
checksum will be rejected.
Craig L Russell
Secretary, Apache Software Foundation
clr@apache.org http://db.apache.org/jdo
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7596] Update distribution to satisfy new Apache policies,
including replacing SHA-1 checksums with SHA-256 or SHA-512
Posted by bu...@bugzilla.spamassassin.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7596
Sidney Markowitz <si...@sidney.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Version|3.4 SVN branch |unspecified
Target Milestone|Undefined |3.4.2
CC| |sidney@sidney.com
--- Comment #1 from Sidney Markowitz <si...@sidney.com> ---
I don't see any reason not to only use SHA-256, and not SHA-512.
Note that we are required to not include SHA-1 checksums.
We are not required to generate new checksums for old versions that are still
available for download.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7596] Update distribution to satisfy new Apache policies,
including replacing SHA-1 checksums with SHA-256 or SHA-512
Posted by bu...@bugzilla.spamassassin.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7596
--- Comment #12 from Kevin A. McGrail <km...@apache.org> ---
(In reply to RW from comment #11)
> (In reply to Kevin A. McGrail from comment #2)
> > New Policy from yesterday, not yet linked publicly:
> >
>
> > Details:
> >
> > Recently, a successful penetration of SHA-1 was verified, and SHA-1 is no
> > longer considered safe for crypto hashes
>
> This is an exaggeration, Google demonstrated a successful collision attack.
>
> A collision attack against a release would require that both the legitimate
> tarball and the fake be created together, so only one of you lot could pull
> it off. And you'd need hardware that's orders of magnitude faster than
> Google's to avoid some very suspicious behaviour.
Bill, I did not write that policy. I am relaying it.
The SA project is superbly protected anyway because we ALSO cryptographically
sign our releases as well. So there is not huge urgency to switch to sha-256+
but we should move forward with the policy that sha1 is becoming less safe to
rely on.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7596] Update distribution to satisfy new Apache policies,
including replacing SHA-1 checksums with SHA-256 or SHA-512
Posted by bu...@bugzilla.spamassassin.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7596
Sidney Markowitz <si...@sidney.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
OS|Mac OS X |All
Hardware|PC |All
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7596] Update distribution to satisfy new Apache policies,
including replacing SHA-1 checksums with SHA-256 or SHA-512
Posted by bu...@bugzilla.spamassassin.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7596
--- Comment #10 from John Hardin <jh...@impsec.org> ---
(In reply to Bill Cole from comment #9)
> (In reply to John Hardin from comment #8)
> > (In reply to Kevin A. McGrail from comment #7)
> > > Just confirmed that code for the support to use sha256 by default for rule
> > > signatures and that sha1 is used as secondary if sha256 does not exist IS in
> > > 3.4 and trunk.
> >
> > Oh, good.
> >
> > I'd suggest again: if both are present we should validate both. It sounds
> > like that would be a minor code change.
>
> Not at all. It would be a non-change. It's how the code was designed from
> the start.
OK, good. I didn't actually look a the code, I was interpreting "if sha256 does
not exist" as "fallback", not "as well".
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7596] Update distribution to satisfy new Apache policies,
including replacing SHA-1 checksums with SHA-256 or SHA-512
Posted by bu...@bugzilla.spamassassin.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7596
Bill Cole <sa...@billmail.scconsult.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |sa-bugz-20080315@billmail.s
| |cconsult.com
--- Comment #9 from Bill Cole <sa...@billmail.scconsult.com> ---
(In reply to John Hardin from comment #8)
> (In reply to Kevin A. McGrail from comment #7)
> > Just confirmed that code for the support to use sha256 by default for rule
> > signatures and that sha1 is used as secondary if sha256 does not exist IS in
> > 3.4 and trunk.
>
> Oh, good.
>
> I'd suggest again: if both are present we should validate both. It sounds
> like that would be a minor code change.
Not at all. It would be a non-change. It's how the code was designed from the
start.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7596] Update distribution to satisfy new Apache policies,
including replacing SHA-1 checksums with SHA-256 or SHA-512
Posted by bu...@bugzilla.spamassassin.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7596
RW <rw...@googlemail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rwmaillists@googlemail.com
--- Comment #11 from RW <rw...@googlemail.com> ---
(In reply to Kevin A. McGrail from comment #2)
> New Policy from yesterday, not yet linked publicly:
>
> Details:
>
> Recently, a successful penetration of SHA-1 was verified, and SHA-1 is no
> longer considered safe for crypto hashes
This is an exaggeration, Google demonstrated a successful collision attack.
A collision attack against a release would require that both the legitimate
tarball and the fake be created together, so only one of you lot could pull it
off. And you'd need hardware that's orders of magnitude faster than Google's to
avoid some very suspicious behaviour.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7596] Update distribution to satisfy new Apache policies,
including replacing SHA-1 checksums with SHA-256 or SHA-512
Posted by bu...@bugzilla.spamassassin.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7596
--- Comment #8 from John Hardin <jh...@impsec.org> ---
(In reply to Kevin A. McGrail from comment #7)
> Just confirmed that code for the support to use sha256 by default for rule
> signatures and that sha1 is used as secondary if sha256 does not exist IS in
> 3.4 and trunk.
Oh, good.
I'd suggest again: if both are present we should validate both. It sounds like
that would be a minor code change.
It's been my position for about 20 years now that a lot of the panic over hash
attacks could have been minimized by using multiple hash algorithms for
validation.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7596] Update distribution to satisfy new Apache policies,
including replacing SHA-1 checksums with SHA-256 or SHA-512
Posted by bu...@bugzilla.spamassassin.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7596
--- Comment #3 from Kevin A. McGrail <km...@apache.org> ---
Sha256 backend and frontend support for rule updates is already in place with
3.4 branch and trunk in sa-update and the rule generation system/rules mirror.
This will be more for the actual upcoming 3.4.2 release and similar.
KAM
--
You are receiving this mail because:
You are the assignee for the bug.