You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@pekko.apache.org by "raboof (via GitHub)" <gi...@apache.org> on 2023/02/07 14:15:21 UTC

[GitHub] [incubator-pekko] raboof commented on issue #130: Setup the release process

raboof commented on issue #130:
URL: https://github.com/apache/incubator-pekko/issues/130#issuecomment-1420845831

   > a release manager has to have control over the machine they do the release under
   
   AFAICT the policy says the verification needs to happen on (a) machine(s) owned and controlled by the committer, but the artifact-being-verified might come from another machine.
   
   There's some precedent for this approach in https://github.com/apache/logging-log4j-tools/blob/master/RELEASING.adoc though indeed it's early, and it might still be subject to change after this approach has been more formally described on Confluence and discussed further on the members@ list.
   
   > Doing so would mean putting your private/signing key as a secret into the CI machine which is not allowed, see https://infra.apache.org/openpgp.html#private-keyring-management.
   
   It seems for logging infra has been able to create a separate keypair for this purpose (https://issues.apache.org/jira/browse/INFRA-23996) and gave the individual PMC members revocation rights.
   
   > For this reason it would make more sense to have a private key specific just for CI, but then this would break the paper trail to the release manager (which I presume is the main point of signing in the first place, even from an ASF legal/insurance standpoint).
   
   When the build is reproducible, the RM (and other voters) can independently build&verify the artifact before voting, which I'd say (but IANAL) should close the loop.
   
   Anyway, it's up to you which way to go, and I can imagine perhaps waiting until this process is more broadly vetted - just wanted to make you aware of the option ;)


-- 
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: notifications-unsubscribe@pekko.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@pekko.apache.org
For additional commands, e-mail: notifications-help@pekko.apache.org