jira-importer commented on issue #430: URL: https://github.com/apache/maven-apache-parent/issues/430#issuecomment-2771722729
**[Christopher Tubbs](https://issues.apache.org/jira/secure/ViewProfile.jspa?name=ctubbsii)** commented I'm not sure what you mean about whether your personal key is sufficient (that concern seems more related to what I suggested in MGPG-54). This issue isn't related to the signer's key. Rather, this would simply ensure that the signature is of a strong hash of the contents. This ensures that an attacker cannot easily alter the contents of a file to create a hash collision, such that the original signature from the release manager would still validate against the modified file. This is why the [dev guidelines](http://www.apache.org/dev/openpgp.html#sha1) already [suggest](http://www.apache.org/dev/release-signing.html#sha1) using SHA-512, [as do](https://keyring.debian.org/creating-key.html) [nearly every](https://help.riseup.net/en/security/message-security/openpgp/best-practices) [search result](https://wiki.ubuntu.com/SecurityTeam/GPGMigration) [in Google's](https://www.tylerburton.ca/2015/04/gpg-conf-current-best-practices-april-2015/) [top search results](https://sparkslinux.wordpress.com/2013/02/21/hashing-algorithm-is-your-gpg-configuration-secure/) when looking for ["gpg recommended digest algorithm"](https://w ww.google.com/search?q=gnupg+recommended+digest+algorithm). There are two implications to consider: 1. This is currently the strongest digest algorithm available, but it won't be forever. When the recommendation eventually changes (presumably when SHA-3 algorithms are finished and widely implemented), this will become out of date (not all that different from an out of date plugin version in MPOM). 2. This will cause breakage if a release manager tries to perform a release and they are running a **very** old version of gpg, which does not have support for SHA512. In this case, they would need to update, or override the setting to perform a release with weaker signatures. I suppose it would also affect communities explicitly deciding to create releases with weaker signatures... but I'm not sure why anybody would do that on purpose. The main benefit of configuring this by default in the parent pom is to avoid the **accidental** use of weaker algorithms when creating signatures. What do you think are the next steps? How do we engage the larger community and security team to discuss and weigh in on this? There's no urgency, but I really can't see much of a downside. -- 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]
