sbp opened a new issue, #431: URL: https://github.com/apache/tooling-trusted-releases/issues/431
In a call with @adityamparikh and @epugh, Eric suggested that we make the SHA256 generation button less prominent than the SHA512 button, because [ASF Infra recommend using that](https://infra.apache.org/release-signing.html#sha-checksum). We will do this by hiding the SHA256 button in a `details` element, but ASF Tooling have also discussed removing the checksum generation buttons entirely. The question we considered was whether the checksums exist to allow end users to check the files, or whether they allow ATR itself to check the files uploaded by the release manager. In the former case they can be generated on ATR, but in the latter case they can only be generated by the release manager. But we can also get the best of both worlds. Since a release manager currently has to sign files before uploading them, and since we verify the signature, we can use the signature as a corroborating checksum. GnuPG stores only the first two bytes of whatever hash it is configured to use in its signature files (cf. `byte digest_start[2]` in `packet.h`), but the whole artifact is hashed again on signature verification. Therefore we can be certain, as long as a secure hash algorithm was used and the upload process was secure and so on, that the file on ATR is the one that the release manager intended to upload. In that case we can generate SHA256 or SHA512 checksum files on ATR with the greater assurance level mentioned above. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
