ppkarwasz commented on issue #171: URL: https://github.com/apache/tooling-trusted-release/issues/171#issuecomment-2983857111
> 1. There is something to be said about having an attestation about the released artifacts. While a new addition to the process, we can make it part of our process. I think that this can become part of the Release Policy, but that would need a clear proposal and discussion on `legal-discuss@a.o` Attestations would be a nice addition to the process, although to solve the signing dilemma described by @sbp, we could either: - Hide the signatures uploaded by the Release Manager from the UI and just trust the TLS certificate to provide authenticity and integrity for the downloaded release candidates. - Or upload our release candidates using a "release-candidate only" key. > 4. I would be in favor of the following changes. > > * Add an explicit RC field separate from the version. Changing this value should create a blank revision. This would happen after a failed vote. At that time the Release Manager could decide to simply discard the whole candidate. > * The vote email has a thread id. Is this suitable for an UUID which we carry forward? > * The RC field or a UUID should part of the path for finding the VOTE artifacts and the RC field in the email subject. Looks good to me. -- 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
