incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <>
Subject Re: Digests in releases
Date Fri, 01 Sep 2017 01:29:58 GMT
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

> 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 <file>.asc for each <file> 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:
  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

> Julian
> [1]
> [2]
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message