sbp commented on issue #171: URL: https://github.com/apache/tooling-trusted-release/issues/171#issuecomment-2976717532
We don't presently allow file content to change after a vote has concluded, precisely because of the requirement of preserving reproducible builds. On the other hand there has been some concern about what this means in terms of signing. When files are uploaded, they must come with `.asc` signatures. This can look like ratification of the files, whereas in fact the files are not ratified until the vote has concluded. If the files are `rc` artifacts, with internal `0.0.1rc1` style versions, then the signature data is at least clear that an RC is being signed. But if it's a release candidate for a reproducible build, then those `.asc` signatures are for what may be the final release. The problem is this: say the vote for 0.0.1 fails, because there's a huge security flaw in the release. You fix it, sign the fixed version (also called 0.0.1), and the vote passes and you distribute. But an attacker downloaded the earlier 0.0.1 files, with all the release manager's `.asc` files. They can now distribute these. There's nothing to distinguish them from the final release. The security flaw is present, but the files are signed. It has the right version, the right signatures, but the "wrong" implementation - one that was never intended for release. There are all sorts of ways to fix but, but I would favour signing metadata about the releases instead of the release files themselves. You'd have a statement saying "these files are release candidates being offered for vote, and this signature is by the release manager for integrity of the vote process, not for final release", or somesuch. You'd include the hash of the files being proxy signed in this way. Then you'd sign that statement. This would, however, be a signfiicant change in ASF release policy. -- 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: dev-unsubscr...@tooling.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tooling.apache.org For additional commands, e-mail: dev-h...@tooling.apache.org
