incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henk P. Penning" <>
Subject Re: Digests in releases
Date Sat, 02 Sep 2017 10:00:13 GMT
On Fri, 1 Sep 2017, Christopher wrote:

> Date: Fri, 1 Sep 2017 03:29:58 +0200
> From: Christopher <>
> To:
> 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]
>> [2]

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

   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.


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

   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/ :
       AFAIK it doesn't report any false negatives or positives ;
       please send comments etc to me (


   Henk Penning

------------------------------------------------------------   _
Henk P. Penning, ICT-beta                 R Uithof HFG-406   _/ \_
Faculty of Science, Utrecht University    T +31 30 253 4106 / \_/ \
Budapestlaan 6, 3584CD Utrecht, NL        F +31 30 253 4553 \_/ \_/ M     \_/

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message