Re: Digests in releases
On Thu, Aug 31, 2017 at 3:15 PM, Henk P. Penning wrote: > -- SHA-1 : not as bad as MD5, but no longer considered secure > by some ; https://en.wikipedia.org/wiki/SHA-1 ; skip > -- SHA-256 : fine > -- SHA-512 : fine > > So, I would suggest we pick SHA-256... +1 -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Digests in releases
My proposal was an attempt to achieve two goals: 1. Drop the absolute MD5 requirement in favor of an "at least MD5" requirement, and 2. Make [2] consistent with [3] by dropping file naming conventions in [2], and deferring to the constraints in [3]. If my existing wording is too complex, I'm sure it could be rewritten to achieve both of these goals with simpler wording. If considering both goals at the same time is too much to address at once, we could just focus on #1, since that's more relevant to the topic this thread started with. On Sat, Sep 2, 2017 at 6:00 AM Henk P. Penning wrote: > On Fri, 1 Sep 2017, Christopher wrote: > > > Date: Fri, 1 Sep 2017 03:29:58 +0200 > > From: Christopher > > To: general@incubator.apache.org > > Subject: Re: Digests in releases > > > > On Wed, Aug 30, 2017 at 5:08 PM Julian Hyde wrote: > > > >> What is the correct forum for discussing release distribution policy? > >> > >> > > Good question. I hope it's this one, since this is where the discussion > is > > happening. > > > > > > > >> Current policy [1] states: > >> > >> Every artifact distributed to the public through Apache channels MUST > >> be accompanied by one file containing an OpenPGP compatible ASCII > >> armored detached signature and another file containing an MD5 > checksum. > >> > >> ... > >> > >> An SHA checksum SHOULD also be created. > >> > >> > >> MD5 is no longer deemed secure[2]. I think we should remove it from > >> our releases and mandate SHA256 or SHA512. > > >> [1] http://www.apache.org/dev/release-distribution.html#sigs-and-sums > >> [2] https://en.wikipedia.org/wiki/Md5sum > > > > > A good policy is simple and flexible, in my opinion. Rather than require > > any specific checksum with others optional, I would personally like to > see > > the policy changed to simply require "a detached ASCII-armored GPG > > signature named .asc for each release artifact, and one or > > more standard checksums with a minimum strength of MD5 in a standard file > > format with a convenient file naming convention" > > > > Such a policy could easily be updated by simply changing the "minimum > > strength", if necessary, in the future. But changing the policy to allow > > PMCs to drop support for legacy hashes, replaced by newer standards, is > > infinitely better, in my opinion. > >The '(legal) release policy' [1] says /what/ we want, and /why/. >-- note that [1] doesn't even mention checksums. >The 'Release Distribution Policy' [2] says /how/ we do it. >-- because [2] is about 'implementation' it should preferably be : > -- simple, strict, unambiguous and short > -- easy to explain and easy to understand > -- ASF-wide > >I think the current scheme has the prefered properties. > >[1] http://www.apache.org/legal/release-policy.html >[2] http://www.apache.org/dev/release-distribution >[3] http://www.apache.org/dev/release-publishing > > > If my wording needs clarification: > > > > By "standard checksums", I mean MD5, SHA1, or any of the SHA2 family > > currently, but maybe SHA3 family in future. > > By "standard file format", I mean a plain text file containing only the > > ASCII encoded hex representation of the hash or in a format such as those > > output by the 'sha*sum' suite of tools (example: > > https://www.systutorials.com/docs/linux/man/1-sha512sum/). > > By "convenient file naming convention", I mean the artifact file name > > with an appended ".md5 or .sha\d*" or aggregated into a file such as > > CHECKSUMS, SHA1SUM, MD5SUM, etc. for the convenience of verifying > multiple > > artifact files from a release. > >If I understand you correctly, the operational word here is "or" >in "or aggregated into a file [...]". > >-- The scheme you propose is more complex than the current scheme ; > therefor, a priori, it isn't better. >-- In your scheme, the checksum of a given file can be in multiple > places ; this error-prone, harder to use, check and report. >-- Note that [3] /allows/ you to supply 'MD5SUM' and 'SHA*SUM' files, > but [3] also says that in general checksum files shouldn't leak > to the mirrors, so a list of excluded files is provided ; > a short list is better than a long list. > [the l
Re: Digests in releases
On Fri, 1 Sep 2017, Christopher wrote: Date: Fri, 1 Sep 2017 03:29:58 +0200 From: Christopher To: general@incubator.apache.org Subject: Re: Digests in releases On Wed, Aug 30, 2017 at 5:08 PM Julian Hyde wrote: What is the correct forum for discussing release distribution policy? Good question. I hope it's this one, since this is where the discussion is happening. Current policy [1] states: Every artifact distributed to the public through Apache channels MUST be accompanied by one file containing an OpenPGP compatible ASCII armored detached signature and another file containing an MD5 checksum. ... An SHA checksum SHOULD also be created. MD5 is no longer deemed secure[2]. I think we should remove it from our releases and mandate SHA256 or SHA512. [1] http://www.apache.org/dev/release-distribution.html#sigs-and-sums [2] https://en.wikipedia.org/wiki/Md5sum A good policy is simple and flexible, in my opinion. Rather than require any specific checksum with others optional, I would personally like to see the policy changed to simply require "a detached ASCII-armored GPG signature named .asc for each release artifact, and one or more standard checksums with a minimum strength of MD5 in a standard file format with a convenient file naming convention" Such a policy could easily be updated by simply changing the "minimum strength", if necessary, in the future. But changing the policy to allow PMCs to drop support for legacy hashes, replaced by newer standards, is infinitely better, in my opinion. The '(legal) release policy' [1] says /what/ we want, and /why/. -- note that [1] doesn't even mention checksums. The 'Release Distribution Policy' [2] says /how/ we do it. -- because [2] is about 'implementation' it should preferably be : -- simple, strict, unambiguous and short -- easy to explain and easy to understand -- ASF-wide I think the current scheme has the prefered properties. [1] http://www.apache.org/legal/release-policy.html [2] http://www.apache.org/dev/release-distribution [3] http://www.apache.org/dev/release-publishing If my wording needs clarification: By "standard checksums", I mean MD5, SHA1, or any of the SHA2 family currently, but maybe SHA3 family in future. By "standard file format", I mean a plain text file containing only the ASCII encoded hex representation of the hash or in a format such as those output by the 'sha*sum' suite of tools (example: https://www.systutorials.com/docs/linux/man/1-sha512sum/). By "convenient file naming convention", I mean the artifact file name with an appended ".md5 or .sha\d*" or aggregated into a file such as CHECKSUMS, SHA1SUM, MD5SUM, etc. for the convenience of verifying multiple artifact files from a release. If I understand you correctly, the operational word here is "or" in "or aggregated into a file [...]". -- The scheme you propose is more complex than the current scheme ; therefor, a priori, it isn't better. -- In your scheme, the checksum of a given file can be in multiple places ; this error-prone, harder to use, check and report. -- Note that [3] /allows/ you to supply 'MD5SUM' and 'SHA*SUM' files, but [3] also says that in general checksum files shouldn't leak to the mirrors, so a list of excluded files is provided ; a short list is better than a long list. [the list appears to be incomplete, which proves my point ;-] -- You talk about a "standard file format" [for checksum files] ; note that the current scheme does /not/ specify anything about the contents of a checksum file ; yet it works (*). Look at the checksum files in /dist/ ; they vary wildly. Prescribing the format of checksum files is a bad idea. (*) The checker finds some bad checksum files in /dist/ : https://checker.apache.org/dist/sums.html AFAIK it doesn't report any false negatives or positives ; please send comments etc to me (he...@apache.org). Regards, Henk Penning _ Henk P. Penning, ICT-beta R Uithof HFG-406 _/ \_ Faculty of Science, Utrecht UniversityT +31 30 253 4106 / \_/ \ Budapestlaan 6, 3584CD Utrecht, NLF +31 30 253 4553 \_/ \_/ http://www.staff.science.uu.nl/~penni101/ M penn...@uu.nl \_/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Digests in releases
Dave Fisher wrote on Thu, 31 Aug 2017 13:35 -0700:
> Regardless of what Jane User knows, and we have 200 million Jane Users of
> Apache OpenOffice, I think it would be helpful to have an Apache Download
> checker program/script that could be run to confirm the bonafides.
>
> An idea.
Why stop here? On unix this problem is largely solved, by
'${packagemanager} install foo' (substitute your distro's package
manager). Why not set up a package manager (program + repository
service) for windows?
With 200M users, though, somebody's going to write phishing software
that impersonates the package manager. There's no easy way around the
web of trust.
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
Re: Digests in releases
Hey Joe, Thanks for the pointer. I think Henk needs to be involved. Regards, Dave Sent from my iPhone > On Aug 31, 2017, at 3:31 PM, Joe Schaefer wrote: > > Henk's scripting does that and much more. > >> On Thu, Aug 31, 2017 at 5:09 PM Ted Dunning wrote: >> >> I thought that gpg does that. >> >> On Thu, Aug 31, 2017 at 1:35 PM, Dave Fisher >> wrote: >> >>> Regardless of what Jane User knows, and we have 200 million Jane Users of >>> Apache OpenOffice, I think it would be helpful to have an Apache Download >>> checker program/script that could be run to confirm the bonafides. >>> >>> An idea. >>> >>> Regards, >>> Dave >>> On Aug 31, 2017, at 1:22 PM, Julian Hyde >> wrote: I know this. You know this. Joe User does not know this. I am trying to >>> make Joe User’s life easier. Since SHA256 is sufficient for both purposes why does release policy >>> MANDATE that projects include an MD5? Julian b > On Aug 31, 2017, at 1:17 PM, Ted Dunning >> wrote: > > The checksum is not a tampering countermeasure. > > It is a "mirror ran out of diskpace" or "IP checksums are only 32 >> bits" > countermeasure. > > > > On Thu, Aug 31, 2017 at 11:35 AM, Julian Hyde >> wrote: > >> As security experts, you and I know that. But Joe User maybe only >>> checks >> one digest. >> >> (Aren’t we all Joe User sometimes?) >> >> Julian >> >>> On Aug 31, 2017, at 11:30 AM, Mike Jumper >> >> wrote: >>> >>> On Aug 31, 2017 11:21, "Julian Hyde" wrote: >>> >>> After downloading artifacts, there are 3 things to check: (1) the >> download >>> is successful; (2) the artifacts were indeed created by the named >>> author; >>> and (3) the artifacts have not been tampered with. >>> >>> A security expert would know to use the .md5 for (1), the .asc for >>> (2), >> and >>> the .sha256 or .sha512 for (3). >>> >>> >>> If there is a danger that the artifacts may be tampered with, there >>> is an >>> equivalent danger that the checksum files will be tampered with, as >>> well. >>> Checksums alone cannot be relied upon to verify an artifact hasn't >>> been >>> altered. >>> >>> Only the signature allows verification of authorship and integrity >> ... >>> assuming users have secure access to the corresponding public keys, >>> and >>> that those keys are linked into the web of trust. >>> >>> - Mike >> >> >> - >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> >> - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org >>> >>> >> - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Digests in releases
On Wed, Aug 30, 2017 at 5:08 PM Julian Hyde wrote: > What is the correct forum for discussing release distribution policy? > > Good question. I hope it's this one, since this is where the discussion is happening. > Current policy [1] states: > > Every artifact distributed to the public through Apache channels MUST > be accompanied by one file containing an OpenPGP compatible ASCII > armored detached signature and another file containing an MD5 checksum. > > ... > > An SHA checksum SHOULD also be created. > > > MD5 is no longer deemed secure[2]. I think we should remove it from > our releases and mandate SHA256 or SHA512. > > A good policy is simple and flexible, in my opinion. Rather than require any specific checksum with others optional, I would personally like to see the policy changed to simply require "a detached ASCII-armored GPG signature named .asc for each release artifact, and one or more standard checksums with a minimum strength of MD5 in a standard file format with a convenient file naming convention" Such a policy could easily be updated by simply changing the "minimum strength", if necessary, in the future. But changing the policy to allow PMCs to drop support for legacy hashes, replaced by newer standards, is infinitely better, in my opinion. If my wording needs clarification: By "standard checksums", I mean MD5, SHA1, or any of the SHA2 family currently, but maybe SHA3 family in future. By "standard file format", I mean a plain text file containing only the ASCII encoded hex representation of the hash or in a format such as those output by the 'sha*sum' suite of tools (example: https://www.systutorials.com/docs/linux/man/1-sha512sum/). By "convenient file naming convention", I mean the artifact file name with an appended ".md5 or .sha\d*" or aggregated into a file such as CHECKSUMS, SHA1SUM, MD5SUM, etc. for the convenience of verifying multiple artifact files from a release. Modifying the policy in this way, we can eliminate requirements for legacy hashes and inconvenient (as determined by PMCs for their users, not by INFRA) file naming conventions. Of course, the file naming conventions would still have to fit into constraints imposed by INFRA for the mirroring system, or Maven deployments, or whatever, but these would simply be implementation details, rather than enshrined in policy (which I think is better, because policy should be simple and shouldn't change as much; INFRA should be able to update implementation details, upon request, to allow more conventions as new projects come on board with their own conventions, and as verification tools and de facto standards around the internet evolve). > Julian > > [1] http://www.apache.org/dev/release-distribution.html#sigs-and-sums > > [2] https://en.wikipedia.org/wiki/Md5sum > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: Digests in releases
Henk's scripting does that and much more. On Thu, Aug 31, 2017 at 5:09 PM Ted Dunning wrote: > I thought that gpg does that. > > On Thu, Aug 31, 2017 at 1:35 PM, Dave Fisher > wrote: > > > Regardless of what Jane User knows, and we have 200 million Jane Users of > > Apache OpenOffice, I think it would be helpful to have an Apache Download > > checker program/script that could be run to confirm the bonafides. > > > > An idea. > > > > Regards, > > Dave > > > > > On Aug 31, 2017, at 1:22 PM, Julian Hyde > wrote: > > > > > > I know this. You know this. Joe User does not know this. I am trying to > > make Joe User’s life easier. > > > > > > Since SHA256 is sufficient for both purposes why does release policy > > MANDATE that projects include an MD5? > > > > > > Julian > > >b > > > > > >> On Aug 31, 2017, at 1:17 PM, Ted Dunning > wrote: > > >> > > >> The checksum is not a tampering countermeasure. > > >> > > >> It is a "mirror ran out of diskpace" or "IP checksums are only 32 > bits" > > >> countermeasure. > > >> > > >> > > >> > > >> On Thu, Aug 31, 2017 at 11:35 AM, Julian Hyde > wrote: > > >> > > >>> As security experts, you and I know that. But Joe User maybe only > > checks > > >>> one digest. > > >>> > > >>> (Aren’t we all Joe User sometimes?) > > >>> > > >>> Julian > > >>> > > On Aug 31, 2017, at 11:30 AM, Mike Jumper > > > >>> wrote: > > > > On Aug 31, 2017 11:21, "Julian Hyde" wrote: > > > > After downloading artifacts, there are 3 things to check: (1) the > > >>> download > > is successful; (2) the artifacts were indeed created by the named > > author; > > and (3) the artifacts have not been tampered with. > > > > A security expert would know to use the .md5 for (1), the .asc for > > (2), > > >>> and > > the .sha256 or .sha512 for (3). > > > > > > If there is a danger that the artifacts may be tampered with, there > > is an > > equivalent danger that the checksum files will be tampered with, as > > well. > > Checksums alone cannot be relied upon to verify an artifact hasn't > > been > > altered. > > > > Only the signature allows verification of authorship and integrity > ... > > assuming users have secure access to the corresponding public keys, > > and > > that those keys are linked into the web of trust. > > > > - Mike > > >>> > > >>> > > >>> - > > >>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > >>> For additional commands, e-mail: general-h...@incubator.apache.org > > >>> > > >>> > > > > > > > > > - > > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > > > >
Re: Digests in releases
I thought that gpg does that. On Thu, Aug 31, 2017 at 1:35 PM, Dave Fisher wrote: > Regardless of what Jane User knows, and we have 200 million Jane Users of > Apache OpenOffice, I think it would be helpful to have an Apache Download > checker program/script that could be run to confirm the bonafides. > > An idea. > > Regards, > Dave > > > On Aug 31, 2017, at 1:22 PM, Julian Hyde wrote: > > > > I know this. You know this. Joe User does not know this. I am trying to > make Joe User’s life easier. > > > > Since SHA256 is sufficient for both purposes why does release policy > MANDATE that projects include an MD5? > > > > Julian > > > > > >> On Aug 31, 2017, at 1:17 PM, Ted Dunning wrote: > >> > >> The checksum is not a tampering countermeasure. > >> > >> It is a "mirror ran out of diskpace" or "IP checksums are only 32 bits" > >> countermeasure. > >> > >> > >> > >> On Thu, Aug 31, 2017 at 11:35 AM, Julian Hyde wrote: > >> > >>> As security experts, you and I know that. But Joe User maybe only > checks > >>> one digest. > >>> > >>> (Aren’t we all Joe User sometimes?) > >>> > >>> Julian > >>> > On Aug 31, 2017, at 11:30 AM, Mike Jumper > >>> wrote: > > On Aug 31, 2017 11:21, "Julian Hyde" wrote: > > After downloading artifacts, there are 3 things to check: (1) the > >>> download > is successful; (2) the artifacts were indeed created by the named > author; > and (3) the artifacts have not been tampered with. > > A security expert would know to use the .md5 for (1), the .asc for > (2), > >>> and > the .sha256 or .sha512 for (3). > > > If there is a danger that the artifacts may be tampered with, there > is an > equivalent danger that the checksum files will be tampered with, as > well. > Checksums alone cannot be relied upon to verify an artifact hasn't > been > altered. > > Only the signature allows verification of authorship and integrity ... > assuming users have secure access to the corresponding public keys, > and > that those keys are linked into the web of trust. > > - Mike > >>> > >>> > >>> - > >>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > >>> For additional commands, e-mail: general-h...@incubator.apache.org > >>> > >>> > > > > > > - > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org > > > >
Re: Digests in releases
Regardless of what Jane User knows, and we have 200 million Jane Users of Apache OpenOffice, I think it would be helpful to have an Apache Download checker program/script that could be run to confirm the bonafides. An idea. Regards, Dave > On Aug 31, 2017, at 1:22 PM, Julian Hyde wrote: > > I know this. You know this. Joe User does not know this. I am trying to make > Joe User’s life easier. > > Since SHA256 is sufficient for both purposes why does release policy MANDATE > that projects include an MD5? > > Julian > > >> On Aug 31, 2017, at 1:17 PM, Ted Dunning wrote: >> >> The checksum is not a tampering countermeasure. >> >> It is a "mirror ran out of diskpace" or "IP checksums are only 32 bits" >> countermeasure. >> >> >> >> On Thu, Aug 31, 2017 at 11:35 AM, Julian Hyde wrote: >> >>> As security experts, you and I know that. But Joe User maybe only checks >>> one digest. >>> >>> (Aren’t we all Joe User sometimes?) >>> >>> Julian >>> On Aug 31, 2017, at 11:30 AM, Mike Jumper >>> wrote: On Aug 31, 2017 11:21, "Julian Hyde" wrote: After downloading artifacts, there are 3 things to check: (1) the >>> download is successful; (2) the artifacts were indeed created by the named author; and (3) the artifacts have not been tampered with. A security expert would know to use the .md5 for (1), the .asc for (2), >>> and the .sha256 or .sha512 for (3). If there is a danger that the artifacts may be tampered with, there is an equivalent danger that the checksum files will be tampered with, as well. Checksums alone cannot be relied upon to verify an artifact hasn't been altered. Only the signature allows verification of authorship and integrity ... assuming users have secure access to the corresponding public keys, and that those keys are linked into the web of trust. - Mike >>> >>> >>> - >>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >>> For additional commands, e-mail: general-h...@incubator.apache.org >>> >>> > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > signature.asc Description: Message signed with OpenPGP
Re: Digests in releases
I know this. You know this. Joe User does not know this. I am trying to make Joe User’s life easier. Since SHA256 is sufficient for both purposes why does release policy MANDATE that projects include an MD5? Julian > On Aug 31, 2017, at 1:17 PM, Ted Dunning wrote: > > The checksum is not a tampering countermeasure. > > It is a "mirror ran out of diskpace" or "IP checksums are only 32 bits" > countermeasure. > > > > On Thu, Aug 31, 2017 at 11:35 AM, Julian Hyde wrote: > >> As security experts, you and I know that. But Joe User maybe only checks >> one digest. >> >> (Aren’t we all Joe User sometimes?) >> >> Julian >> >>> On Aug 31, 2017, at 11:30 AM, Mike Jumper >> wrote: >>> >>> On Aug 31, 2017 11:21, "Julian Hyde" wrote: >>> >>> After downloading artifacts, there are 3 things to check: (1) the >> download >>> is successful; (2) the artifacts were indeed created by the named author; >>> and (3) the artifacts have not been tampered with. >>> >>> A security expert would know to use the .md5 for (1), the .asc for (2), >> and >>> the .sha256 or .sha512 for (3). >>> >>> >>> If there is a danger that the artifacts may be tampered with, there is an >>> equivalent danger that the checksum files will be tampered with, as well. >>> Checksums alone cannot be relied upon to verify an artifact hasn't been >>> altered. >>> >>> Only the signature allows verification of authorship and integrity ... >>> assuming users have secure access to the corresponding public keys, and >>> that those keys are linked into the web of trust. >>> >>> - Mike >> >> >> - >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> >> - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Digests in releases
The checksum is not a tampering countermeasure. It is a "mirror ran out of diskpace" or "IP checksums are only 32 bits" countermeasure. On Thu, Aug 31, 2017 at 11:35 AM, Julian Hyde wrote: > As security experts, you and I know that. But Joe User maybe only checks > one digest. > > (Aren’t we all Joe User sometimes?) > > Julian > > > On Aug 31, 2017, at 11:30 AM, Mike Jumper > wrote: > > > > On Aug 31, 2017 11:21, "Julian Hyde" wrote: > > > > After downloading artifacts, there are 3 things to check: (1) the > download > > is successful; (2) the artifacts were indeed created by the named author; > > and (3) the artifacts have not been tampered with. > > > > A security expert would know to use the .md5 for (1), the .asc for (2), > and > > the .sha256 or .sha512 for (3). > > > > > > If there is a danger that the artifacts may be tampered with, there is an > > equivalent danger that the checksum files will be tampered with, as well. > > Checksums alone cannot be relied upon to verify an artifact hasn't been > > altered. > > > > Only the signature allows verification of authorship and integrity ... > > assuming users have secure access to the corresponding public keys, and > > that those keys are linked into the web of trust. > > > > - Mike > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: Digests in releases
As security experts, you and I know that. But Joe User maybe only checks one digest. (Aren’t we all Joe User sometimes?) Julian > On Aug 31, 2017, at 11:30 AM, Mike Jumper wrote: > > On Aug 31, 2017 11:21, "Julian Hyde" wrote: > > After downloading artifacts, there are 3 things to check: (1) the download > is successful; (2) the artifacts were indeed created by the named author; > and (3) the artifacts have not been tampered with. > > A security expert would know to use the .md5 for (1), the .asc for (2), and > the .sha256 or .sha512 for (3). > > > If there is a danger that the artifacts may be tampered with, there is an > equivalent danger that the checksum files will be tampered with, as well. > Checksums alone cannot be relied upon to verify an artifact hasn't been > altered. > > Only the signature allows verification of authorship and integrity ... > assuming users have secure access to the corresponding public keys, and > that those keys are linked into the web of trust. > > - Mike - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Digests in releases
On Aug 31, 2017 11:21, "Julian Hyde" wrote: After downloading artifacts, there are 3 things to check: (1) the download is successful; (2) the artifacts were indeed created by the named author; and (3) the artifacts have not been tampered with. A security expert would know to use the .md5 for (1), the .asc for (2), and the .sha256 or .sha512 for (3). If there is a danger that the artifacts may be tampered with, there is an equivalent danger that the checksum files will be tampered with, as well. Checksums alone cannot be relied upon to verify an artifact hasn't been altered. Only the signature allows verification of authorship and integrity ... assuming users have secure access to the corresponding public keys, and that those keys are linked into the web of trust. - Mike
Re: Digests in releases
After downloading artifacts, there are 3 things to check: (1) the download is successful; (2) the artifacts were indeed created by the named author; and (3) the artifacts have not been tampered with. A security expert would know to use the .md5 for (1), the .asc for (2), and the .sha256 or .sha512 for (3). But we are not all security experts. An ordinary user might use the .md5 for (3), a purpose that it is not suited for. If we switch to .sha256 / .sha512 for both (1) and (3) there is one fewer thing that can go wrong. Julian > On Aug 30, 2017, at 4:12 PM, sebb wrote: > > Surely the main purpose of the hash is to check that the download has > been successful. > As such, MD5 is adequate. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Digests in releases
On Wed, 30 Aug 2017, Julian Hyde wrote: Date: Wed, 30 Aug 2017 14:08:42 -0700 From: Julian Hyde To: general@incubator.apache.org Subject: Digests in releases What is the correct forum for discussing release distribution policy? MD5 is no longer deemed secure[2]. I think we should remove it from our releases and mandate SHA256 or SHA512. Agree ; we should not require or recommend MD5. IMHO, discussions about "MD5 can be used for X but not for Y" are a waste of time ; they never stop en convince nobody. It is better to adopt something that we can agree on. What can we agree on ? -- SHA-1 : not as bad as MD5, but no longer considered secure by some ; https://en.wikipedia.org/wiki/SHA-1 ; skip -- SHA-256 : fine -- SHA-512 : fine So, I would suggest we pick SHA-256. Julian Regards, Henk Penning _ Henk P. Penning, ICT-beta R Uithof HFG-406 _/ \_ Faculty of Science, Utrecht UniversityT +31 30 253 4106 / \_/ \ Budapestlaan 6, 3584CD Utrecht, NLF +31 30 253 4553 \_/ \_/ http://www.staff.science.uu.nl/~penni101/ M penn...@uu.nl \_/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Digests in releases
On 30 August 2017 at 22:08, Julian Hyde wrote: > What is the correct forum for discussing release distribution policy? > > Current policy [1] states: > > Every artifact distributed to the public through Apache channels MUST > be accompanied by one file containing an OpenPGP compatible ASCII > armored detached signature and another file containing an MD5 checksum. > > ... > > An SHA checksum SHOULD also be created. > > > MD5 is no longer deemed secure[2]. I think we should remove it from > our releases and mandate SHA256 or SHA512. Surely the main purpose of the hash is to check that the download has been successful. As such, MD5 is adequate. > Julian > > [1] http://www.apache.org/dev/release-distribution.html#sigs-and-sums > > [2] https://en.wikipedia.org/wiki/Md5sum > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Digests in releases
What is the correct forum for discussing release distribution policy? Current policy [1] states: Every artifact distributed to the public through Apache channels MUST be accompanied by one file containing an OpenPGP compatible ASCII armored detached signature and another file containing an MD5 checksum. ... An SHA checksum SHOULD also be created. MD5 is no longer deemed secure[2]. I think we should remove it from our releases and mandate SHA256 or SHA512. Julian [1] http://www.apache.org/dev/release-distribution.html#sigs-and-sums [2] https://en.wikipedia.org/wiki/Md5sum - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
