sbp opened a new issue, #437: URL: https://github.com/apache/tooling-trusted-releases/issues/437
The ASF release policy currently [requires release managers to sign all artifacts with OpenPGP before voting](https://www.apache.org/legal/release-policy.html#release-signing) if their project is not being built by automated release infrastructure, which requires a reproducible build. > All supplied packages MUST be cryptographically signed with an ASCII-armored detached signature. They MUST be signed by either the Release Manager or the automated release infrastructure, where the underlying implementation MUST follow the principles [outlined](https://www.apache.org/dev/release-signing.html#automated-release-signing) by the Apache Security Team. Since the vast majority of ASF projects are not yet built on automated release infrastructure, almost all release managers currently have to sign their artifacts. We have long been discussing, in Tooling, whether we should migrate to Sigstore, like the Python Software Foundation, to ease the burden of signing. An informal internal review that I conducted concluded that balance of tradeoffs is unclear, but probably quite in favour of OpenPGP, and that at most we should support Sigstore only in addition to OpenPGP and not as a replacement. The Python Software Foundation decided differently, so this outcome is subject to further consideration. There are, however, other potential solutions. We could allow a private key to be generated by ATR and protected with symmetric encryption, and then allow signing to take place automatically on the platform. The security would then reduce to that of the OAuth session of the user, which we could attest to, and the security of the ATR server. Overall I think that this would be a reduction in security compared to the average case of a release manager signing on their own machine, but it may still be acceptable to the foundation, and it sets a baseline that may in some cases even be a security improvement. This solution would drastically improve the usability of the signing process. The release manager would be required to enter the high entropy password protecting their private key only, and ATR would do the rest. An obvious problem here is that "enter a password" is always susceptible to phishing, so we would probably have to say that this can only be done if the user has logged in using WebAuthn. But even this may be positive, as it could encourage release managers to use WebAuthn. -- 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]
