aurora-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aurora ReviewBot <wfar...@apache.org>
Subject Re: Review Request 62830: Switch release checksum to sha512
Date Sun, 08 Oct 2017 16:36:19 GMT

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/62830/#review187362
-----------------------------------------------------------


Ship it!




Master (0f1e684) is green with this patch.
  ./build-support/jenkins/build.sh

I will refresh this build result if you post a review containing "@ReviewBot retry"

- Aurora ReviewBot


On Oct. 8, 2017, 6:15 p.m., Stephan Erb wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/62830/
> -----------------------------------------------------------
> 
> (Updated Oct. 8, 2017, 6:15 p.m.)
> 
> 
> Review request for Aurora and Bill Farner.
> 
> 
> Repository: aurora
> 
> 
> Description
> -------
> 
> For our releases we will now be using .sha512 files rather than .sha files
> containing sha1 checksums. This change is triggered by a recent update of
> the Apache Release Distribution Policy.
> 
> Please see this mail for details:
> 
> ```
> Hi PMC,
> 
>     The Release Distribution Policy[1] changed regarding .sha files.
>     See under "Cryptographic Signatures and Checksums Requirements" [2].
> 
>    Old policy :
> 
>      -- use extension .sha for any SHA checksum (SHA-1, SHA-256, SHA-512)
> 
>    New policy :
> 
>       -- use .sha1 for a SHA-1 checksum
>       -- use .sha256 for a SHA-256 checksum
>       -- use .sha512 for a SHA-512 checksum
>       -- [*] .sha should contain a SHA-1
> 
>    Why this change ?
> 
>       -- Verifying a checksum under the old policy is/was not handy.
>          You have to inspect the .sha to find out which algorithm
>          should be used ; or try them all (SHA-1, SHA256, etc).
>          The new scheme avoids this ambiguity.
>       -- The last point[*] was only added for clarity. Most of the
>          old, stale .sha's contain a SHA-1. The relatively new .sha's
>          contain a SHA-512. The expectation is that the last catagory will
>          disappear, when active projects adapt to the 'new' convention.
> 
>    Impact :
> 
>       -- Should be none ; many projects already use the 'new' convention.
>       -- Please ask your release managers to use .sha1, .sha256, .sha512
>          instead of the .sha extension.
>       -- Please fix your build-tools if you have any.
> 
>    Piggyback :
> 
>       -- The policy requires a .md5 for every package ;
>          providing a .sha512 is recommended.
>          Since MD5 is essentially broken, it is to be expected that
>          in the future a .sha512 will be required.
>          Perhaps it is wize to start providing .sha512's
>          with your releases if you do not already do so.
> 
>       -- Visit http://mirror-vm.apache.org/checker/
>          to check the health of your /dist/-area ;
>          my stuff ; any feedback is most welcome.
> 
>    Thanks ; regards,
> 
>    Henk Penning
> 
>     [1] http://www.apache.org/dev/release-distribution
>     [2] http://www.apache.org/dev/release-distribution#sigs-and-sums
> ```
> 
> 
> Diffs
> -----
> 
>   build-support/release/release ff7ee71211d950ee11d6b4cc6aaa8dd1cfb666e9 
>   build-support/release/release-candidate bab92bba857d37c880945dcf54637e3fed2e2fc1 
>   build-support/release/verify-release-candidate 3b9beeea981f04253f147eea4262ce809c58bac3

> 
> 
> Diff: https://reviews.apache.org/r/62830/diff/1/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Stephan Erb
> 
>


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