Hi Daniel, > Automating this process *requires* a > reproducible build process that has been approved by the ASF security > team
It sseems the security team has limited bandwidth to process such a review request. I make the request to secur...@apache.org for OpenDAL (incubating) and the team member tells me they are working on other items now. This is of course understandable, while I'm wondering if we have a JIRA project to track this request instead of I keep an eye on the security mailing list which is quite busy for other threads. Also, I don't think such a request needs to be private and secur...@apache.org is private. Briefly, I'm not sure if we have a public tracking place for requests on automating releases. Best, tison. Daniel Gruno <humbed...@apache.org> 于2023年7月19日周三 17:28写道： > On 2023-07-19 11:21, Francis Chuang wrote: > > Is infra happy to explore the case where release artifacts are > automatically uploaded via CI? > > The exploration is already ongoing. > > > > > This would go a long way towards automating our release process as > asking RMs to download the release artifacts from GitHub and uploading them > manually is a bit clunky. > > I do want to point out one thing that is a general requirement and not > specific to this email or project: Automating this process *requires* a > reproducible build process that has been approved by the ASF security > team. That is the first place projects should look when they decide to > explore this route, and is a requirement before infra will even > entertain the notion of automated artifacts for a project. > > > > > On 2023/07/18 19:55:00 Volkan Yazıcı wrote: > >> Abstract: Signing release artifacts using an automated release > >> infrastructure has been officially approved by LEGAL. This enables > >> projects to sign artifacts using, say, GitHub Actions. > >> > >> I have been trying to overhaul the Log4j release process and make it > >> as frictionless as possible since last year. As a part of that effort, > >> I wanted to sign artifacts in CI during deployment and in a > >> `members@a.o` thread[0] I explained how one can do that securely with > >> the help of Infra. That was in December 2022. It has been a long, > >> rough journey, but we succeeded. In this PR[1], Legal has updated the > >> release policy to reflect that this process is officially allowed. > >> Further, Infra put together guides[2][3] to assist projects. Logging > >> Services PMC has already successfully performed 4 Log4j Tools releases > >> using this approach, see its release process[4] for a demonstration. > >> > >> [0] (members only!) > >> https://lists.apache.org/thread/1o12mkjrhyl45f9pof94pskg55vhs61n > >> [1] https://github.com/apache/www-site/pull/235 > >> [2] https://infra.apache.org/release-publishing.html#signing > >> [3] > https://infra.apache.org/release-signing.html#automated-release-signing > >> [4] > https://github.com/apache/logging-log4j-tools/blob/master/RELEASING.adoc > >> > >> # F.A.Q. > >> > >> ## Why shall a project be interested in this? > >> > >> It greatly simplifies the release process. See Log4j Tools release > >> process[4], probably the simplest among all Java-based ASF projects. > >> > >> ## How can a project get started? > >> > >> 1. Make sure your project builds are reproducible (otherwise there is > >> no way PMC can verify the integrity of CI-produced and -signed > >> artifacts) > >> 2. Clone and adapt INFRA-23996 (GPG keys in GitHub secrets) > >> 3. Clone and adapt INFRA-23974 (Nexus creds. in GitHub secrets for > >> snapshot deployments) > >> 4. Clone and adapt INFRA-24051 (Nexus creds. in GitHub secrets for > >> staging deployments) > >> > >> You might also want to check this[5] GitHub Action workflow for > inspiration. > >> > >> [5] > https://github.com/apache/logging-log4j-tools/blob/master/.github/workflows/build.yml > >> > >> ## Does the "automated release infrastructure" (CI) perform the full > release? > >> > >> No. CI *only* uploads signed artifacts to Nexus. The release manager > >> (RM) still needs to copy the CI-generated files to SVN, PMC needs to > >> vote, and, upon consensus, RM needs to "close" the release in Nexus > >> and so on. > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > >> For additional commands, e-mail: dev-h...@community.apache.org > >> > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > > For additional commands, e-mail: dev-h...@community.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > For additional commands, e-mail: dev-h...@community.apache.org > >
